DORA Metrics
Cztery metryki zwalidowane na bazie badań ponad 33,000 profesjonalistów DevOps. Elite performers deployują 208x częściej i naprawiają incydenty 2604x szybciej niż Low performers.
Cztery metryki DORA
Dwie metryki Throughput (szybkość dostarczania) i dwie Stability (stabilność). Balans obu jest kluczem — szybkość bez stabilności nie jest wartościowa.
Deployment Frequency
Jak często team deployuje kod na produkcję
Change Lead Time
Czas od commitu do deploymentu na produkcję
Change Failure Rate
Odsetek deploymentów powodujących incydent
Mean Time to Restore
Średni czas naprawy po incydencie produkcyjnym
Dźwignie poprawy DORA Metrics
Każda metryka ma konkretne taktyki poprawy. Zacznij od najniżej wiszącego owocu dla swojego aktualnego tier.
Trunk-based development + feature flags
Małe PRy (max 400 linii) + automated review
Ephemeral environments dla każdego PR
Parallel CI jobs, cache dependencies
Canary / progressive delivery rollouts
SLO-based alerting + runbooks dla top incydentów
Często zadawane pytania
Co to są DORA Metrics i dlaczego są ważne?
DORA Metrics (DevOps Research and Assessment) to cztery metryki opracowane przez Google/DORA team na podstawie badań ponad 33,000 profesjonalistów DevOps. Mierzą wydajność software delivery i operational stability. Są najlepiej zwalidowanymi empirycznie miarami efektywności dostarczania oprogramowania. Cztery metryki: Deployment Frequency (DF) — jak często organizacja deployuje na produkcję. Change Lead Time (CLT) — czas od commitu do deploymentu na produkcję. Change Failure Rate (CFR) — odsetek deploymentów powodujących incydent/rollback. Mean Time to Restore (MTTR) — średni czas naprawy po incydencie. DORA performance tiers: Elite, High, Medium, Low. Elite performers (top 25%) deployują on-demand (wielokrotnie dziennie), CLT poniżej 1 godziny, CFR poniżej 5%, MTTR poniżej 1 godziny. Dlaczego ważne: badania DORA wykazały że Elite performers mają 208x więcej deployów, 106x szybszy CLT i 2604x szybszy MTTR niż Low performers. Korelacja z wynikami biznesowymi: wyższy NPS, niższy churn, wyższa profitability.
Jak mierzyć DORA Metrics w swoim zespole?
Mierzenie DORA Metrics: Deployment Frequency: policz deploye na produkcję per tydzień/miesiąc. Zdefiniuj co liczy się jako deployment — każda zmiana, nie tylko release. Narzędzia: GitHub Actions workflow events, Argo CD deployment history, DORA metrics dashboards (LinearB, Sleuth, Jellyfish). Change Lead Time: czas od pierwszego commitu w PR do deployment na produkcję. Wyzwanie: musisz połączyć dane z Git, CI/CD i deployment system. Narzędzia: Faros AI, LinearB, Sleuth — automatycznie kalkulują z API GitHub/GitLab. Change Failure Rate: liczba incydentów / liczba deploymentów × 100%. Wymaga integracji z incident management (PagerDuty, OpsGenie). Jeśli brak formal incident management — trudno mierzyć. Mean Time to Restore: czas od wykrycia incydentu do pełnego recovery. Dane: PagerDuty alert created timestamp vs. resolved timestamp. Segmentuj MTTR per severity (P1 vs. P2 vs. P3). Pułapki: nie mierz tylko tych metryk które wyglądają dobrze. DORA jest wartościowe tylko przy honest measurement.
DORA Elite vs. High vs. Medium vs. Low — benchmarki?
DORA Performance Tiers (2023 State of DevOps Report): Elite performers: Deployment Frequency — on demand (wiele razy dziennie). Change Lead Time — poniżej 1 godziny. Change Failure Rate — 0-5%. MTTR — poniżej 1 godziny. High performers: DF — raz dziennie do raz tygodniowo. CLT — 1 dzień do 1 tygodnia. CFR — 5-10%. MTTR — 1 dzień. Medium performers: DF — raz tygodniowo do raz miesięcznie. CLT — 1 tydzień do 1 miesiąca. CFR — 10-15%. MTTR — 1 dzień do 1 tygodnia. Low performers: DF — raz miesięcznie lub rzadziej. CLT — 1-6 miesięcy. CFR — 15-30%+. MTTR — ponad 1 tydzień. Kontekst: typowy nowy startup z małym team może być w High tier. Legacy enterprise z monolitem często w Low/Medium. Elite tier to Amazon, Google, Netflix — ale wiele mid-size SaaS firm tam dochodzi. Cel: nie celuj w Elite od razu — skup się na przejściu z Low do Medium, Medium do High.
Jak poprawić DORA Metrics — strategie dla każdej metryki?
Poprawa DORA Metrics per metryka: Deployment Frequency (niska): Problem — duże, rzadkie deploye. Rozwiązanie: trunk-based development (małe, częste PRy). Feature flags — rozdziel deployment od release. Automated testing — usuń ręczne testy jako bramkę. Change Lead Time (długi): Problem — długi review, wolne CI, manualne etapy. Rozwiązanie: limity PR size (max 400 linii). Parallel CI jobs. Automatyczne staging environment dla każdego PR (Ephemeral environments). Eliminacja manualnych approval dla non-prod environments. Change Failure Rate (wysoki): Problem — za mało testów, brak staging, brak code review. Rozwiązanie: wymagaj automated tests jako merge requirement. Canary deployments / progressive delivery. Lepszy staging environment parity. Pair programming lub mandatory 2nd reviewer. MTTR (długi): Problem — słaby alerting, trudna diagnoza, brak runbooks. Rozwiązanie: SLO-based alerting (alert na symptomy, nie przyczyny). Distributed tracing (Jaeger, Tempo). Runbooks dla top 10 incydentów. Chaos Engineering — trenuj recovery zanim nastąpi prawdziwy incydent. Blameless post-mortems po każdym P1/P2.
DORA Metrics a 5th metric — Reliability i burnout?
5th DORA Metric — Reliability: W 2021 DORA dodał 5. metrykę — Reliability (niezawodność), mierzoną przez Operational Performance: czy system osiąga swoje availability i performance targets? Reliability = suma SLO achievement + incident count + on-call experience. SPACE framework (GitHub Research, 2021): alternatywne podejście do mierzenia developer productivity. Satisfaction and wellbeing, Performance, Activity, Communication, Efficiency. Burnout correlation: badania DORA wykazały że Low performers mają znacznie wyższy poziom burnout wśród inżynierów. Elite performers — niższy burnout przez: mniej manualne procesy, szybszy recovery, rzadsze nocne incydenty. Developer Experience (DevEx): nowy trend — mierzenie Developer Experience jako leading indicator produktywności i retencji inżynierów. SPACE + DORA + DevEx = holistic engineering effectiveness measurement. Praktyczne zastosowanie: DORA metrics powinny informować decyzje inwestycyjne w tooling, processes i architecture — nie być celem samym w sobie. Goodhart's Law: gdy miara staje się celem, przestaje być dobrą miarą.
Powiązane artykuły
Skontaktuj się z nami
Porozmawiajmy o Twoim projekcie. Bezpłatna wycena w ciągu 24 godzin.
Wyślij zapytanie
Telefon
+48 790 814 814
Pon-Pt: 9:00 - 18:00
adam@fotz.pl
Odpowiadamy w ciągu 24h
Adres rejestrowy
Poznańska 117/11
62-023 Kamionki · obsługa zdalna