Bir DevOps ekibinin eksik istihdam edilmesinin tipik işaretleri ve sinyalleri nelerdir? Bir ekibe yeni ekleme isteğini nasıl haklı çıkarır / açıklarsınız?

Soruyu genel tutmayı çok isterim, ancak bazı ek bilgiler:

Şu anda bir ekip olarak birlikte çalışan 2 DevOps uzmanımız var, ancak ürünlerin talepleri ve miktarı ve karmaşıklığı artıyor. Ekibe yeni bir ek talep etmeyi düşünüyoruz, ancak bunun neden iyi bir fikir olacağını açıklamak ve kanıtlamakta bazı zorluklar yaşıyoruz.

Ekibinizin yetersiz olduğunu hissetmenizin dört ana nedeni vardır :

1. Kötü organizasyon ve iş planlaması
2. Başka birinin işi yapması gerekir
3. Hiç yapılmaması gereken işler yapmak
4. Aslında yetersiz personel olmak

İlk üç noktayı inceleyerek başlayın. İlkinin nasıl yapılacağı hakkında fikirler için Phoenix Projesi'ni okuyun . Kendinize kimseye yardım etmeniz gereken her görevi, hiç yapılması gerekip gerekmediğini ve görevi gerçekleştirecek olan sizseniz veya kendisinin yapması gereken her şeyi etkinleştirmeniz gerekip gerekmediğini sorun. Bu, yaptığınız tüm işlerin neden gerekli olduğuna dair bazı belgeler verecektir.

Ardından, Phoenix projesinde belirtilen dört çalışma türünü gözden geçirin:

1. İş Projeleri - organizasyondaki diğer ekipler için yaptıklarınız
2. Dahili Projeler - gelecekte işinizi kolaylaştırmak için yaptıklarınız
3. Programlı Bakım - ışıkları açık tutmak için ne yaparsınız?
4. Planlanmamış Kesintiler - bir şeyler ters gittiğinden ne yaparsınız

Ekibinizin çalışması sürdürülebilirse, dört kişiden birine yaklaşık aynı miktarda zaman harcayacaksınız. Planlanmamış çalışma zamanınızın% 50'sine yakın bir hızda kaymaya başlarsa, kesinlikle yetersiz kaldığınızın bir işaretidir.

Zamanınızın% 25'ine ulaşan planlanmamış işin önünde yaklaşık bir kişi kalmak için kiralayabilmeniz gerekir, aksi takdirde ayrılan bir kişi tüm ekibinizi asla kurtaramayacağınız bir kuyruk noktasına gönderir. İnsanların ve teknolojinin aşırı sağlanması, aynı nedenlere ve faydalara sahiptir.

Arka Plan: Mevcut altyapımıza ve Geliştiricilerimize destek sağlamanın yanı sıra, sprint'lerdeki dev ekiplere ve başlatılan yeni projelere yardımcı olmak için bir DevOps ekibi olarak aylık planlama yapıyoruz. Bununla birlikte, ay boyunca sık sık yapılması ve geliştirilmesi gereken ekstra şeyleri fark ederiz, bu da daha sonra biriktirme işlerimize ekleriz. Ayrıca, kapsamımızın ötesine geçen çeşitli diğer şeylerden de sorumluyuz ve yardımcı oluyoruz, ancak işimize yardımcı olabiliriz :)

Cevap : Özellikle bakım başta olmak üzere pek çok görevi tamamlamadığınızı veya ertelemediğinizi fark ettiğiniz anda, bunun iyi bir gösterge olduğunu düşünüyorum (yaşadıklarımdan). Ayrıca, DevOps ekibinin inceltilmesiyle daha fazla yeni proje ve geliştirme ekibi yayılır, daha fazla insana ihtiyaç duyarsınız.

Sadece görevleri tamamlayarak günlük yakalamak için süper kolay, ama bir adım geri almak ve bunu değerlendirmek için süper önemli (ayda bir kez) inanıyorum.

Aslında bu konuda SRE El Kitabı'ndan çok alakalı olduğunu düşündüğüm bir sayfa alıyorum. DevOps spesiyaliteleri bir organizasyonla yatay olarak büyümek için tasarlanmamıştır. Daha ziyade, işlerin yapılmadığını görürseniz, geliştiricilere self servis için düzgün bir şekilde yetkilendirmediğinizin bir işaretidir.

Süreçlerinizi değerlendirin ve yaygın olarak kabul edilen DevOps İlkelerine nasıl uyum sağladıklarını ve sektörün en iyi uygulamalarını ne kadar iyi takip ettiğinizi görün.

İki kişilik bu ekibin projeden projeye gideceğini ve orada DevOps öğeleri oluşturduğunu varsayıyorum (CI / CD boru hatları oluşturma, Dockerfiles oluşturan diğer geliştiricileri destekleme veya hangi teknolojiyi kullanırsanız kullanın). Başka bir deyişle, http://web.devopstopologies.com/ uyarınca 3, 4, 5 veya 6 yazın .

Bu durumda, bir eksiklik işareti bu ikisi için çok fazla iş yüküdür; hizmetlerini isteyen çok fazla proje; çok fazla bilet; mesai; stres, tükenmişlik. Bu faktörler, sorumlu bir liderliğin daha fazla kapasite katması için yeterli neden olmalıdır. Bu bir DevOps özel işareti görmüyorum, bu sadece yetersiz bir işlevdir.

Bir şeyi değiştirmek için başka bir işaret, iyi bir sert görünüm alırsanız ve tüm DevOps bilgilerinin bu iki adam / gals'ta yoğunlaştığı ve diğer herkesin geriye yaslandığı bir "DevOps silo" oluşturduğunuzu fark ederseniz. bu ikisi "DevOps yapıyor". DevOps'un amacı bu değil. Eğer durum buysa, kültürel yönü düşünün ve diğer takımlar için daha fazla evangelist / öğretmen / koç olacak şekilde değiştirin.

Her iki durumda da, DevOps'un ilk etapta olmasının neden daha derin bir nedeni (genel İyi Şeyler) üst yönetime açık olmalıdır. Bu iletiyi bir araya getiremezseniz, ekibinizin yaptığı işi düzenli Devs / Ops'a kaydırarak ölçeklendirin (her durumda olduğu gibi).

DevSecOps'un bir takım değil bir zihniyet olduğu izlenimindeydim - eğer bir Dev (Sec) Ops "ekibine" sahipseniz, yanlış yapıyorsunuz ... Başımı iki "DevOps Mühendisi" ve onlara "DevOps Ekibi" diyoruz.

Kod ve yapılandırma / sistem değişikliklerini belirli bir bitiş noktasına (aşamalandırma veya üretim) aktarmak için hızlı bir dağıtım / yayınlama modeli için birlikte çalışan geliştirme ekiplerimiz, SCM, Uygulama Güvenliği ve Sistem Mühendislerimiz var.

Bunun herhangi bir "devOps" mühendisiyle hiçbir ilgisi yoktur.

Görevlerin gruplandırılması

Geçmişte benzer durumlarda kullandığımız bir yaklaşım, bir ekibin çalışmasını 4 ana görev grubunda organize etmek ve 2 FTE (Tam Zamanlı Eşdeğeri) eşdeğerini bu görevleri tamamlamak (denemek) için tahsis etmektir. Bizim durumumuzda, ana bilgisayar ortamında bir SCM yardım masası yürütmekle ilgiliydi, yaklaşık 300 geliştirici bu 2 FTE'den her türlü yardım / müdahaleyi istedi. Görev grupları 4 olası öncelikte düzenlenmiştir:

• Öncelik 1 ve 2'nin Görevleri gerekir (hiçbir mazeret / müzakerelerin mümkün) tamamlanacak
• Öncelik 3 görevler "tamamlanmak üzere olan en kısa sürede zaman izni".
• Öncelik 4 görevleri " zaman izin veriyorsa " tamamlanmalıdır .

Bu 4 grubun her birindeki görev türleri hakkında daha fazla bilgi için okumaya devam edin ...

Görev açıklamaları

Öncelik 1 - Yardım masasını çalıştırın

• Kolayca erişilebilen ve her zaman ulaşılabilir olan uzmanlar tarafından.
• Çalışma saatleri içinde telefon, e-posta veya bilet sistemi aracılığıyla.
• Önceden tanımlanmış SLA'lar ile uyumludur.
• Tüm çağrıların periyodik raporlaması ile tüm yardım masası çağrılarının ITIL tabanlı kaydı.
• Kritik sorunlar için acil durum özelleştirmeleri (geçici çözümler) uygulayın.

Öncelik 2 - İzleme görevi hizmetleri

• 24 saat / gün, haftada 7 gün çağrı.
• Önceden tanımlanmış SLA'lar ile uyumludur.
• Tüm saat görevi çağrılarının raporlanması.
• Gerektiğinde yönetimin artması.

Öncelik 3 - Rutin bakım

• İdaresi.
• Uygulama yatılı.
• Kat.
• Performans geliştirmeleri.
• Alan yönetimi.
• Kaynak tüketiminin ayarlanması.
• Yardım masası çağrılarının sayısını ve / veya nöbet görevlerini azaltmak için özelleştirmeler için geliştirmeler önerin.

Öncelik 4 - Düzeltmeler ve geliştirmeler

• Kullanıcı belgeleri oluşturun ve bakımını yapın.
• Yeni özelleştirmelerin KG testi.
• Geliştirme taleplerini geliştirmek ve uygulamak.
• DRP testine katılın.

Değerlendirme

Yukarıda açıklandığı gibi bir yaklaşım kullanıyorsanız, çeşitli şeyler olmaya başlayabilir (olacaktır!):

• Ekibin yetersiz kalması durumunda, büyük olasılıkla çoğu zaman öncelik 1 ve 2 görevlerine giderken, öncelik 3 görevlerinin alınması biraz zaman alabilir ... ve öncelik 4 görevleri açlıktan muzdarip olabilir ( bu görevler).
• Öncelik 4 görevlerine " yatırım yapmak " için daha fazla zaman kalırsa, öncelik 1 ve 2 görevleri için daha fazla zaman azalır, böylece daha fazla zaman (2 FTE'nin mevcut bütçesinden) "yatırım yapılabilir" "öncelik 4 görevlerinde.
• Bir süre sonra öncelik 1 ve 2 görevlerinin sayısının nasıl düşeceğine şaşıracaksınız. Ve bu görevler hakkında yeterli raporlama yaparsanız, bu yönetimin duymayı sevdiği bir şeydir. Bizim durumumuzda bu sayı yaklaşık 300 / aydan 100 / ay'ın altına düştü ...
• Bununla birlikte, 2 FTE'nin öncelikli 4 görevler için hiçbir zaman (veya neredeyse hiç) zamana sahip olmadığı görülüyorsa, yönetiminiz için yetersiz bir açıklama ve kanıtınız vardır.