Guia de métricas DORA
O guia da Mensor para entender, medir e, principalmente, melhorar as quatro métricas DORA, sem cair nas armadilhas clássicas. Escrito para líderes de engenharia; as definições valem para qualquer ferramenta, não só a nossa.
O que é DORA (e por que virou o padrão)#
DORA (DevOps Research and Assessment) é o programa de pesquisa que, desde 2014, estuda o que separa times de engenharia de alta performance dos demais. Hoje é mantido pelo Google Cloud, com relatórios anuais (Accelerate State of DevOps, em dora.dev). O livro Accelerate (Forsgren, Humble e Kim, 2018) consolidou a descoberta central: quatro métricas de entrega predizem performance organizacional e, contra a intuição, velocidade e estabilidade andam juntas: os times mais rápidos também são os mais estáveis.
As quatro, em duas duplas:
| Métrica | Pergunta que responde | |
|---|---|---|
| Velocidade | Deployment frequency | Com que frequência entregamos em produção? |
| Lead time for changes | Quanto tempo uma mudança leva do commit à produção? | |
| Estabilidade | Change failure rate (CFR) | Que % das entregas causa falha? |
| MTTR (time to restore) | Quanto tempo levamos para restaurar após uma falha? |
A leitura certa é em conjunto: frequência alta com CFR alto é pressa, não performance. Lead time baixo com MTTR alto é risco escondido. O jogo é subir a velocidade sem pagar em estabilidade.
As fórmulas (as mesmas que usamos)#
- Deployment frequency =
deploys de produção ÷ dias do período. - Lead time for changes =
mediana de (término do deploy de produção − primeiro commit da mudança), só deploys com sucesso. Mediana, não média: um único deploy atrasado não deve distorcer o número. - Change failure rate =
deploys que causaram falha ÷ total de deploys de produção. - MTTR = tempo médio da abertura do incidente à resolução (com uma fonte de incidentes real) ou, como aproximação, do deploy com falha ao próximo deploy com sucesso no mesmo serviço.
Os tiers de 2023#
| Métrica | elite | good | fair | poor |
|---|---|---|---|---|
| Deployment frequency | ≥ 1/dia | ≥ 1/semana | ≥ 1/mês | < 1/mês |
| Lead time for changes | ≤ 24 h | ≤ 1 semana | ≤ 1 mês | > 1 mês |
| Change failure rate | ≤ 5% | ≤ 10% | ≤ 15% | > 15% |
| MTTR | ≤ 1 h | ≤ 24 h | ≤ 1 semana | > 1 semana |
Use os tiers como bússola, não como meta cega: um monólito regulado com deploy semanal saudável pode valer mais que um "elite" com CFR maquiado.
As armadilhas que estragam a medição#
A maioria dos dashboards DORA mente sem querer. Os erros que vemos com mais frequência:
- CFR 0% por falta de sinal. Se nada reporta falha (nenhum monitor de incidentes, CI que nunca marca deploy como FAILURE), o CFR "dá" 0% e o tier vira um elite falso. O honesto é distinguir "0% medido" de "sem dado". No Mensor, o CFR usa uma cadeia de fonte explícita (incidentes do PagerDuty → erros do Sentry → status do deploy) e mostra qual fonte está em uso; sem evidência de sinal, o número fica vazio em vez de mentir.
- Contar "deploy" que não é deploy. Merge em
mainnão é entrega em produção. Quando não há CI/CD de deploy conectado, inferir é aceitável, desde que os deploys inferidos sejam marcados como tal e deduplicados contra os reais. É o que fazemos com os deploys sintéticos. - Média em vez de mediana no lead time. Um único hotfix de 10 minutos ou um deploy preso por um mês destroem a média. Mediana + percentis contam a história real (o típico e a cauda).
- MTTR medindo população errada. Incidentes resolvidos por merge (duplicados agrupados) não são restauração; incidentes de serviços que não fazem deploy não deveriam entrar na conta do DORA. População do MTTR = população do CFR.
- Otimizar a métrica, não o sistema. Quebrar um deploy em dez para inflar a frequência, ou reabrir incidentes como "novos" para zerar o MTTR. As quatro métricas existem para expor gargalos do fluxo: se viram alvo individual, viram teatro (lei de Goodhart).
Como melhorar cada uma (o que a pesquisa diz)#
- Deployment frequency: reduza o tamanho do lote: PRs menores, trunk-based development, feature flags para separar deploy de release. Frequência é consequência de lote pequeno, não de pressa.
- Lead time: ataque o maior estágio do seu cycle time. Na prática, o gargalo raramente é o build: é a espera por review (pickup) e a esteira de entrega. Meça por fase antes de otimizar no escuro.
- CFR: invista em testes automatizados que o time confia, revisão de código distribuída e deploys pequenos (mudança pequena = raio de explosão pequeno). CFR alto com lote grande é sintoma, não causa.
- MTTR: observabilidade (saber que quebrou antes do cliente), rollback barato e on-call claro. Times elite não erram menos: se recuperam mais rápido.
DORA não é tudo#
O próprio time da pesquisa alerta: quatro números não descrevem produtividade. O framework SPACE (Forsgren et al., ACM Queue, 2021, em queue.acm.org) lembra que satisfação, colaboração e fluxo importam tanto quanto vazão. Por isso, ao lado do DORA, olhe o cycle time por fase, a rede de review (bus factor, silos), rework e PRs parados, e nunca use nada disso para ranquear pessoas. Métrica de fluxo mede o sistema, não o indivíduo.
Como a Mensor mede#
Conecte o GitHub/GitLab/Azure DevOps (leitura apenas) e as quatro métricas são calculadas do seu histórico real, com PagerDuty/Sentry opcionais para CFR/MTTR por incidentes. Cada número tem um modal "como é calculado" com a fórmula, e a tela Saúde dos dados mostra a proveniência (real, estimado ou pendente) de tudo que você vê. As definições completas estão no glossário de métricas.
Fontes#
- dora.dev: pesquisa DORA e relatórios Accelerate State of DevOps (tiers da edição 2023).
- Forsgren, N.; Humble, J.; Kim, G. Accelerate (2018).
- Forsgren et al. The SPACE of Developer Productivity, ACM Queue (2021).
Próximos passos#
- Glossário de métricas: as fórmulas de todos os indicadores.
- Guia rápido: do zero à primeira métrica.
- Ver a demo ao vivo: os painéis DORA rodando, sem cadastro.