Birçok organizasyonda iki cümle aynı anda dolaşır:
- “Daha hızlı release etmemiz lazım.”
- “Üretim çok kırılgan, risk alamayız.”
Bu ikisi birbirinin düşmanı değildir. Düşman; ölçümsüz hız, görünmez risk ve “hissiyatla” yönetilen operasyonlardır. DORA metrikleri bu yüzden değerlidir: hızı ölçer. Ama tek başına yetmez; çünkü üretim güvenini (stability) SRE sinyalleri ile birlikte okumak gerekir.
1) DORA metrikleri neyi ölçer?
DORA çekirdeği dört metriktir:
- Deployment Frequency: ne kadar sık deploy ediyorsunuz?
- Lead Time for Changes: commit’ten prod’a ne kadar sürüyor?
- Change Failure Rate: deploy’ların kaçı sorun çıkarıyor?
- Time to Restore (MTTR): bozulunca ne kadar hızlı toparlıyorsunuz?
Bu metriklerin değeri “kıyas” değil; trend ve darboğaz teşhisidir.
2) En büyük hata: metriği hedefe çevirmek
Metrik hedef olursa, oyun başlar:
- “Deploy sayısını artırmak” için küçük ve anlamsız release’ler
- “Change failure rate düşük olsun” diye değişiklikleri biriktirmek
- “MTTR iyi görünsün” diye incident tanımını daraltmak
3) DORA + SRE: hızın yanında güveni de ölç
Benim sevdiğim “tek pano” yaklaşımı:
Hız (DORA)
- Deployment frequency
- Lead time
Kalite ve risk
- Change failure rate (deploy sonrası incident/rollback)
- MTTR (toparlanma hızı)
- Error budget tüketimi (SLO varsa)
Operasyon sağlığı (sürdürülebilirlik)
- On‑call yükü (paging rate, gece alarmı)
- Toil oranı (tekrarlayan manuel iş)
- En yüksek gürültü üreten 10 alarm (alert hygiene)
Bu pano “yönetim raporu” değil; ekip kararlarını hızlandıran bir araçtır.
4) Tanımları standardize et: aksi hâlde herkes başka şey ölçer
Saha problemi şudur: aynı kelime farklı anlama gelir.
Pratik tanımlar:
- Deployment: üretime çıkan her değişiklik (manual hotfix dahil)
- Lead time: merge→prod (veya commit→prod), ama tek tanım
- Change failure: rollback, sev2+ incident, SLO ihlali veya “müşteri etkisi” (seç ve yaz)
- Restore: servis “kabul edilebilir” seviyeye döndüğü an (tam kök neden çözümü değil)
5) Ritüel: metrikleri konuşmak için değil, aksiyon çıkarmak için toplan
Benim çalıştığım yapılarda işe yarayan ritim:
- Haftalık 30 dk: “metrik + 3 aksiyon”
- 1 aksiyon: lead time darboğazı (pipeline/test/review)
- 1 aksiyon: change failure (release gate / canary / runbook)
- 1 aksiyon: toil (otomasyon/standardizasyon)
Bu toplantıda “neden kötü?” tartışması değil, “hangi friksiyonu kaldırıyoruz?” konuşulur.
6) Operasyonel gerçekçilik: hızlı olmak için önce geri dönüşü ürünleştir
Yüksek hız, ancak geri dönüş refleksi güçlü ise güvenlidir:
- Canary / ring / progressive delivery
- Rollback otomasyonu (tek tuş değil, tek süreç)
- Feature flag disiplini
- Runbook ve karar noktaları (eşik + aksiyon)
Hızın gerçek kaynağı, “hata olmayacak” varsayımı değil; hata olduğunda kontrollü kalabilme kapasitesidir.
Kapanış
DORA metrikleri, hız tartışmasını sayısallaştırır. SRE sinyalleri ise hızın bedelini görünür kılar. İkisini birlikte okuduğunuzda “hız mı güven mi?” sorusu yerini şu soruya bırakır:
Hızı artırmak için hangi operasyonel riskleri ürünleştirmemiz gerekiyor?