Dürüst olmak gerekirse Ivan, izleme departmanındaki meslektaşlarının nafile çabalarına sık sık gülüyordu. Şirket yönetiminin onlara ulaşmalarını emrettiği ölçümleri uygulamak için büyük çaba harcadılar. O kadar meşguldüler ki, kimsenin bir şey yapmasını istemiyorlardı.
Ancak bu yönetim için yeterli değildi; sürekli olarak daha fazla yeni ölçüm sipariş ettiler ve daha önce yapılmış olanı kullanmayı çok hızlı bir şekilde bıraktılar.
Son zamanlarda herkes LeadTime'dan, yani iş özelliklerinin teslim edilmesinden söz ediyor. Metrik çılgın bir sayı gösteriyordu: Bir görevi tamamlamak için 200 gün. Herkes nasıl da ıslık çaldı, aah dedi ve ellerini gökyüzüne kaldırdı!
Bir süre sonra gürültü yavaş yavaş azaldı ve yönetim başka bir ölçüm oluşturma emri aldı.
Ivan için yeni ölçünün karanlık bir köşede sessizce öleceği tamamen açıktı.
Gerçekten de Ivan, numarayı bilmenin kimseye bir şey ifade etmediğini düşündü. 200 gün veya 2 gün - hiçbir fark yoktur çünkü sayıya göre sebebini belirlemek ve iyi mi kötü mü olduğunu anlamak imkansızdır.
Bu tipik bir metrik tuzağıdır: Öyle görünüyor ki yeni bir metrik varoluşun özünü anlatacak ve bazı gizli sırları açıklayacak. Herkes bunu çok umut ediyor ama nedense hiçbir şey olmuyor. Evet çünkü işin sırrı metriklerde bulunmamalı!
Ivan için bu geçilmiş bir aşamaydı. Bunu anladı ölçümler için ve tüm sırlar aranmalıdır , yani bu metriğin oluşturulmuş olmasıdır.
Bir çevrimiçi mağaza için etki nesnesi, para getiren müşterileri olacaktır ve DevOps için, bir dağıtım hattı kullanarak dağıtımlar oluşturup dağıtan ekipler olacaktır.
Bir gün salonda rahat bir sandalyeye oturan Ivan, etki nesnesinin ekipler olduğu gerçeğini hesaba katarak DevOps metriklerini nasıl görmek istediğini dikkatlice düşünmeye karar verdi.
DevOps Metriklerinin Amacı
Herkesin teslimat süresini kısaltmak istediği açıktır. 200 gün elbette iyi bir şey değil.
Ama nasıl, soru bu mu?
Şirkette yüzlerce ekip çalışıyor ve her gün binlerce dağıtım DevOps hattından geçiyor. Gerçek teslimat süresi bir dağıtım olarak görünecektir. Her takımın kendine ait zamanı ve kendine has özellikleri olacaktır. Bu karmaşanın içinde nasıl bir şey bulabilirsin?
Cevap doğal olarak ortaya çıktı: Sorunlu ekipleri bulmamız, onlara neler olduğunu, neden bu kadar uzun sürdüğünü anlamamız ve "iyi" ekiplerden her şeyi nasıl hızlı bir şekilde yapacağımızı öğrenmemiz gerekiyor. Bunu yapmak için ekiplerin DevOps standlarının her birinde harcadığı süreyi ölçmeniz gerekir:
"Sistemin amacı takımları tribünleri geçme sürelerine göre seçmek olacak. Sonuç olarak, bir sayı değil, seçilen zamana sahip bir komut listesi almalıyız.
Toplamda tribünlerde ne kadar vakit geçirildiğini, tribünler arasında ne kadar zaman harcandığını öğrenirsek ekipleri bulabilir, arayabilir ve nedenlerini daha detaylı anlayıp ortadan kaldırabiliriz” diye düşündü Ivan.
DevOps için Teslim Süresi Nasıl Hesaplanır?
Bunu hesaplamak için DevOps sürecini ve özünü derinlemesine incelemek gerekiyordu.
Şirket sınırlı sayıda sistem kullanıyor ve bilgi yalnızca onlardan alınabiliyor, başka hiçbir yerden alınamıyor.
Şirketteki tüm görevler Jira'ya kayıtlıydı. Bir görev üstlenildiğinde bunun için bir dal oluşturuldu ve uygulama sonrasında BitBucket ve Pull request'e commit yapıldı. Bir PR (Çekme İsteği) kabul edildiğinde, otomatik olarak bir dağıtım oluşturuldu ve Nexus deposunda saklandı.
Daha sonra dağıtım, otomatik ve manuel testlerin doğruluğunu kontrol etmek için Jenkins kullanılarak çeşitli standlarda kullanıma sunuldu:
Ivan, tribünlerdeki süreyi hesaplamak için hangi sistemlerden hangi bilgilerin alınabileceğini anlattı:
- Nexus'tan – Dağıtımın oluşturulma zamanı ve komut kodunu içeren klasörün adı
- Jenkins'ten – Her işin başlangıç zamanı, süresi ve sonucu, stand adı (iş parametrelerinde), aşamalar (iş adımları), Nexus'taki dağıtıma bağlantı.
- Ivan, Jira ve BitBucket'i projeye dahil etmemeye karar verdi çünkü... bunlar daha çok geliştirme aşamasıyla ilgiliydi ve bitmiş dağıtımın stantlarda yayınlanmasıyla değil.
Mevcut bilgilere dayanarak aşağıdaki diyagram çizildi:
Dağıtım oluşturmanın ne kadar sürdüğünü ve her birine ne kadar zaman harcandığını bilerek, DevOps hattının (tam döngü) tamamının toplam maliyetini kolayca hesaplayabilirsiniz.
İşte Ivan'ın elde ettiği DevOps metrikleri:
- Oluşturulan dağıtım sayısı
- Standa “gelen” ve standı “geçen” dağıtımların payı
- Standda geçirilen süre (duruş döngüsü)
- Tam döngü (tüm standlar için toplam süre)
- İşin süresi
- Tribünler arası kesinti
- Aynı standda iş lansmanları arasındaki kesinti
Bir yandan ölçümler DevOps hattını zaman açısından çok iyi karakterize ederken diğer yandan çok basit kabul ediliyordu.
İyi yapılan işten memnun kalan Ivan bir sunum yaptı ve bunu yönetime sunmaya gitti.
Kasvetli ve elleri aşağıda geri döndü.
İronik meslektaşı "Bu bir fiyasko, kardeşim," diye gülümsedi...
Makalede daha fazlasını okuyun “'.
Kaynak: habr.com