DORA Metrics

Jak często team deployuje kod na produkcję

Czas od commitu do deploymentu na produkcję

Odsetek deploymentów powodujących incydent

Średni czas naprawy po incydencie produkcyjnym

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ą.

Wyślij zapytanie