import React from 'react';
Giriş
DORA (DevOps Research and Assessment) metrikleri — dağıtım sıklığı, dağıtım süresi (lead time for changes), hata geri dönüş oranı (change failure rate) ve hizmet geri kazanma süresi (MTTR) — yazılım teslim süreçlerinin sağlığını ölçmede yaygın olarak kullanılıyor. Ancak bu metrikleri toplamak ve raporlamak kolay olsa da, "doğru" yorumlamak daha zordur. Bu yazıda sahadan edindiğim pratik çıkarımlarla ve uygulanabilir önerilerle DORA verisini nasıl daha akılcı okuyacağınızı anlatacağım.
Temel prensip: bağlam olmadan sayılar yanıltır
Metrikler tek başına bir hüküm vermez. Aynı dağıtım sıklığı farklı ekipler için farklı anlam taşıyabilir: - Monolitik bir uygulamada günde birden az dağıtım normal iken, mikroservislerde saatlik veya dakikalık dağıtımlar beklenti olabilir. - Yüksek dağıtım sıklığı olumlu olabilir ama bunun arkasında otomasyon, test kapsamı ve güvenli bir geri dönüş stratejisi yoksa risk artar.
Her metriği değerlendirirken şu soruları sorun: - Ölçtüğümüz şey hedeflediğimiz davranışla doğrudan ilişkili mi? - Bu metriğin yüksek/ düşük olması hangi süreçleri etkiler? - Metriğin değişimine etki eden dış faktörler (organizasyonel, teknik veya sezonluk) neler?
Veri kalitesi ve ölçüm sapmaları
Yanlış veri toplama en yaygın tuzaklardan biridir. Örnek sapmalar: - "Deployment" tanımı belirsizse: CI'de başarılı bir pipeline mı yoksa prod'e ulaşan release mi sayılıyor? - Otomasyon düzeyindeki değişiklikler aniden dağıtım süklümesini artırabilir (pipeline'ların parçalanması, feature flag kullanımı vb.). - Hotfix/rollback'leri ayrı kategorize etmezseniz hata oranı veya MTTR yanlış hesaplanır.
Pratik öneriler: - Deployment, rollback ve hotfix kavramlarını net tanımlayın ve telemetri kaynaklarınızda bu etiketleri zorunlu kılın. - Pipeline event'lerini, release tag'lerini ve prod monitoring incident'lerini birleştirecek bir id-mapping stratejisi kurun. - Veri temizleme (örneğin test deploy'larını hariç tutma) için açık kurallar tanımlayın.
Nedensel değil korelasyon düşünün
Metriklerdeki iyileşme veya bozulma başka değişkenlerle bağlanabilir, ancak bu doğrudan neden değildir. Örneğin ekip başına düşen deployment sayısı arttıysa bunun sebebi rolling release modeline geçiş olabilir, bu da daha küçük ve sık parçalar anlamına gelir; ancak aynı anda test kapsamı düştüyse hata oranı artabilir.
Aksiyon alırken "Neden?" sorusunu bir hipotez olarak kurun ve küçük kontrollü deneylerle doğrulayın: - Hipotez: "Deployment sıklığını artırmak MTTR'yi düşürür." Deney: Bir servis grubunda canary + feature flag ile dene, sonuçları kontrol et. - Ölçümler değiştiğinde hangi süreç veya araç değişti? (ör. yeni CI runner, test piramidi değişikliği, on-call rota değişikliği)
Kısa kod örneği: basit DORA metrik hesaplayıcı (Python)
Aşağıdaki örnek, pipeline ve incident olaylarından temel DORA metriklerini hesaplamaya yönelik minimal bir yaklaşımı gösterir. Gerçek üretimde olay eşleştirme, zaman dilimi farklılıkları ve istisna yönetimi eklenmelidir.
from datetime import datetime from statistics import mean
Örnek veri (prod deploys ve incident'ler) deploys = [ {"id": "d1", "time": datetime.fromisoformat("2026-07-01T10:00:00")}, {"id": "d2", "time": datetime.fromisoformat("2026-07-02T12:30:00")}, {"id": "d3", "time": datetime.fromisoformat("2026-07-03T09:00:00")}, ]
lead_time: kod commit -> prod deploy (saat cinsinden) lead_times_hours = [2.5, 4.0, 1.75]
change failure rate: deploy başına incident sayısı (boolean) failures = [False, True, False] # d2 hataya neden oldu
MTTR: incident açılış -> kapatılış (saat) mttr_hours = [0, 3.5, 0] # sadece gerçek incident için 3.5 saat
deployment_frequency_per_day = len(deploys) / 3 # örnek 3 günlük pencere avg_lead_time = mean(lead_times_hours) change_failure_rate = sum(1 for f in failures if f) / len(deploys) avg_mttr = mean([t for t in mttr_hours if t > 0]) if any(t > 0 for t in mttr_hours) else 0
print("Deployment frequency (per day):", deployment_frequency_per_day) print("Average lead time (hours):", avg_lead_time) print("Change failure rate:", change_failure_rate) print("Average MTTR (hours):", avg_mttr)
Bu kodu kendi verinize bağlarken: - Zaman pencerelerini açıkça belirtin (gün, hafta, ay). - Deploy'ları ve incident'leri doğru eşleştirin (deploy id veya release id üzerinden).
İyi uygulamalar: gösterge panosu ve raporlama
- Çok katmanlı panolar kurun: üst düzey özet + servis/ekip bazında detay. Yöneticiler için trendler, mühendisler için incident detayları. - Hedefler (SLA/ SLO) ile metrikleri ilişkilendirin ama hedefleri ödül-punishment aracı olarak değil iyileştirme rehberi olarak kullanın. - Sürümleme ve feature flag kullanımı metrikleri anlamlandırmada yardımcı olur: küçük, terslenebilir değişiklikler ölçümleri daha anlamlı kılar.
Kontrol listesi: DORA metriklerini doğru okumak için hızlı doğrulama
- [ ] Deployment tanımımız net mi? (CI başarılı mı, prod'e mi, canary/mavi/yeşil dahil mi) - [ ] Hotfix ve rollback olaylarını ayrı sınıflandırıyor muyuz? - [ ] Veri kaynaklarımız (CI, CD, incident tracker, monitoring) zaman damgalarını aynı zaman dilimine taşıyor mu? - [ ] Metriğe etki eden organizasyonel değişiklikleri (mesela ekip yeniden yapılanması) kaydediyor muyuz? - [ ] Otomasyon değişiklikleriyle (pipeline, infra) metriklerdeki ani sıçramaları korelasyonlayabiliyor muyuz? - [ ] Metrikleri takım/servis bazında parçalayabiliyor muyuz? (Toplam sayılardan ayrıştırma) - [ ] Değişimleri hipotez-odaklı testlere çevirip küçük kontrollü deneyler yapıyor muyuz? - [ ] Panolarımız hem trend hem de kök neden analizi (drive-down) için yeterli detaya sahip mi?
Sonuç
DORA metrikleri güçlü araçlardır ama tek başlarına kesin bir yargı üretmezler. Doğru yorumlama, veri kalitesine yatırım, bağlamın korunması, ve hipotez-temelli deney kültürü ile mümkündür. Teknik lider olarak hedefiniz metrikleri "cezalandırmak" veya "övmek" için kullanmak değil; süreçleri gözlemleyip, riskleri azaltıp ve sürekli iyileşmeyi destekleyecek aksiyonlar üretmektir. Bu yaklaşımı benimseyen ekipler, metrikleri bir amaç değil, iyileştirme için bir rehber olarak görürler.
Eğer isterseniz, mevcut telemetri kaynaklarınızı ve panolarınızı gözden geçirip hangi ölçümlerin yeniden tanımlanması gerektiğine dair kısa bir kontrol listesi üzerinden beraber çalışabiliriz.