DORA & Accelerate
As 4 métricas que diferenciam time alta-performance — e como medir sem virar vanity metric
Pesquisa empírica: Accelerate (Forsgren, Humble, Kim) analisou milhares de orgs e identificou 4 métricas que separam elite de low performers. Não é opinião — é dado. Times que melhoram essas 4 métricas têm 2x mais lucro, satisfação e estabilidade.
As 4 métricas DORA
| Métrica | O que mede | Como calcular |
|---|---|---|
| Deployment Frequency (DF) | Quantos deploys em produção por unidade de tempo | Contar pipelines bem-sucedidos para prod / dia |
| Lead Time for Changes (LT) | Tempo entre commit e produção | p50 e p95 do tempo entre PR merged → deploy em prod |
| Change Failure Rate (CFR) | % de deploys que causam degradação (rollback, hotfix, incidente) | Incidentes causados por deploy / total de deploys |
| Mean Time to Restore (MTTR) | Tempo médio para restaurar serviço após falha | Início da degradação → resolução, média sobre incidentes |
Por que essas 4 juntas
DF + LT medem velocidade: o time entrega frequente e rápido?
CFR + MTTR medem estabilidade: quando algo dá errado, é frequente? recupera rápido?
A descoberta da pesquisa: velocidade e estabilidade andam juntas, não em trade-off. Time que deploya mais frequente também falha menos, porque mudanças são menores e mais reversíveis.
CFR + MTTR medem estabilidade: quando algo dá errado, é frequente? recupera rápido?
A descoberta da pesquisa: velocidade e estabilidade andam juntas, não em trade-off. Time que deploya mais frequente também falha menos, porque mudanças são menores e mais reversíveis.
Como instrumentar
# Fontes de dado típicas para as 4 métricas
Deployment Frequency:
- GitHub Actions / GitLab CI / Jenkins → events de "deploy to prod success"
- Argo CD / Flux → sync events
- Tagged releases com convenção (vX.Y.Z para prod)
Lead Time for Changes:
- PR merged timestamp → primeira ocorrência em prod (event do deploy)
- Quebrar por tipo (feature, hotfix); excluir reverts
Change Failure Rate:
- Incidentes (PagerDuty/Opsgenie) marcados com "caused by deploy"
- Rollbacks (% deploys revertidos em < 4h)
- Hotfixes pra produção (PR labeled 'hotfix' em < 24h após deploy)
Mean Time to Restore:
- Incident open → resolved timestamps
- Apenas P0/P1 (excluir tickets normais)
- Mediana e p95 — média esconde os outliers que importam
Tooling pronto:
- DORA Quickstart (Google) https://github.com/dora-team/fourkeys
- Jellyfish, LinearB, Sleuth (SaaS)
- Backstage plugin DORA
Frequência de medição
- Mensal: dashboard de saúde do time/produto
- Trimestral: revisão e ajuste de práticas
- Semanal: tendência (não use número absoluto, e sim direção)
Por que MTTR sem CFR é enganador?
MTTR sozinho pode parecer ótimo (15min!) mas se CFR é 30%, você está restaurando rápido um sistema que quebra direto — péssimo. MTTR sozinho também incentiva esconder incidentes ("foi só uma instabilidade"). As métricas só fazem sentido combinadas: alta DF + alta LT (velocidade), com baixa CFR + baixa MTTR (estabilidade). Olhar uma sem as outras vira gaming.