DevOps'u ölçmek için hangi Anahtar Performans Göstergeleri (KPI'lar) kullanılır?

Ben operasyon disiplinleri etrafında eyleme geçirilebilir metrikleri tanımlamak için, bunu desteklemek için bir DevOps dönüşüm programı içinde iyi davranışlar sürücü çalışıyorum:

• Sorun ve Olay Yönetimi
• Kapasite yönetimi
• Değişim ve Sürüm Yönetimi

Kesinlikle açık olmak gerekirse, bunlar operasyonlar organizasyonuna ait olan ve şimdi Agile / DevOps organizasyonuna ait olan işlevlerdir. Kötü davranışlar yaratan mevcut KPI'lar vardır:

• Kök Zaman Nedeni Analizi tamamlandı:
  • Eksik RCA'ları zamanında sisteme almak için kullanıyor.
• Test yürütme süresi:
  • İşletme değerine bakılmaksızın uzun süren testleri devre dışı bırakır.
• Bulut hizmetlerinin ortalama kullanımı:
  • Hesaplama kaynaklarının aşırı bağlılığını teşvik ederek yavaş yanıt sürelerine neden olur

Bir DevOps Programında iyi davranışı teşvik etmek için hangi Anahtar Performans Göstergeleri kullanılabilir?

"Evrensel" DevOps KPI'ları olduğunu düşünmüyorum. Örneğin, işiniz için önemli bir sürücü olmadıkça hız harika. Amazon, devasa bir perakende operasyonuna sahip oldukları için hıza çok önem veriyor. 100 kullanıcılı küçük bir uygulama için bu daha az önemli.

Nasıl yok: Bu soruyu akla sen ilgili en iyi temel seçmek sizin iş? Bu, tüm Kuruluşunuzu kapsayan bir araştırma ve keşif sürecidir.

Ne önemsiyorsun?

• Kalite
• Güvenilirlik
• İdame
• hız
• Süreç geliştirme
• Hizmet Seviyeleri

İş paydaşlarınızı gece ne tutar? Bu çeyrekte para kazanıp kazanmayacağınızı ne belirler? Yukarıdaki liste bu şeylerden bazılarını içerebilir veya içermeyebilir. Listenizi oluşturun, ardından teşvikleri her departmana nasıl ulaştırdığınızı öğrenin .

Teşvikler davranışı yönlendirir, bu nedenle SMART hedeflerine birlikte karar verin. Beyin fırtınası listenizden iki veya üç öğe seçin ve her biri için bir ölçüm / düzeltme geri bildirim döngüsü başlatın. Bir seferde çok fazla seçim yapmayın - iki veya üç şeye odaklanarak başarılı olma olasılığınız daha yüksektir.

DevOps hiç yok KPI . Sevgi KPI'sının ne olduğunu sormak gibi bir şey olurdu. Ancak, bahsettiğiniz bazı şeyler ( Sorun ve Olay Yönetimi , Kapasite Yönetimi , Değişim ve Serbest Bırakma Yönetimi ), bazıları DevOps'un arkasındaki teoriye dayanan iyi KPI'ya sahiptir.

Genel olarak, herhangi bir iş süreci için, bir oluşturabilirsiniz Harita Değer Zincirini değeri akar nasıl açıklayan Müşteriye kurumsal Arka taraftan, Müşteri . Döngünün tamamı her zaman Müşteri ile başlayıp bitmelidir, ancak bazen bir hizmet kuruluşu için Müşteri dahili olabilir. Değerin üretilen iş böyle zinciri boyunca kurcalamaya dayanıklı bir şekilde KPI tasarlamak için iyi bir yol olabilir. Değer zincirinin herhangi bir bağlantısında herhangi bir KPI ölçmek, yalnızca söz konusu bağlantı sürecin darboğazı olduğu ve darboğazdan yararlanmaya veya yükseltmeye çalıştığınız sürece mantıklıdır .

KPI ile ilgili yaygın bir sorun, zincirin yarısından başlamasıdır. Örneğin, bir Değişiklik ve Yayın süreci genellikle geliştiricilerle başlar ve dağıtımla sona erer. Bu işlem hariç tutuldu:

• Müşteri bir sorun yaşıyor
• Sorunları belirleyen destek ekibi
• Biriktirme listesi sorununu tanımlayan ürün ekibi
• Müşteri için konuşlandırmayı özelleştiren çözümler ekibi
• Çözümden değer alan müşteri

Sorun şu ki, tek başına bir döngü süresinin ölçülmesi iki önemli soruna yol açabilir:

1. Darboğaz, yukarıda belirtilen hariç tutulan bölümlerin herhangi birinde yer alır ve müşterileriniz değeri fark etmez ve geliri döngü sürenizin hızıyla orantılı olarak gerçekleştirmezsiniz. Bu yüzden mühendisliğiniz mükemmel olsa da, işiniz acı çekiyor.

2. Müşterilerin bağlantısının kesilmesi, serbest bırakma döngünüzün boş olmasına neden olur - değişiklik yapılmasına rağmen herhangi bir değer üretmez - hatta Müşterilerinizin ihtiyaçlarını karşılar ve yapılan işin olumsuz iş değeri olabilir.

KPI ile ilgili bir başka sorun, bir müşteriyle başlarken ve biterken müşteriye gerçekte değeri ölçmeyebilmesidir. Buna iyi bir örnek Problem ve Olay Müdahale süreci ve KPI olarak MTTR (Ortalama Tamir Süresi) olacaktır. Sorun kimseyi etkiliyor mu? Müşterilerin değeri nedir? 100 vakada 3 saatlik mükemmel MTTR'ye sahip olabilirsiniz. Ancak bunların çoğu dahili, müşteriler üzerinde hiç etkisi olmayan veya çok az etkisi olan ve dakikalar içinde çözülmüşse, büyük müşteri etkisi olan büyük bir olayın ele alınması 3 gün sürdü, iş değeri 1 günlük MTTR'nizden daha düşüktür, çünkü dahili olayların çoğunu yok sayın, ancak büyük müşteri etki olayına 1 saat içinde yanıt verdiniz.

NOT: Dahili bir müşteri için, destek ekibi iş süreci durumunda, elde edilen değer, dahili müşteriye yapılan işin değeri değil, şirket tarafından dahili müşterinin kendi iş süreçlerinde engellemesini kaldırmada kazandığı değerdir. Kendi süreçlerinde darboğaz olan bir takımın engelini kaldırmak, darboğazlı olmayan bir takımın veya bireyin engellemesini kaldırmaktan daha yüksek bir değer sağlar. Bu tür destek ekibinin tüm KPI'larının, hesaplamalarına işletme değerini dahil etmesi gerekir.

1. Dağıtım sıklığı
2. Dağıtım hızı
3. Dağıtım başarı oranı
4. Başarısız bir dağıtımdan sonra hizmet ne kadar çabuk geri yüklenebilir
   Ve son olarak,
5. Aslında ölçülemeyen DevOps Kültürü