DevOps öncesi dağıtım metrikleri zorluğu

TL; DR, nasıl yok kanıtlamak devops, özellikle dağıtım otomasyonu, değişim başarısızlık oranlarını artırır?

Hepimiz mevcut (çoğunlukla manuel) araçları kullanarak 'dağıtım hataları' ile ilgili metrikleri yakalamaya çalışıyoruz . Ne yazık ki, bir 'başarısızlık' nadiren olur, değil mi? Çünkü bir şeyler ters gittiğinde, takım sorunu çözmek için (genellikle kahramanlarla birlikte) bir araya gelir (genellikle izinler, kaçırılan yapılandırmalar, tatbikatı bilirsiniz). Yani ... konuşlandırmanın nasıl geçtiğini sorduğumuzda, cevap "işe yaradı".

Ancak, sezgisel olarak hepimiz bunun iyi olmadığını biliyoruz. Devops raporun 2017 devlet 31-45% hakkında var "diyor değişim başarısızlık oranı. " Hakkı konusunda içgüdüsel sesler, onlar olaylara olarak izlenir, ancak? Hayır. Çünkü genellikle doğrulama sırasında oldukça hızlı bir şekilde sabitlenirler. Bir konuşlandırmayı geri almak çok daha nadirdir.

Bu nedenle, başarısızlık oranlarının doğru bir şekilde raporlanması disiplini gerektirir. Bu şekilde rapor vermekten çekinmiyoruz çünkü bir şeylerin çalışmasını istiyoruz ve bunun gerçekleşmesi için gerekenleri yapıyoruz.

Peki, özellikle dağıtım otomasyonu için adanmışların değişiklik başarısızlık oranlarını nasıl artırdığını nasıl kanıtlarsınız?

(PS bunu "# devops-capability-model" ile etiketlemeye çalıştı)

Geçmişte benzer durumlarda kullandığımız bir teknik, her takım üyesine bu kuralları uygulayan "yönetim taahhüdü" elde etmektir:

1. Hedef dağıtım alanlarında (yani üretim) güncelleme gerçekleştirmek için erişim, yönettikleri alanlarda her türlü güncelleştirme için uygun denetim izlerine (= günlük kaydı) sahip olan seçilen otomatik sistemlerle sınırlıdır.

2. Her ne nedenle olursa olsun, hedef dağıtım alanlarında elle yapılan güncellemelere, bu güncellemeleri yapabilen (yetkili) tipik ekip üyeleri (kullanıcı kimlikleri) artık izin vermemektedir. Bunun yerine, gerektiğinde bu tür manuel güncellemeleri yapmak için (yine de) tüm izinlere sahip olacak YENİ (ek) kullanıcı kimlikleri oluşturulacaktır. Ancak bu yeni kullanıcı kimliklerini gerçekten kullanabilmek için (= onlarla bir oturum açma gerçekleştirin), bu tür yeni bir kullanıcı kimliğiyle oturum açmak isteyen ekip üyesinin, parolaya erişmek için "bazı" ek adımlar gerçekleştirmesi gerekir. böyle yeni bir kullanıcı kimliği. İdeal olarak bu ekstra adım da otomatiktir (nasıl göründüğü konusunda kendi hayal gücünüzü kullanın), ancak başka bir şey başarısız olursa: "hangi sorunla karşılaştıkları" da dahil olmak üzere gerekli şifrenin kapı bekçisiyle (yalnızca e-posta, çağrı vb. düzeltilmek "

3. Böyle bir kapı tutucunun yerine oturtulması kolay bir iş değildir. Ve en çok direniş ... ekip üyelerinden gelecek (her türlü nedenden dolayı). Bu nedenle, bu yeni kullanıcı kimliklerinin bir varyasyonu (önceki adımda olduğu gibi), her ekip üyesinin ekstra bir kullanıcı kimliği alması (kendilerine karar verdikleri şifre ile), ancak ek bir dize eklenmiş olmalarıdır: gerçekte bunun için iyi bir nedenleri varsa, bu (ekstra) kullanıcı kimliğiyle oturum açın. Her oturum açtıklarında, "düzelttikleri sorun" (sorunuza benzer) hakkında bir tür rapor sunmaları gerekir.

Bu prosedürler uygulandığında, tek yapmanız gereken bu raporların her birini / bu özel kullanıcı kimliğini kullanmanın neden gerekli olduğunu periyodik olarak gözden geçirmek ve " Bunu daha da otomatikleştirmek için yapılabilecek bir şey var mı? " böyle özel girişlere olan ihtiyacı daha da azaltır mı? "

Güncelleme :

Bu cevabın altındaki ekstra yorumunuzdan alıntı yapın:

Bir dağıtım sorununu gidermede yapay engeller eklemenin tersine etkili olduğunu düşünüyorum.

Doğru bir bariyer ekliyor, ama ben "yapay" suçlu değilim. Çünkü bu, bence, ekip üyelerinin başka türlü size söylemeyeceği şeylerden haberdar olmanın tek yolu, örneğin:

• iş güvenliği.
• saklamayı tercih ettikleri kötü şeyler / uygulamalar.
• güç kaybetmek istemiyorlar.

2017 devops durumu raporu yaklaşık% 31-45 "değişim başarısızlık oranı" olduğunu söylüyor. Bu sezgisel olarak haklı görünse de, olay olarak takip ediliyorlar mı? Hayır. Çünkü genellikle doğrulama sırasında oldukça hızlı bir şekilde sabitlenirler.

Hızlı bir şekilde çözülen bir sorun hala bir sorundur. Bunları bu şekilde bildirmiyorsanız, bu bir sorundur.

Bu nedenle, başarısızlık oranlarının doğru bir şekilde raporlanması disiplini gerektirir. Bu şekilde rapor vermekten çekinmiyoruz çünkü bir şeylerin çalışmasını istiyoruz ve bunun gerçekleşmesi için gerekenleri yapıyoruz.

Amacınız aslında işlerin işe yaramasını sağlamaksa, başarısızlıklarla ilgili dürüst olmanız gerekir, böylece gelecekte bunları önleyebilirsiniz. Buradaki takım başarısızlıklar hakkında yalan söylüyor (belki de kendilerine, kesinlikle yönetime) gibi görünüyor çünkü hedefleri bir şeyler çalışıyor gibi görünüyor .

Bunlar farklı şeyler. Örneğin, QA'nın hatalar ürettiği eski şakayı ele alalım - “QA onu alana kadar kodum iyiydi ve sonra tüm bu hataları yaptılar!”. Böcekler baştan beri vardı, ama geliştirici onlardan habersizdi. Bir operasyon ekibinin hedefi gerçek güvenilirlik olmalı ve yönetimi tarafından bu şekilde teşvik edilmelidir. Bu, yeni sorunların keşfedilmesine yol açan daha fazla izleme koyarlarsa, güvenilirlik metriklerindeki sonraki düşüş için cezalandırılmamalı, ödüllendirilmeleri gerektiği anlamına gelir.

TL; DR, adanmışları, özellikle dağıtım otomasyonunu nasıl değiştirirsiniz?

Kuruluşunuzdaki değişimi motive etmeye çalışıyorsanız, hiçbir şey kanıtlamaya çalışmamalısınız, ancak diğer kuruluşların kendi geçişleri hakkında söylediklerinin kanıtını sunmalısınız. Halihazırda uyguladığınız süreçleri ölçmeye ve varlığını sürdürmeyi haklı çıkarmaya çalışıyorsanız, ortalama onarım süresi (MTTR) gibi standart güvenilirlik metriklerini izlemelisiniz.

Ancak devops ilkeleri yalnızca güvenilirliği artırmakla ilgili değildir. Site güvenilirliği mühendisliği bile sadece güvenilirliği artırmakla ilgili değildir. Aksine, uygun bir güvenilirlik düzeyine ulaşmak istiyorsunuz - bu, işletmeye yarar sağlayan, ancak gelişimi engellemeyen bir şey. Ve bu, değişimleri güçlendirmek için adanmışlardaki gerçek motivasyonu artırır . Kabul edilebilir bir güvenilirlik sınırında kalırken, işletmenin geliştirici sürtünmesini azaltarak, dağıtım oranını artırarak, manuel işlemleri otomatikleştirerek vb. Bu, güvenilirliği ölçmeniz gerektiği anlamına gelir, ancak aynı zamanda hızı da ölçmeniz gerekir, çünkü amacınız birincisini nispeten statik tutarken ikincisini artırmaktır.