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)
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?
Paylaş:
Bu yazı faydalı oldu mu?
Yükleniyor...
Geri bildiriminiz için teşekkürler!
Bu yazı nasıldı?
Sıkça Sorulanlar
Bu makale ile ilgili okurların sorduğu yaygın sorular.
DORA metriklerini SRE sinyalleriyle birleştirmeye nasıl başlayabilirim ve hangi araçları tercih etmeliyim?
Ben ilk adım olarak mevcut CI/CD pipeline’ımı gözden geçirip Deployment Frequency ve Lead Time for Changes’i otomatik olarak ölçebilen bir veri toplayıcı kurdum; genellikle GitHub Actions, GitLab CI ya da Jenkins’in metrik eklentileri işimi gördü. Ardından SRE sinyalleri için Prometheus ve Grafana’yı entegre ettim; burada error budget burn rate, latency ve incident count gibi göstergeleri topladım. Bu iki veri setini birleştiren bir dashboard oluşturarak hem hız hem de stabiliteyi aynı ekranda izleyebildim. Başlangıçta basit bir JSON‑exporter ve bir cron job yeterli olur; zamanla daha gelişmiş bir observability platformuna geçiş yapabilirsiniz.
Deployment Frequency artırırken Change Failure Rate'ı düşük tutmanın avantajları ve dezavantajları nelerdir?
Ben sık release yaptığımda ekip daha küçük, geri alınabilir değişikliklerle çalıştığı için hatalar izole olur ve geri dönüş süresi (MTTR) çok kısalır; bu da müşteri memnuniyetini artırır. Ancak, Change Failure Rate’ı sadece “düşük” göstergesine odaklanmak, kritik testleri atlamaya ve “küçük ama sık” hataları görmezden gelmeye yol açabilir. Bu durum uzun vadede teknik borç birikmesine neden olur. Ben dengeyi, her deploy’da otomatik test ve canary deployment uygulayarak sağlıyorum; böylece frekans artarken başarısızlık oranı da gerçek bir kalite ölçütü olarak kalır.
MTTR (Mean Time To Restore) ölçümünde sık karşılaştığım hata nedir ve bir incident sonrası ne yapmalıyım?
Ben MTTR’ı ölçerken en büyük hatam, incident’ı sadece “kapandığında” saymak ve ön hazırlık aşamasını hesaba katmamaktı; bu, sürenin gerçekte çok daha uzun olduğunu gizler. Bir sorun çıktığında önce olayın sınıflandırmasını (seviyesini, etki alanını) netleştiriyorum, ardından zaman damgalarını – detection, acknowledgement, mitigation, resolution – ayrı ayrı kaydediyorum. Incident sonrası post‑mortem’de sadece teknik nedenleri değil, ölçüm hatalarını da analiz ediyorum. Böylece sonraki döngülerde MTTR’ı daha doğru bir şekilde raporlayıp, iyileştirme aksiyonlarını gerçek veriye dayandırabiliyorum.
DORA metriklerini prim ya da performans hedefi olarak kullanmak doğru mu? Genel kanı bu konuda ne kadar doğru?
Ben DORA metriklerini doğrudan primle bağladığımda ekip, “sayıları artırmak” için sahte davranışlar geliştirdi; örneğin çok küçük release’lar yapıp gerçek değer katmayan değişiklikleri “deploy” olarak saydılar. Bu, Google’ın da uyardığı gibi metrikleri skorboard yerine teşhis aracı olarak tutmamız gerektiğini gösteriyor. Genel kanı, DORA’yı ekip kültürünü iyileştiren bir geri bildirim döngüsü olarak görmek; hedefleri ise iyileştirme planları ve retrospektiflerle bağlamak. Ben metrikleri “benchmark” olarak kullanıyorum, ödül sistemini ise kalite, iş birliği ve müşteri memnuniyeti gibi daha kapsamlı kriterlerle oluşturuyorum.
ME
Mustafa Erbay
Sistem Mimarisi · Network Uzmanı · Altyapı, Güvenlik ve Yazılım
2006'dan bu yana sistem mimarisi, network, sunucu altyapıları, büyük yapıların kurulumu, yazılım ve sistem güvenliği
ekseninde çalışıyorum. Bu blogda sahada karşılığı olan teknik deneyimlerimi paylaşıyorum.
Kişisel Notlar
Bu notlar sadece sizde saklanır. Tarayıcınızda yerel olarak tutulur.
Hazır0 karakter
Yorumlar
Sunucu Taraflı AI Moderasyon
Yorumlar sunucuda yapay zeka ile denetlenir ve kalıcı olarak saklanır.
?
0/2000
Sunucu taraflı AI denetim
Henüz yorum yok. İlk siz yapın!
✉️Ücretsiz · Spam yok · İstediğin an çık
Yeni yazılardan haberdar olun
Yeni içerikler ve teknik notlar e-postanıza gelsin.
📌
Haftanın en iyisiSadece okumaya değer tek yazı
🔧
Alet çantasıBu hafta kullandığım araçlar
🧠
Perde arkasıBlog'a girmeyen notlar
Spam yapmıyoruz. İstediğiniz zaman ayrılabilirsiniz. · Sadece Umami (self-hosted, Google yok) ile takip.