DevOps için YG'yi ölçmenin bazı yöntemleri nelerdir?

DevOps karmaşıktır ve kültür ve süreç gibi deterministik olmayan birçok yönü içerir.
DevOps girişimlerini başarı için ölçmenin bazı yolları nelerdir?
Bir işletmeye yaptıkları yatırımın gerçek paraları iade ettiğini (veya biriktirdiğini) nasıl kanıtlarsınız?

Harika soru! Birçoğumuz DevOps uygulamalarına yatırım yapmanın, sayısız sebeplerden dolayı oldukça değerli bir arayış olduğunu biliyoruz; Bununla birlikte, DevOps'u yalnızca sonuçta ortaya çıkacak etki üzerine haklı çıkarmayız.

Not : Bu, tartışılan bir sorudur ve cevabım da aynı şekilde tartışılmıştır.

Tensibai akıllıca doğru ölçümleri bulmamızı önerdi ve pazara çıkış zamanını örnek olarak kullandı. Bu harika bir büyük resim yaklaşımı.

Alternatif bir yaklaşım olarak, fasulye sayaçlarıyla olan deneyimim, büyük resmi bilmek zorunda olmadıkları ya da zorunlu olarak bilmek istedikleri, sadece mali sorumluluk kanıtı istedikleridir. Doğru yönde bir eğilim görmek istiyorlar.

İşte birkaç mali kazanç:

• Bulutta otomatik ölçeklendirmeyi kullanarak tasarruf edilen sunucu maliyetlerini hesaplayın
• Gelir getirici siteler için, duruş süresinin dakikası başına maliyetini tahmin edin, ardından MTTI ve MTTR’de iyileştirmeler gösterin
• Yine, gelir getirici siteler için, geçmiş olaylara dayanarak yüksek oranda kullanılabilir mimariden yararlanarak elde edilen dakika başına maliyeti tahmin edin.
• yapı ve dağıtım hattınızı geliştirdiyseniz, izlenen hatalardan kaynaklanan üretimdeki gerilemeleri ve hataları azalttığınızı gösterin
• geliştirici test ortamlarında, hatta geliştirici dizüstü bilgisayarlarındaki araçlar ve konfigürasyonda iyileştirmeler yaptıysanız, yeni mühendislerin katılmadan hemen sonra ilk katkılarını yapıp yapmadıklarını görmek için taahhüt geçmişlerine bakın.
• Altyapı harcamalarınızı haklı çıkarmak için bulut ve şirket içi arasında tam bir maliyet karşılaştırması yapın ( Gitlab’ın son zamanlarda yaptığı gibi ).

Para bilincinde olduğunuzu ve birkaç açık kazancınız olduğunu göstermek genellikle yeterlidir. Bazı açık örnekleri kesinlikle kaçırdım; Aşağıya yorum eklemek için çekinmeyin.

Bir DevOps boru hattının temel metriği Döngü Süresidir ( Kurşun Süresi de denir ). Bu bir değişimin (veya bir değişim isteğinin, fikrin başlangıcına kadar olan yolu takip etmesinin) zamanıdır. Bu kavramın en iyi örneklerinden biri, üretim bağlamında bahseden "Hedef" kitabından.

Dağıtım Frekansı da yararlıdır. DevOps boru hattında dağıtımların sık olmasını istiyoruz. Büyüleyici "1 gün iyi, 2 gün kötü" ölçüsü yoktur; Bunun anlamlı olması için projenizin tarihsel bir bağlamına ihtiyacı olacaktır.

Dağıtım Boyutu : Geliştiricileriniz iş ölçütlerini - kullanıcı hikayelerini, hikaye noktalarını, quatloos'u ne olursa olsun ölçtüler. Yine, zaman içinde mutlak değer değil eğilimleri görmek istersiniz.

Frekans ve boyut arasında anlatılacak bir hikaye var. Bültenlerimiz daha seyrekleşiyor ve büyüyor mu? niye ya? Daha küçük ve sık mı hale geliyorlar? Yine neden?

Frekans / boyut eğiliminin iyi olup olmadığını açıklayarak , Başarısız Uygulamaların Yüzdesine de ihtiyacımız olacak . Bu üç ölçümde 'neden'i ortaya çıkarmak size projenin sağlığı hakkında çok şey söyleyecektir.

Kişisel favorim, küçük bir ölçü birimi olmasına rağmen, Önemsiz Bir Konuşlandırma Zamanı . Tüm siteyi yeniden dağıtmaya değecek en küçük şeyi bulursanız ... belki de CEO adına bir yazım hatası ... panik telefon görüşmesinden konuşlandırılmış bir siteye ne kadar çabuk gidebilirdiniz? 'Vanity' diyorum, çünkü yukarıdaki diğer metriklerin tartıştıklarının ötesinde bir o kadar da öngörücü değil, ancak değeri sevdiğimde kendimi iyi hissettiriyor.

Eğer izlemeye başlarsak, ' Uptime ' gibi her şeyi kapsayan şeylerden , istek-cevap döngüsünde özel HTML yenilemek için harcanan zaman gibi gerçekten düşük seviyeli şeylere kadar izleyebileceğimiz bir sürü farklı şey var ... fakat bunlar bir DevOps kültürü kurmaya özel değil.

Bunlar doğrudan dolara bağlı değil ... bu yüzden böyle bir forumda önerebileceğimden daha fazla bilgi sahibi olmalısın; fakat onlar bu soruyu cevaplamak için BEGIN'in anahtarıdır. Çalışmayı düzenli olarak prodüksiyon dışı bir etkinlik olarak serbest bıraktığınızı öğrendikten sonra, daha önce ne kadar çaba harcadığınızı görmeye başlayabilirsiniz. "Hedef" adlı kitabın öğrettiği gibi (boru hatlarının üretimi hakkında - bununla alakalı), yerel olarak optimize etmek , para biriktirdiğiniz gibi görünebilir , ancak sonuçta, envanterde (işsiz özellikler) bağlanmış değer yaratır.

Bu tavsiyenin ötesinde , son birkaç yıldaki DevOps Eyalet Raporuna bir göz atmalısınız . Bu, taklit edebileceğiniz gerçek dünya projeleriyle ilgili ölçümlerle dolu.

Kaptan apaçık: piyasaya çıkma süresini azaltarak ve piyasaya çıkan kusurları.

Bu astarı genişletmek için, normal tuzak referanssız bir organizasyon değişikliğidir.

Bir kültür veya organizasyon değişikliğini yapmak, insanları eğitmek ve bu yeni yöntemle tanıştırmak için bir miktar masrafa yol açıyor, bunun eğitim için bir maliyeti var ama aynı zamanda bir tren oturumundaki insanlar hiçbir şey üretmeyeceğinden üretkenlik kaybı anlamına geliyor. Bu kültürel değişimin yatırım kısmıdır.

Bir YG'yi ölçmek için önce iyileştirilmesi gereken bazı alakalı ölçümleri bulmanız gerekir (pahalı, pahalı veya kar kaybı kaynağını anlayın). Bu, piyasaya sürülmek için daha kısa bir süre olabilir, her sürümden sonra daha az düzeltme eki, ürününüzde daha iyi bir müşteri etkileşimi olabilir. Alakalı metrikler ürünlerinize büyük ölçüde bağımlı olacaktır.

Bir YG'yi ölçmek (eğitim giderini ne kadar hızlı karşıladığınız), bu ölçümler üzerinde bir evrim sunabileceğinizi gösterir, bu nedenle herhangi bir değişiklik yapmadan önce bu ölçümleri tanımlamanız ve bunları nesnel bir şekilde ölçmeniz gerekir.
Gösterecek gerçek bir evrim geçirdikten sonra, eğitim masraflarını karşılayacak ve daha önce olduğundan daha karlı hale gelebilecek bir şeyi iyileştirip geliştirmediğinizi anlayabilirsiniz.

Her zamanki tuzak, herhangi bir ölçümü tanımlamadan önce değişimi yapmak ve böylece yatırım getirisini gerçek veriler üzerinde değil bir his üzerinde değerlendirmektir.

Verimlilik bir metrik olabilir, ancak ölçümü genellikle nesnel bir şekilde yapılması çok zordur ve bu tür bir çalışma için birinci sınıf bir ölçüm olmamalıdır.

Oyuna geç kaldım ama içeri gireceğimi düşündüm.

Ölçemediğiniz şeyi yönetemezsiniz, bu nedenle yeni başlayanlar için, ekiplerin olay yanıtı için izlemesi gereken kilit ölçütler şunlardır:

• Çalışma süresi% : toplam sürenin% 'si = [toplam süre - aksama süresi] / [toplam süre]
• MTTR : ortalama çözülme süresi = [kesinti süresi] / [# olay]
• MTTA : Ortalama onay süresi = [onay toplam süresi] / [olay sayısı]
• MTBF : arızalar arası ortalama süre = [toplam süre - aksama süresi] / [olay sayısı]

Bu ölçütler, operasyonlarınızın üst düzeyde sağlık kontrolünü sağlar ve daha fazla nereye girmeniz gerektiğini belirlemenize yardımcı olur.

Konuyla ilgili daha ayrıntılı bir görünüm için beyaz tahta animasyonuna bir göz atın .

Metriklerinizi bildikten sonra , çalışmama süresinin maliyetine karşı onları artırabilirsiniz . Takımınızın yatırım getirisini oradan oluşturmaya başlayabilir ve sürekli iyileştirme için bazı nicel ölçümler belirleyebilirsiniz.