DORA Metrikleri Nedir? Yazılım Dağıtımının Dört Temel Ölçüsü
Summary
DORA metrikleri, yazılım takımının kodları ne kadar hızlı ve güvenilir bir şekilde dağıttığını ortaya koyan dört ölçümdür. Deployment sıklığı, change lead time, başarısızlık oranı ve kurtarma süresi gibi göstergeler, elite ekiplerin neden diğerlerinden daha hızlı ve istikrarlı gemi yaptığını açıklar.
Yazılım geliştirme ekibi olarak "dora metrikleri nedir" sorusuna temiz bir cevap arayıyorsanız: bunlar yazılım dağıtım performansını ölçen dört ölçümdür. Deployment Sıklığı, Change Lead Time, Change Failure Rate ve Service Restore Time. Nicole Forsgren, Jez Humble ve Gene Kim tarafından geliştirilen, on binlerce mühendislik ekibinde doğrulanan ve 2018'de Google tarafından satın alınan bu model, her metriğin neyi izlediğini, pratikte başarı sınırlarının neye benzediğini ve bu çerçevenin ne zaman işe yaramadığını kapsar.
DORA metrikleri nereden geldi ve araştırma neden önemli
DORA programı 2014'te spesifik bir soruyla başladı: yüksek performans gösteren yazılım takımları diğer herkesten ne farklı yapıyor? Araştırma ekibi, sektörler arasında on binlerce geliştiriciyi yıllık olarak anket yaparak, güçlü yazılım dağıtım sonuçlarını tahmin eden uygulamaları aradı.
Araştırmayı yapışkan kılan bulgu sezgiyi tersine çevirdi. Elite takımlar hız ve istikrarı ödün verme konusunda bir seçim yapmadı. Daha hızlı dağıttı ve üretimde daha az olay yaşadı. Bu sonuç, yayın döngülerini yavaşlatmanın standart yasasını sorguladı: eğer daha az sık dağıtırsak, daha az şey kırılır.
Veriler tam tersini gösterdi. Sık dağıtan takımlar daha iyi geri bildirim döngüleri kurdu, sorunları erkene yakaladı ve bir şey yanlış gitti miş, daha hızlı kurtarıldı. Hız ve istikrar çelişkili değildi. Bunlar ilişkili idi.
Google, 2018'de DORA programını satın aldı. Takım şimdi yıllık State of DevOps Raporu yayınlıyor, modelini 2025'te beşinci metrikle (Rework Rate) güncelledi ve araştırmayı dora.dev'de açık bir girişim olarak yürütüyor.
Dört ölçüm ve her biri neyi izliyor
Model, 2025'te beşinci metrik (Rework Rate) eklemek için güncellendi, ancak dört orijinal anahtar çoğu araç ve takım tartışması için temel kalır.
Deployment Sıklığı
Takımınız ne sıklıkla production'a çıkıyor. Bu tam tanımdır.
Elite takımlar isteğe bağlı dağıtım yapar: bir şey hazır olduğunda günde birden fazla. Düşük performans gösteren takımlar ayda bir veya daha az, bazen birkaç ayda bir dağıtırlar. Solo builder için, herhangi bir tutarlı haftalık sevkiyat hızı, bu tek metrik tarafından yüksek performans gösteren köşesine kesinlikle konmuşsunuzdur.
Deployment sıklığı, pipeline güveninin bir temsilcisidir. Seyrek dağıtan takımlar genellikle kırılgan altyapı, ağır manuel test kapıları veya yayınları sürüntüye vuran organizasyonel onay zincirleri var. Günde birden fazla kez gemi yapan takımlar, bu engellerin çoğunu otomatikleştirmişler. Sıklık bir semptom, sebep değil.
Change Lead Time
Bir commit'in sürüm kontrolüne ulaşmasından o değişikliğin production'a canlı olmasına kadar geçen zaman.
Bu sürenin çoğu kod yazmak değil. Bu bekleme: pull request kuyruğu açılmasını beklemek, CI/CD boru hatlarının bitmesini beklemek, bir dağıtım yuvasını beklemek, yayını tetikleme erişimi olan biri beklemek. Birkaç saatlik bir lead time, iş akışının sıkı ve büyük ölçüde otomatikleştirilmiş olduğu anlamına gelir. Haftalar cinsinden ölçülen bir lead time, bir veya daha fazla teslim noktasında yapısal bir şey sürtünme eklediği anlamına gelir.
Solo geliştirici için, lead time, bir commit'i itme ile kullanıcıların sonucu görmesi arasında ne duruyor. Bazen bu, on iki dakika süren bir dağıtım pipeline'ıdır. Bazen bu, bir değişikliğin sevkiyata karşı istikrar hakkında iç tereddütüdür.
Change Failure Rate
Bir dağıtımın hotfix, geri alma veya olay yanıt vermesini gerektirecek kadar ciddi bir soruna neden olma yüzdesi.
Bu, DORA modelindeki kalite sinyalidir. 2024 State of DevOps Raporu, elite takımları yaklaşık %5 değişiklik başarısızlık oranında yerleştirir. Düşük performans gösteren %46 ila %63 arasında çalışır. Kabaca yarısı dağıtımlarınız acil müdahale gerektiriyorsa, test kapsamı ve inceleme sürecinizde önemli yapısal boşluklar var.
Change Failure Rate, soyut anlamda kod kalitesini ölçmez. Sevkiyat ettiğiniz değişikliklerin özellikle production ortamında beklenen şekilde davranıp davranmadığını ölçer. Yerel olarak geçen ancak production'da başarısız olan entegrasyon yollarını kapsamayan bir test paketi bu sayıyı taşımaz.
Service Restore Time
Bir dağıtım bir olay tetiklediğinde, hizmet geri yüklenene kadar ne kadar sürer?
Bu orijinal olarak Mean Time to Recovery (MTTR) olarak etiketlendi. DORA ekibi, 2025'te çerçeveyi, dağıtıma neden olan olaylardan kurtarışı izleyen Failed Deployment Recovery Time olarak günceledi, altyapı arızaları veya üçüncü taraf kesintileri yerine. Ayrım önemlidir çünkü dağıtımdan kaynaklanan olaylar tamamen takımın kontrolü altındadır, bu da onları süreç iyileştirmesi için doğru hedef yapar.
Elite takımlar bir saatin altında hizmet kurtarır. Düşük performans gösteren kurtarmak haftalara kadar yapabilir. Eğer solo builder iseniz, bu metrik büyük ölçüde izleme altyapınız olup olmadığına bağlıdır. Uyarı altyapısı olmayan takımlar, hataları otomatik sinyallerden değil, kullanıcı şikayetlerinden öğrenirler, bu da kurtarma süresine saat ekler.
Performance katmanları pratikte neye benziyor
State of DevOps raporu, ekipleri DORA numaralarına dayalı dört katmana ayırır. Bunlar 2024 raporundan kaba aralıklardır, sert kesintiler değil:
Performance Seviyeleri:
Elite: Günde birden fazla dağıtım, 1 saatten az lead time, %5'ten az hata oranı, 1 saatten az kurtarma
Yüksek: Günlük ila haftalık dağıtım, 1 gün-1 hafta lead time, %5-10 hata oranı, 1 günden az kurtarma
Orta: Haftalık ila aylık dağıtım, 1 hafta-1 ay lead time, %10-15 hata oranı, 1 gün-1 hafta kurtarma
Düşük: Aylık veya daha az dağıtım, 1-6 ay lead time, %46-63 hata oranı, 1 hafta-6 ay kurtarma
Elite ve low arasındaki boşluk artımlı değil. 2024 raporuna göre, düşük performans gösteren takımlar dağıtım yapmak için 180 kez daha uzun ve olaylardan kurtulması için elite takımlardan 2.500 kez daha uzun sürebilir. Bunlar marjinal farklılıklar değil.
Elite katmana ulaşmak, CI/CD otomasyonuna, test kapsamına ve gözlemlenebilirlik araçlarına devam eden yatırımla başarılabilir. Daha hızlı kod yazarak olmaz. Kod yazmakla production'da güvenilir bir şekilde çalışması arasındaki manuel adımları ve bekleme dönemlerini kaldırarak olur.
AI geliştirme araçları 2026'da DORA numaralarını nasıl değiştiriyor
2026'ya kadar, AI kodlama araçları, DORA metriklerini spesifik şekillerde etkileyen kadar yaygınlaştı.
Cursor, GitHub Copilot veya benzer araçları kullanan takımlar daha hızlı kod yazıyorlar, bu deployment sıklığını artırma eğilimindedir. Lead time ayrıca birçok takımda kısaldı çünkü geliştirici başına haftada daha fazla kod üretilir, bu da daha fazla commit'in pipeline'ı aracılığıyla akması anlamına gelir.
Change failure rate her iki yönde gitmiştir. Güçlü inceleme süreçlerine ve test kapsamına sahip takımlar, daha fazla gönderi sağlarken başarısızlık oranlarını istikrarlı tutmuştur. AI tarafından oluşturulan kodu yeterli inceleme olmadan gemi yapan takımlar başarısızlık oranlarının artış görmüştür. DORA modeli kodun nasıl yazıldığını umursamaz. Kodun production'a ne zaman gemi yapıldığını ölçer.
DORA 2024 State of DevOps Raporu anket yapan takımların %41'inin AI destekli geliştirme araçlarını kullandığını bulmuştur. Bu takımlar, AI'nin otomatik test ve inceleme pipeline'larıyla eşleştirildiğinde, orantılı bir change failure rate artışı olmadan daha yüksek deployment sıklığı göstermiştir.
İşte pratikte takılıp kalan yer: AI, pipeline'ın ön ucunu önemli ölçüde hızlandırır. DORA, bu hızlandırmanın temiz bir şekilde absorblanıp absorplanmadığını veya downstream'da instabilite yaratıp yaratmadığını söyler.
Stack'inizi aşırı kurmadan DORA metriklerini izlemek için araçlar
Çoğu takım, zaten kullandıkları araçlardan veri çekerek DORA metriklerini ölçmeye başlar: dağıtım olayları ve commit zaman damgaları için GitHub veya GitLab, kurtarma zamanı verileri için PagerDuty veya OpsGenie ve change failure rate sayıları için olay yönetim sistemi.
Birkaç platform, özellikle bu dört metrik etrafında DORA dashboard'ları inşa etti. Solo builder'lar için budget yoksa: her production dağıtımının zaman damgasını ve her kurtarma olayını günlüğe kaydeden basit bir script, hiçbir altyapı maliyeti olmadan deployment sıklığı ve kurtarma süresini sunar. Lead time, Git logundaki commit zaman damgalarından yaklaşık olarak yapılabilir.
DORA metriklerinin gerçek sınırları
DORA'yı ölçmek faydalıdır. Bunu mühendislik performansının tam resmini olarak tedavi etmek, adlandırmaya değer birkaç spesifik kör nokta oluşturur.
Teknik borç birikimi. Düşük change failure rate ile yüksek deployment sıklığı, kod tabanının zaman içinde çalışması daha zor hale gelip gelmediği hakkında hiçbir şey söylemez. Bir takım, her yeni özelliği göndermek daha yavaş yapan tür borcunu istikrarlı olarak biriktirebilirken elite DORA numaralarını vurabilir. DORA dağıtım çıkışını ölçer; dağıttığınız şeyin durumunu ölçmez.
Sonuç hizalaması. Deployment sıklığı çıkışı ölçer, sonuçları değil. Günde beş kez gönderi, eğer bu değişikliklerin hiçbiri ürün veya işletme önemsediği metrik taşımıyorsa önemli değildir. Feature flag'ler, A/B test altyapısı ve işletme metriklerini izleme DORA modelinin dışında tamamen oturuyor.
Sürdürülebilirlik. DORA araştırma ekibi 2023'te çerçeveye geliştirici deneyim boyutu ekledi, sürdürülebilir yüksek performansın burnout'ta çalışmayan mühendisler gerektirdiğini kabul etti. Dört temel metrik, elite numaraları vurmak başka yerde bir maliyete gelip gelmediğini izlemez.
DORA'yı temel tanı aracı olarak kullanın, puan tahtası değil. Ölçümlerin ortaya attığı sorular çoğunlukla sayıların kendisinden daha işlem yapılabilir. %30'luk bir change failure rate, hangi değişiklik türlerinin başarısız olduğunu ve neden bilmekten daha az faydalıdır.
Eğer hiç ölçmemişseniz başlayacak yeri
Altı aylık hiçbir DORA verisi olmayan bir yan proje normal. Çoğu küçük takım ve solo builder hiçbir şey ölçmemiş.
Sıfırdan başlıyorsanız, ilk olarak deployment sıklığı ve lead time seçin. Her ikisi de Git commit zaman damgalarından ve dağıtım günlüklerinden çıkarmak kolaydır ve pipeline'ınızda gereksiz sürtünme olup olmadığı hakkında hemen geri bildirim verir. Yazmak için kırk dakika süren bir değişiklik için üç günlük lead time araştırmaya değer bir sinyal.
Change failure rate ve restore time için, sayılar herhangi bir şey anlamına gelmeden önce olayların birikmesi gerekir. Production'da bir şey kırıldığında, tespit edilen zaman damgasını ve çözülen zaman damgasını günlüğe kaydedin. Bu veriler zaman içinde bileşir.
Pratik bir alışkanlık: herhangi bir production olayından sonra iki soru sorun. Bu sorunun tespiti ne kadar sürdü? Tespitinden çözüme kadar ne kadar? Bu iki sayı, restore süresi girdisidir. Altı ay boyunca tutarlı bir şekilde izlemek, kurtarma sürecinizin iyileşip iyileşmediğini veya düz kaldığını bilmek için yeterli geçmiş verir.
DORA metriklerini solo dev olarak bile ölçmek için üç sebep, bir sebep ödün vermeyin: metrikler görünmez sürtünmeyi görünür kılar, otomasyonu yatırım için muhasebe oluştururlar ve özellik çalışması arasında iyileştirilecek somut bir şey verirler. Ödün vermemek sebebi: eğer launch öncesiyseniz gerçek production kullanıcıları yok, sayılar henüz çok şey anlamına gelmez. Gerçek kullanıcılara düzenli olarak sevkiyat yaptığınızda ölçmeye başlayın.
Mükemmel bir fikir değildir. Yapılabilir bir fikirdir.