Devops Metrikleri nelerdir Dora ve Agile Metrik Neden Önemli
Klasik bir SDLC sürecinde(Waterfall) metrik ve KPI açısından IT yöneticilerinde, geliştiricilerinde , iş birimlerininde işi nispetten daha kolaydı. Bir proje planı yapılır bu plan içinde analizin nezaman başlayacağı nezaman geliştirme yapılacağı ve testlerin ve canlı ortama alınmanın nezaman olacağı net tarihler olarak yazılır herkes bu hedefe koşmak için çalışmalara başlardı
Üç aylık bir proje öngörülmüş ise iş birimi taleplerinin toplanması ,analiz süresi , kaç kaynak ile geliştirmenin ne sürede biteceği , test ve bug çözme süresi ve son olarak canlı ortama alınma tarihi bir proje yönetiminin ve proje metriklerinin ana konusuydu. Stratejiyi belirleyen organizasyonun yöneticileri, proje yönetimi ve it yöneticileri bu metriklere odaklanır ve başarıya ulaşmaya çalışırdı
Bu yazımızın konusu değil ama zamanla waterfall modeldeki eksiklikler bu klasik bakış açısından bizi uzaklaştırmaya başladı. Kısaca özetlersek tek bir canlıya alım sonrası organizasyonun stratejisine uygun bir projeden tamemen farklı bir proje geliştirildiği gözlemlendi . Örneğin 3 yıllık bir proje planında başarıyla bitirilmiş bir proje canlıya alındığında değişen şartlar (pandemi, ekonomik koşullar, teknoloji vs) nedeniyle artık başarısızdı. Bu noktada Agile kavramı sıklıkla duyar olduk. Özelliklede son 10 yılda birçok kurumun agile geçişde başarı hikayelerini okuduk.
Çevik yaklaşımlar bize daha sık deploy yapmaya ve geri bildirim almaya itti. Buda doğal olarak devops yaklaşımlarını ve araçlarının popüler olmasını vewglişmesinin önünü açtı
Proje yönetimi metriklerinden devops metriklerine geçiş
Günümüzde devops ekiplerinin, bir organizasyonun bel kemiği olduğu artık yadsınamaz bir gerçek. Ufak yada büyük bir organizasyon olsun çevik metodolojiler kullanıyorsanız sprint sonu geliştirmelerimizi canlı ortama alıyor olmamız gerekiyor. Artık 3 aylık bir analizden bitime kadar bir projemiz yok. 2–3 haftalık sprintler ile geliştirme tamamlayıp canlı ortama aldığımız uygulamalar var. Bu durumda proje yönetimindeki metrik ve KPI kavramlarımız tamamen değişiyor. Hala kaynak/maliyet metrikleri önemli iken artık çevik yaklaşımlar bize yeni sorular sorduruyor.
- Ne sıklıkla canlı ortama uygulamalarımızı alıyoruz ve düşündüğümüz kadar çevikmiyiz? Nasıl daha çevik olabiliriz
- Canlı ortama aldığımız uygulamalarımızı başarılı bir şekilde canlı ortama alabildik mi ? Hatalarımızı ne sürede düzeltebildik?
- Başarılı olarak canlı ortamda isek bunu nekadar sürede yapabildik?
- Bir proje talebini nekadar sürede bitirdik ve tüm talepleri proje sonunda canlı ortama alabildikmi ?
Dora Metrik
Gene Kim, Jez Humble ve Dr. Nicole Forsgren’in DevOps Araştırma ve Değerlendirme (DORA) ismiyle kurdukları firmada , DevOps performansını ölçmek amacıyla iki temel alanda dört ölçüm metriği belirledi.Her metriğinde kendi içinde başarı kriterlerini belirlemek için elit ile low arasında hedefler belirlendi.Aşağıdaki görselde Google 2022 raporundan bir ekran görüntüsü
Burda öncelikle şunu düşünmek gerekir her sektörün kendi dinamikleri var. Bir pazaryeri organizasyonu ile bir finans organizasyonu yada bir startup benzer çevik stratejilerde değiller bu nedenle her organizsyon kendi metrik değerlerini belirlemeli ve kendi organizasyonunu nasıl kalitesini arttırıcağına odaklanmalı
Metriklere geçmeden önce bu metrikleri toplamamız için uygun araçlarımızında olması gerekiyor. Her bir metriklerde bu araçlar neler olması gerekiyor bunlardan da bahsediyor olacağız.
Deployment Frequency
Dağıtım sıklığı, bir uygulamada canlı ortama alınma hızını ifade eder. Yüksek dağıtım sıklığı bir ürünün kullanıcılara yeni özellikler ve iyileştirmeler sunmak için hızlı bir şekilde çalıştığını gösterir. Bunun aksine, düşük dağıtım sıklığı, daha yavaş bir geliştirme sürecine veya yeni geliştirmelerin sağlanmasına yeterince önem verilmediğine işaret edebilir. Sürekli bir rekabet ortamı olduğu bir sektördeyseniz stratejiniz çok sık yeni özellik canlıya almak olabilir.
Ancak şunu unutmayın deployment sıklığınızı arttırmak için kalite, güvenlik test gibi change managementın süreçlerini atlamak faydadan çok zararda getirebilir. Bir takımın çok yüksek bir dağıtım sıklığı olmasınıda sorgulamalısınız
Dağıtım sıklığını ölçebilmeniz için modern bir CI/CD aracınız olması gerekir.
Lead Time for changes
İş birimi isteği olarak sprinte dahil ederek aldığımız bir geliştirmeyi geliştirme aşamasından, bu geliştirmenin yayınlanmasına kadar ne kadar süregeçtiğini ölçen bir metrikdir. Lead Time değeri ne kadar düşük olursa, onu uygulamaktan sorumlu ekibin performansı da o kadar yüksek olur. İlk geliştirme ile sürüm arasında geçen süre çok uzunsa bu, dağıtımı geciktiren darboğazlar veya başka sorunların bir göstergesi olabilir. Plansız araya giren işler iyi analiz edilmeli. Geliştirme başladıktan sonra code commitlerin hangi aşamada en çok beklendiği irdelenmelidir. Otomatize edilmemiş bir test süreci , yanlış bir sprint planlama, Code review süreçlerinde tıkanıklık Lead Time etkileyecektir.
Lead time başarılı ölçmek için modern bir CI /CD aracına, CI/CD ile entegre olabilen Agile planing aracına veentegre bir source control management aracına ihtiyacınız vardır. Bu 3 araç birbiriyle entegre ve verimli çalışmalıdır.
Time to Restore Service
Bir hizmeti bir arızadan sonra toparlanması için gereken süreyi gösterir. Bu ölçüm, bir sorunun tetiklenmesi ile sorunu düzelten değişikliğin üretime gönderilmesi arasında geçen süreyi ölçer. Planlanmamış kesintiler herzaman meydana gelebilir. Kesintilerden kaçınılamayacağından, aslında fark yaratan şey sistemi düzeltmek için gereken süredir. Buradaki amaç, ekiplerin sorunları ortaya çıktıklarında çözmede ne kadar etkili olduklarını nekadar çabuk ve yüksek performanslı olduklarını değerlendirmektir; Hızlı çözümler, daha az kesinti süresine ve müşterilerin yazılımdan memnun kalmasına, ayrıca işlev bozuklukları nedeniyle daha az hayal kırıklığına yol açar.
Time to Restore Service başarılı ölçmek için nedenlerinide iyi anlamak gerekmektedir. Bir yazılım geliştirmesinden yada başka bir nedenden olsun Incedent Management yapan araçlarımız olması iyi bir ölçümü mümkün kılar.
Change Failure Rate
Değişim Başarısızlık Oranı, canlı ortama alınan değişikliğin yada geliştirmenin kesinti veya ciddi sorunlar olarak tanımlanan arızalarla sonuçlandığını ölçen bir yüzde metriğidir. Hatalı dağıtım sayısı ile toplam dağıtım sayısına bölünmesiyle hesaplanır.
Sürekli olarak yüksek değişiklik hatası oranı genellikle sistematik bir soruna işaret eder. Canlı ortama alınmadan önce test koşumlarının eksik yapıldığını veya kaos senaryolarının canlı ortam öncesi koşulmadığını gösterir. Bunun yanında kod inceleme disiplininde sorunlar olabilir. Sorunları tespit etmek için Test otomasyon süreçlerini incelemek , Statik kod analizi araçlarının metriklerinden faydalanmak ve Code review süreçlerini incelemek faydalı olacaktır.
Başarılı bir ölçüm için Change Management ve application monitoring önemlidir. Başarılı bir deploy gibi gözüken ama aslında bir anda artan business hatalar tespit etmek için modern bir uygulama monitoring aracı olmalıdır. Change Manager değişimin başarılı yada başarısız olduğuna karar vermelidir.
Kendi Dora metriklerimizi Nasıl Ölçeriz
Dora ölçmek için yukarda belirttiğim araçları içermesi gerekiyor. Bu araçlar mevcut ise Dora kendiniz de ölçecek bir yapı geliştirebilirsiniz yada şuan piyasada hali hazırda olan Dora yazılımları ile hızlıca ilerleyebilirsiniz. Başlıca uygulamlar olarak waydev ,BlueOptima,oobeya gibi araçlar var.
Bir uygulama satın almayacaksanız opensource birkaç ürün ve birkaç rest servis ile benzer metrik raporları oluşturabilirsiniz . Öncelikle görüntüleme için bir arayüz gereksinimimiz var. Esnek ve farklı grafikler destekliyor olması nedeniyle Grafana tercih edebilirsiniz. Grafana arkasına bir rest api yada bir database bağlayarak grafiklerinizi paylaşabilirsiniz yada kendi web arayüzünüzü geliştirebilirsiniz ama grafanada pek ala yeterli
Deployment Frequency ölçeceksek deployment yaptığımız pipeline içine bir rest call adımı ekleyerek uygulama ismi, deployment zamanı, deployment statüsü ,deployment içindeki code commit zamanları ve boyutları vb birçok bilgiyi bir database tablosuna gönderebilirsiniz. Sonrasında ise tek yapmamız gereken tabloyu grafanaya bağlamak.
Deployment Frequency için Stat componentini kullandık. Farklı görsel olarak Gauge da kullanaabilirdik.
Stat componenti Thresholds tanımlamaya ve farklı Value lar için farklı renkler vermeye olanak sağlıyor.
Tablodan son 6 aydaki başarılı olan deploymentları çektik
Componente bağlayınca çok basit bir grafik gösterimi yapmış olduk.
Bu grafiğin yanında başka birçok deployment sıklığı grafiği ekleyebilirsiniz. Son1 yıldaki deployment sayısı ay bazındaki grafiği başarılı başarısız deployment sayısı. Deploymentları kurumuzunuzdaki organizasyon topolojisi ile bağdaşlaştırıp direktörlük, müdürlük , proje bazlı yada time series olarak 3 ,6 aylık grafikler sunabilirsiniz
Diğer Devops Development Metrikleri
Dora Metrikler tek metrik değil. Bunu birçok metrik ile beslemeniz detaylı analiz için önemli hepsini birleştirip işlerseniz bu veri kıymetli hale geliyor
Statik kod analizi sonucu çıkan Code Coverage, Mutation Test, Test otomasyon sonuç metrikleri , Application anomoly metrikleri, Code Review Metrikleri gibi metrikler bunlardan sadece bazıları. Farklı source code repolarınızı ölçekleyebilir hatta organizsyonunuzdaki geliştiricilerin aylık ölçümlerini yapabilirsiniz
Agile Metrikler
Dora metriklerle geliştirmeden canlı ortama kadarki metrikleri değerlendirdik. Ama bir okadar önemli olan talebin bağlangıcından canlı ortama alınana kadar müşteri isterlerinin metrikleride bir okadar önemli. Agile metrikleri konusurken genelde bir sprint içindeki metriklerden bahsediyoruz. Ancak önemli olan sprintte sonuda review yaparak product owner onayladığı storyler değil, canlı ortama alarak müşterilimize açtığımız storylerdir. Geliştirmeyi yaptığımız ama canlı ortama almadığımız geliştirmeler son kullanıcıya ulaşmadığında bir anlam ifade etmez. Bu iki durumdaki storyleri iyi analiz etmeli ve nedenleri üzerinde durmalıyız.
Agile metriklere genel bir bakış atarsak
Burndown Chart
Ekip kapasitemize göre sprint içinde ne kadar iş aldığımızı ve sprintte ne doğrultuda ilerlediğimizi gösteren önemli metriklerden biridir.
Velocity
Takımının hızını gösteren bir değerdir. Sprint içerisinde ekip tarafından tamamlanan PBI yada Storylerin puanlarının sayısıdır. Bir başka değişle; ekibin çalışır bir yazılım üretme yeteneği de diyebilir
Lead Time
Bir story nin yaratılma tarihinden canlı ortama (done tarihi değil) alınma tarihi arasındaki geçen süredir. Ekibin kaç story nekadar ortalama sürede gerçekten canlı ortama alındığını gösterir. Lead Time doğru hesaplamak için geliştiricilerin geliştirmeleri ile storylerini doğru şekilde birbiriyle ilişkilendirmiş olması gerekmektedir.
Production Time
Sprint sonu Done statüsündeki bir story nin canlı ortama alınma arasındaki geçen süredir. Lead Time sprint sürecinin başından metriği hesaplarken Production Time ise sprint sonu done olduktan nekadar süre sonra işlerin canlı ortama çıktığı ile ilgilenir.
Time To Market
Time to market talebin geldiği andan canlı ortama çıkana kadarki süreci kapsar. Storyler feature ve epiclere bağlıdır. İş biriminin yada müşterinin talebi doğrultusunda gereksinim projelendirilir ve geliştirme ekibine iletilir ve geliştirme storylere bölünerek sprintler içinde eritilerek tamamlanır. İlk iki metrik sprint içindeki storylerin ortalama canlıya çıkışına odaklanırken, Time to markette daha çok proje seviyesinde ortalama metriklere odaklanır
