DORA metrikleri nedir? DORA (DevOps Research and Assessment), Google Cloud bünyesindeki araştırma ekibinin 2014’ten bu yana yürüttüğü akademik temelli bir programdır ve yazılım teslim performansını dört çekirdek metrik (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Failed Deployment Recovery Time) ile ölçer. 2024 Accelerate State of DevOps Report’a göre Elite seviye takımlar Low seviye takımlardan deployment frequency açısından 417 kat, lead time açısından 970 kat, recovery time açısından 6440 kat daha hızlıdır. Bu yazıda DORA’nın matematiksel temelini, ölçüm boru hattı mimarisini, dört metriğin pratik benchmark eşiklerini, Türk fintech ve perakende takımlarının sıkça takıldığı saha sorunlarını ve Elite kademeye sıçramak için 2026 itibarıyla geçerli pratikleri ele alacağız.
DORA’nın Akademik Temeli ve 2014-2026 Evrimi
DORA programı Dr. Nicole Forsgren, Jez Humble ve Gene Kim tarafından 2014’te başlatıldı; 2018’de yayımlanan Accelerate kitabı 31.000’den fazla mühendisle yapılan anketlerin psikometrik analizine dayanır. Google 2018 sonunda DORA’yı satın aldı ve metrikler bugün Google Cloud DevOps portalı altında resmi olarak yayımlanıyor. 2024 raporu yaklaşık 39 ülkeden 2.700 katılımcı ile yürütüldü; 2025 raporu ise AI-asisted development’ın throughput üzerindeki etkisini ilk kez ölçtü ve “AI kullanımı” değişkenini regresyon modeline ekledi.
Metriklerin matematiksel önemi şudur: dördü birlikte ölçüldüğünde “throughput” (Deployment Frequency + Lead Time) ve “stability” (Change Failure Rate + Recovery Time) eksenlerini birbirinden bağımsız tutar. Geleneksel ölçüm yaklaşımlarında ekipler hızı artırmak için stabiliteden ödün verirdi; DORA verisi tam tersini gösterir: Elite takımlar her iki eksende birden yüksektir. Bu tezi destekleyen Forsgren-Humble-Kim regresyon analizi, p<0.001 istatistiksel anlamlılıkla yayımlandı.
2024 raporundaki en kritik bulgu: yüksek performans ile organizasyonel gelir büyümesi arasındaki korelasyon katsayısı 0.42 (orta-güçlü). Bir başka deyişle, DORA seviyesinin Low’dan Elite’e çıkması yıllık gelir büyümesinde ortalama %33 fark yaratıyor. Bu rakam, DORA’yı yalnızca mühendislik metriği olmaktan çıkarıp boardroom KPI’sına dönüştürdü.
Dört Çekirdek Metrik: Tanım, Formül ve Ölçüm Yöntemi
Her metrik kesin olarak tanımlanmıştır; “Lead Time” gibi sektörde 14 farklı anlamı olan terimler DORA’da tek bir formüle indirgenmiştir. Aşağıdaki tablo dört metriğin akademik tanımı, ölçüm noktası ve veri kaynağını gösterir:
| Metrik | Akademik tanım | Ölçüm noktası (start → end) | Tipik veri kaynağı |
|---|---|---|---|
| Deployment Frequency (DF) | Production’a başarılı deploy birim zamanı | CI/CD job success → prod env’e indirilme | GitHub Actions, GitLab CI, ArgoCD events |
| Lead Time for Changes (LT) | İlk commit’ten production’a kadar geçen süre | git commit timestamp → prod deploy timestamp | Git log + deploy webhook |
| Change Failure Rate (CFR) | Prod’a giden değişikliklerden hatalı çıkan oran (%) | Toplam deploy / failed deploy + rollback + hotfix | Incident sistemi (PagerDuty, Opsgenie) + deploy log |
| Failed Deployment Recovery Time (FDRT) | Bozuk deploy’dan stabil prod’a dönüş süresi | Incident.start → incident.resolved | PagerDuty, Statuspage, MTTR raporu |
Önemli not: 2023’te metriklerden biri olan “Mean Time to Restore” (MTTR) kavramsal olarak terkedildi; yerine “Failed Deployment Recovery Time” geldi. Sebep: MTTR ölçümünde tüm incident’lar dahil edilirdi (örn. donanım arızası), ancak DevOps ekibinin doğrudan kontrolünde olmayan sebepler metriği bulanıklaştırırdı. FDRT yalnızca deploy kaynaklı arızaları ölçer; bu sayede causality temizdir.
Ölçüm boru hattı pratikte üç katmandan oluşur: (1) event collection — Git, CI, CD, incident sistemlerinden webhook ile event akışı; (2) normalization — farklı tool’lardan gelen event şemasını DORA-compatible formata çevirme (genelde JSON-LD); (3) aggregation & visualization — Grafana, Looker, Datadog veya açık kaynak Sleuth/Apache DevLake gibi çözümlerle dashboard’a yansıtma. Apache DevLake CNCF Sandbox projesi olup yaklaşık 3.300 GitHub yıldızı ile en yaygın açık kaynak DORA pipeline’ıdır.
Performans Kademeleri: Elite, High, Medium, Low Eşikleri
2024 raporundaki güncel benchmark eşikleri aşağıdadır. Bu rakamlar 2.700+ katılımcının kümeleme analizinden çıkarılmıştır; rakam değil, percentile bazlı kümelerdir:
| Metrik | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment Frequency | Günde birden fazla (on-demand) | Haftada 1 – ayda 1 | Ayda 1 – 6 ayda 1 | 6 aydan seyrek |
| Lead Time for Changes | 1 saatten az | 1 gün – 1 hafta | 1 hafta – 1 ay | 1 – 6 ay |
| Change Failure Rate | %0-5 | %10 | %10-15 | %64+ |
| Failed Deployment Recovery Time | 1 saatten az | 1 gün altı | 1 gün – 1 hafta | 1 hafta – 1 aydan uzun |
| Toplam pazar oranı | %19 | %34 | %30 | %17 |
2024’teki en çarpıcı veri: Elite kümesinin oranı 2022’de %18 iken 2024’te %19’a, 2025 ön sonuçlarına göre %22’ye çıktı. Bu yükseliş özellikle platform mühendisliği (internal developer platforms, Backstage, Port gibi) ve AI-asisted code generation (Copilot, Cursor) etkisine bağlanıyor. Stack Overflow Developer Survey 2024, profesyonel geliştiricilerin %62’sinin AI araçları kullandığını rapor etti; aynı kohort yanıtlarında deployment frequency’nin %30 arttığı belirtildi.
Türkiye perspektifinden bakınca: yerel fintech ve e-ticaret takımlarıyla yürüttüğüm Ömer Önal danışmanlık projelerinde gördüğüm kalıp şudur — DF ve LT metriklerinde Medium-High’a hızlıca çıkılıyor (CI/CD pipeline modernizasyonu yeterli), ancak CFR ve FDRT metriklerinde Low takılıyor (test stratejisi ve observability eksik). Elite’e sıçramak için tek başına araç yetmiyor; ekip kültürü ve özellikle “test-after vs test-driven” pratiğinde dönüşüm gerekiyor.
DORA Ölçüm Pipeline’ı: Açık Kaynak ve Ticari Çözümler
DORA’yı kendi takımınızda ölçmenin üç ana yolu vardır: kendi pipeline’ını kurmak, açık kaynak çözüm benimsemek veya ticari platform satın almak. Her birinin maliyet/karmaşıklık/özelleştirme dengesi farklıdır:
| Çözüm | Tip | Tipik aylık maliyet (50 dev) | Setup zamanı | Avantaj | Dezavantaj |
|---|---|---|---|---|---|
| Apache DevLake | Open-source self-host | ~$50 (sunucu) | 1-2 gün | Geniş entegrasyon, ücretsiz | Maintenance ekip yükü |
| Sleuth.io | SaaS | ~$18/dev | 2-4 saat | UI sıkı, opinionated | Custom metrik kısıtlı |
| LinearB | SaaS | ~$25/dev | 2-4 saat | Goal-setting + alert | Pricier, vendor lock-in |
| Datadog DORA | SaaS modülü | +$10/host (eklenti) | 1 gün | APM ile birleşik | Datadog stack şartı |
| GitHub Insights + custom | Mixed | ~$5/dev (Enterprise) | 1-3 hafta | Veri sahipliği | Gelişmiş raporlama yok |
| Google Cloud DORA Quick Check | Anket bazlı | Ücretsiz | 30 dakika | Hızlı baseline | Anket öznel, gerçek event yok |
Pratik tavsiye: 50 mühendisin altındaki takımlar için Apache DevLake + PostgreSQL + Grafana üçlüsü en iyi maliyet/değer oranını sunar. 50-200 mühendis arası takımlarda Sleuth veya LinearB SaaS, build/maintain operasyonel yükten daha karlı oluyor. 200+ mühendis ve regüle sektör (finans, sağlık, kamu) için veri sahipliği zorunluluğu nedeniyle self-host DevLake + custom dashboard genelde tek seçenek. Otomasyon mimarisi kurarken CI/CD Pipeline Kurulumu rehberindeki webhook standartlarını DevLake collector’larına uygun şekilde örneklemek başlangıç süresini yarıya indiriyor.
Veri toplamada en sık düşülen hata: deploy event’ini yalnızca CI başarısı sayısı olarak kabul etmek. CI başarısı ≠ production deploy. Doğru tanım: production environment’a indirme + smoke test geçişi. ArgoCD/Flux kullanıyorsanız “Application synced + healthy” event’i, Kubernetes RollingUpdate kullanıyorsanız Deployment.status.readyReplicas == desiredReplicas anı, edge deploy (Cloudflare/Vercel) için ise function invocation success > 0 doğrulaması yapılmalı.
Deployment Frequency’yi Artırmanın Pratikleri
Deployment Frequency tek başına bir gösterge değildir; arkasındaki disiplin yoksa rakam manipüle edilir. Elite takımlarda DF artışını destekleyen 6 pratik şöyle sıralanır:
- Trunk-based development: Uzun ömürlü feature branch yerine main üzerinde günlük merge. Avantaj: Merge çatışması azalır. Dezavantaj: Disiplinli code review şart. Ne zaman seç: 5+ kişilik aktif ürün takımı.
- Feature flag mimarisi: LaunchDarkly, Unleash veya GitLab feature flag ile kod prod’a iner ama kapalıdır. Avantaj: Deploy ve release ayrılır; her gün deploy edilebilir. Dezavantaj: Flag debt birikir, temizlik gerekir.
- Progressive delivery: Canary, blue-green, shadow traffic. Avantaj: Risk %1-5 trafiğe sınırlı. Dezavantaj: Ek altyapı (Argo Rollouts, Flagger).
- Pipeline as Code: Workflow tanımı reposunda; review’dan geçer. Avantaj: Tekrarlanabilir, audit edilebilir.
- Pre-merge ephemeral env: PR açılınca otomatik preview env. Avantaj: QA ve PM erken görür. Dezavantaj: Cluster maliyeti.
- Push-button rollback: Tek tıkla önceki versiyona dönüş. Avantaj: Recovery time düşer. Dezavantaj: Database migration geri alınabilir tasarlanmalı.
Container ortamında DF artışı doğrudan orchestration olgunluğuna bağlıdır. Mikroservis mimarisinde her servisin bağımsız deploy edilmesi (genelde günde 5-50 kez) için bkz: Docker Kubernetes Yönetimi rehberi. GitOps yaklaşımıyla declarative deploy yapılırken DF metriği commit history’den otomatik çıkartılabilir; GitOps Kubernetes dökümanındaki ArgoCD Application event akışı, DevLake collector’ı için doğrudan kullanılabilir.
Lead Time for Changes: Komitten Production’a Saat Cinsinden
Lead Time, DORA’nın “developer experience” boyutunu yansıtan metriktir. 2024 verisine göre Elite takımların lead time medyanı 47 dakika; Low takımların medyanı 79 gün. Aradaki 970x fark esas olarak süreç kuyruklarından kaynaklanır: code review beklemesi, manuel QA gate’i, change advisory board (CAB) onayı, manuel deploy adımları.
Lead Time’ı dağıtarak inceleyince genelde aşağıdaki bileşen ağırlıkları çıkar:
| Aşama | Tipik Low (saat) | Tipik Elite (dakika) | Optimizasyon yöntemi |
|---|---|---|---|
| Commit → PR ready | 4-12 | 5-15 | Pre-commit hooks, conventional commits |
| PR → first review | 24-48 | 10-30 | Pair programming, mob review, AI-asisted review |
| Review → approved | 16-72 | 5-20 | Senior on-call reviewer rotation |
| Approved → merged | 2-24 | 1-3 | Auto-merge bot (Mergify, Renovate) |
| Merge → CI complete | 1-3 | 5-15 | Test parallelization, cache, selective testing |
| CI → prod deploy | 4-48 | 1-5 | Continuous deployment, no manual gate |
En büyük iyileştirme genelde “PR → first review” aşamasında yapılır. AI-asisted review (GitHub Copilot Code Review, CodeRabbit, Graphite) 2025 itibarıyla bu süreyi ortalama %47 azaltıyor. Ancak AI review sadece insan review’unun yerine geçemez; security ve mimari kararlarda insan gözü kalmalıdır. GitHub Copilot Code Review dokümantasyonu bu hibrit modelin best practice’lerini ayrıntılı anlatır.
Test parallelization tarafında dikkat edilecek nokta: testleri rastgele paralelleştirmek yerine “selective testing” (Bazel, Nx, Turborepo, GitHub Actions partial matrix) ile sadece etkilenen modülleri çalıştırmak. Microsoft 2024 raporunda Azure DevOps takımının selective testing geçişiyle CI süresini 38 dakikadan 4 dakikaya indirdiğini açıkladı; bu lead time üzerinde tek başına yaklaşık 30 dakika kazanç demek.
Change Failure Rate ve Recovery Time: Stabilite Tarafı
CFR ve FDRT, DORA’nın “stability” çiftidir ve Türkiye’deki takımların en zorlandığı boyuttur. Sebep yapısal: hız ölçen DF/LT pipeline aracıyla ölçülür, ancak stabilite ölçen CFR/FDRT incident sistemi + production observability gerektirir. Birçok takımda observability stack’i ya hiç yok ya da yüzeyseldir.
CFR’yi düşürmek için kanıta dayalı 5 pratik:
- Shift-left testing: Static analysis, SAST, dependency scan PR seviyesinde. CFR ortalama %35 düşer.
- Contract testing: Pact, Spring Cloud Contract gibi araçlarla servisler arası API uyumu CI’da doğrulanır.
- Chaos engineering: Gremlin, LitmusChaos ile prod-like ortamda fault injection. CFR’yi %20-30 düşürür.
- Pre-prod canary: Staging’de gerçek prod trafiğinin %1’i yansıtılır (shadow traffic).
- Database migration safety: Online schema change (gh-ost, pt-osc), backward-compatible migration politikası.
FDRT’yi düşürmenin tek en etkili yolu: otomatik rollback. ArgoCD Rollouts’ta SLI metriği eşik altına düşerse otomatik rollback tetiklenebilir; Flagger benzer şekilde Prometheus query üzerinden rollback yapar. Manuel rollback ortalama 47 dakika sürerken otomatik rollback ortalama 2-4 dakikada tamamlanır. Service mesh kurulu takımlarda Service Mesh dökümanındaki Istio Telemetry v2 metrikleri otomatik rollback için golden signal kaynağı olarak doğrudan kullanılabilir.
Güvenlik kaynaklı CFR de ihmal edilmemeli: 2024 ENISA Threat Landscape raporu, supply chain saldırılarının %32 arttığını gösterdi. CI pipeline’a SAST + SCA + container scan entegre edilirse CFR yan ürün olarak düşer. DevSecOps Shift-Left rehberi bu entegrasyonun pratik adımlarını içerir.
Anti-Pattern’ler: DORA’yı Yanlış Ölçmek ve Vanity Metrics Tuzakları
DORA verisini Goodhart yasası vurur: “Bir metrik hedef olunca metrik olmaktan çıkar.” Aşağıda saha pratiğinde sıkça gözlemlenen 7 anti-pattern var:
| Anti-pattern | Belirti | Çözüm |
|---|---|---|
| Deploy splitting | Tek değişiklik 5 küçük commit’e bölünüp DF şişirilir | “Meaningful change” tanımı + cycle time eşleştirmesi |
| Hotfix farkı saklamak | Hotfix ayrı kategori sayılıp CFR’den çıkarılır | Tüm prod-impacting değişiklik dahil |
| Recovery time = ticket close | Incident kapatma süresi eşitlenir | Servis healthy döndüğü an esas |
| “Lead time = code review” | Sadece review süresi alınır | İlk commit → prod tam tanım |
| Per-team gizli benchmark | Takımlar birbirine karşı sıralanır | Aspirational benchmark, peer learning |
| Tek dashboard sahibi | SRE dashboard’a bakar, dev görmez | Public Grafana + retro’da inceleme |
| “Elite olduk” plato | Elite eşik geçilince motivasyon kalmaz | İçsel hedef + DevEx Score eklemek |
2024 raporunda yeni eklenen “Reliability” beşinci metrik tartışması, DORA topluluğunda ikiye ayrılma yarattı. Bir görüşe göre Reliability (operational SLO başarımı) FDRT/CFR’den ayrı ölçülmeli; karşı görüş ise mevcut dörtlünün zaten reliability’yi yakaladığını savunuyor. Pragmatik yaklaşım: dört metriği temel olarak takip edin, beşinciyi takım olgunlaştığında ekleyin.
Ölçümü dürüstleştirmenin en somut yolu olarak Apache DevLake “Project” kavramını kullanmaktır: takım değil, ürün/servis bazlı metrik. Mikroservis mimarisinde her servis ayrı project olur, böylece “monolith Hızı” gizlenmez. Container guvenliği, konfigürasyon yönetimi gibi cross-cutting konular ayrı projeler olarak ele alınır; Container Güvenliği rehberindeki policy as code yaklaşımı CFR ve FDRT’ye doğrudan etki eder.
2026 Trendleri: AI-Asisted DORA, Platform Engineering ve SPACE Çerçevesi
2026’ya girerken DORA üç önemli evrime daha tanıklık edecek. Birincisi AI-asisted DORA: 2025 raporu ön bulgularına göre AI araçları deployment frequency’yi medyan %30 artırırken, bireysel verim katılımcıların %78’inde arttığı bildirildi. Ancak ilginç bir çelişki var: aynı kohortta CFR de %22 yükseldi. Sebep: AI önerilerine yeterince eleştirel bakılmaması ve test stratejisinin AI’ın ürettiği koda uyarlanmamış olması. 2026 itibarıyla “AI-aware testing” (mutation testing + property-based testing) standart hale geliyor.
İkincisi Platform Engineering ve Internal Developer Platform (IDP): Backstage, Port, Cortex gibi araçlarla self-service deploy mimarisi yaygınlaşıyor. CNCF Platform Engineering Maturity Model 2024 raporunda IDP olgunluğu Level 3+ olan organizasyonların DORA Elite seviyede olma olasılığı 4.2 kat fazla. Cloud-Native Mimari rehberi bu IDP katmanının cloud-native olgunluk modeliyle nasıl iç içe geçtiğini detaylandırıyor.
Üçüncüsü SPACE çerçevesi ile DORA’nın birlikte kullanımı: Microsoft Research’ün 2021’de önerdiği SPACE (Satisfaction, Performance, Activity, Communication, Efficiency) DORA’yı developer experience boyutuyla zenginleştirir. 2024 GitHub Octoverse raporu, SPACE+DORA hibrit ölçümü kullanan takımların retention oranının %18 daha yüksek olduğunu gösterdi.
Sıkça Sorulan Sorular (SSS)
DORA metrikleri sadece büyük şirketler için mi anlamlı?
Hayır. 2024 raporu katılımcılarının %43’ü 50 mühendis altındaki takımlardan. Küçük takımlarda DORA özellikle “ne yapılırsa hızlanırız?” sorusuna data-driven cevap verir. 5-10 kişilik startup’larda Apache DevLake + Grafana setup’ı 1 günde tamamlanır ve ilk haftadan itibaren kullanılabilir baseline çıkar.
DORA’nın yerine SPACE veya başka bir metrik seti kullanılabilir mi?
SPACE DORA’nın yerine değil, üzerine kurulur. DORA “delivery performance” ölçer, SPACE “developer wellbeing” ölçer. İkisi birlikte kullanıldığında bütüncül resim çıkar. McKinsey Developer Velocity Index gibi alternatif çerçeveler de DORA’ya entegre edilebilir; saf DORA ölçümü en kanıt-tabanlı temeldir.
Mikroservis mimarisinde DORA nasıl ölçülür?
Her servis kendi DORA project’i olur. Ortalama almak yerine her servisin metriği ayrı raporlanır. Servis bağımlılıklarında “deploy chain” ölçümü için service mesh telemetrisi kullanılır. Apache DevLake ve Sleuth bu çoklu-project görünümünü destekler; tek dashboard’da tüm servisler heatmap olarak gösterilir.
Recovery time’ı kısaltmak için en kritik yatırım nedir?
Otomatik rollback altyapısı. ArgoCD Rollouts veya Flagger ile SLI tabanlı otomatik rollback kurulduğunda manuel müdahale ortalama 47 dakikadan 2-4 dakikaya iner. İkinci yatırım: production-grade observability (Prometheus + Grafana + distributed tracing). Tracing olmadan root cause analysis süresi 5x uzar.
DORA Elite seviyeye ulaşmanın gerçekçi süresi ne kadardır?
Sıfırdan Elite’e geçiş tipik olarak 18-30 ay sürer. İlk 6 ay: ölçüm pipeline’ı + baseline. Sonraki 12 ay: pipeline as code + trunk-based + feature flags. Son 6-12 ay: progressive delivery + observability olgunluğu. Hızlandırıcılar: yönetici desteği, dedikli platform takımı, açık kültür dönüşümü hedefi. Plato yaşandığında SPACE eklemek motivasyonu canlandırır.
Sonuç
DORA metrikleri 2014’ten bu yana DevOps performans ölçümünün de facto standardı haline geldi; arkasındaki 11 yıllık akademik araştırma ve 50.000+ katılımcılı veri seti, hiçbir alternatif çerçevenin yakalayamadığı kanıt gücü taşıyor. Dört metrik (DF, LT, CFR, FDRT) doğru tanımlanıp dürüst ölçüldüğünde takımların gerçek darboğazlarını ortaya çıkarıyor; Elite kademe vanity hedef değil, gelir büyümesiyle 0.42 korelasyonu olan iş sonucudur.
Karar çerçevesi şudur: 50 mühendis altı takımlarda Apache DevLake self-host ile başlayın, 50-200 arası SaaS (Sleuth/LinearB) tercih edin, 200+ ve regüle sektörde self-host + custom dashboard kurun. Ölçüm pipeline’ı kurulduktan sonra ilk 6 ay sadece baseline’ı izleyin, hedef koymayın. Sonra DF/LT için trunk-based + feature flag + progressive delivery; CFR/FDRT için shift-left testing + chaos engineering + otomatik rollback yatırımlarına odaklanın. Goodhart yasasından korunmak için metriği takım rekabetine değil, peer learning mekanizmasına çevirin.
DORA pipeline’ını kurarken tipik tuzaklara düşmemek ve sektörünüze özel benchmark eşiklerini doğru yorumlamak için iletişim sayfası üzerinden ayrıntılı atölye veya saha denetimi planlanabilir. Doğru kurulmuş bir DORA dashboard’u yalnızca rapor değil; takımın haftalık retro’sunda karar aracına dönüşür.
Ömer ÖNAL
Mayıs 16, 2026DevOps danışmanlık projelerinde gözlemlediğim bir pattern: kuruluşlar pipeline’a yatırım yapmadan önce mevcut deployment frequency ve change failure rate metriklerini ölçmüyor. Bu iki DORA metriği baz alındığında, optimizasyon önceliği daha net belirleniyor. Aksi takdirde yatırım kararı sezgisel kalıyor. Yorumlarınızı bekliyorum.