Métricas DORA

O programa de pesquisa DORA passou anos medindo milhares de organizações procurando o que separa quem entrega bem de quem entrega mal. A descoberta contraintuitiva é a parte importante: velocidade e estabilidade não se opõem. Os times que entregam mais vezes por dia também são os que quebram menos e se recuperam mais rápido.

Isso derruba a premissa por trás de quase todo processo de mudança pesado. Comitê de aprovação, janela de deploy mensal e congelamento de código são justificados como proteção da estabilidade — e os dados dizem que eles produzem o contrário.

As quatro métricas

Duas medem velocidade, duas medem estabilidade. Elas só significam alguma coisa em conjunto.

Métrica	Pergunta que responde	Eixo
Frequência de deploy	Com que frequência colocamos código em produção?	Velocidade
Lead time para mudança	Quanto tempo do commit até rodar em produção?	Velocidade
Tempo de restauração	Quanto tempo para voltar ao normal depois de uma falha?	Estabilidade
Taxa de falha em mudança	Que fração dos deploys causa problema?	Estabilidade

Armadilha

Otimizar uma métrica isolada é o erro clássico. Frequência de deploy alta com taxa de falha alta é caos, não performance. Taxa de falha zero com um deploy por trimestre é paralisia, não qualidade.

Frequência de deploy

Quantas vezes o código chega a produção num período.

Não é uma medida de produtividade — é uma medida de tamanho de lote. Deploy diário significa que cada deploy carrega um dia de mudança. Deploy trimestral carrega três meses, e quando algo quebra você tem centenas de mudanças candidatas a culpada.

As faixas de referência da pesquisa:

Nível	Frequência
Elite	Sob demanda, várias vezes ao dia
Alto	Entre uma vez por dia e uma vez por semana
Médio	Entre uma vez por semana e uma vez por mês
Baixo	Menos de uma vez por mês

Como coletar: conte os deploys bem-sucedidos por serviço, por dia. A fonte mais confiável é o próprio sistema de deploy, não o Git — nem todo merge vira deploy.

# Deploys por dia, a partir de um contador incrementado pelo pipeline.
sum by (servico) (increase(deploys_total{status="sucesso"}[1d]))

Lead time para mudança

O tempo entre o commit e aquele código servindo tráfego real.

É a métrica mais reveladora das quatro, porque expõe todo o atrito do processo: espera por revisão, fila de CI, aprovação manual, janela de deploy, ambiente de homologação disputado. Um lead time de três semanas com um pipeline de dez minutos significa que 20 dias e 23 horas foram espera, não trabalho.

Nível	Lead time
Elite	Menos de uma hora
Alto	Entre um dia e uma semana
Médio	Entre uma semana e um mês
Baixo	Mais de um mês

Como coletar: para cada deploy, pegue o horário de cada commit incluído e calcule a diferença até o deploy. Use a mediana, não a média — um commit esquecido numa branch por dois meses distorce a média inteira.

O diagnóstico que importa

Separe o lead time em tempo de processo (alguém trabalhando) e tempo de espera (nada acontecendo). Na maioria das organizações, mais de 80% é espera. É aí que estão os ganhos fáceis, e não em deixar o build 30 segundos mais rápido.

Tempo de restauração

Quanto tempo, do início do impacto até o serviço voltar ao normal.

Repare que a medida é sobre restaurar, não sobre consertar. Rollback em quatro minutos e investigação com calma no dia seguinte é um resultado excelente. Times que insistem em diagnosticar antes de mitigar têm tempo de restauração ruim por escolha de processo, não por limitação técnica.

Nível	Tempo de restauração
Elite	Menos de uma hora
Alto	Menos de um dia
Médio	Entre um dia e uma semana
Baixo	Mais de uma semana

Como coletar: do sistema de incidentes. Marque o início pelo horário do impacto ao usuário, não pelo horário em que alguém percebeu — senão você está medindo a sua detecção, e uma detecção ruim melhora artificialmente o número.

Taxa de falha em mudança

Que porcentagem dos deploys resulta em degradação que exige correção imediata: rollback, correção às pressas, desligamento de funcionalidade.

Nível	Taxa de falha
Elite / Alto / Médio	Até 15%
Baixo	Acima de 40%

Como coletar: divida os deploys que geraram incidente ou rollback pelo total de deploys. Exige disciplina em ligar incidente ao deploy que o causou — normalmente uma tag ou campo obrigatório no registro do incidente.

Armadilha

Não confunda com “quantidade de bugs”. Um bug cosmético descoberto duas semanas depois não é falha em mudança. A definição é: o deploy exigiu remediação imediata.

A quinta métrica: confiabilidade

Edições mais recentes da pesquisa acrescentaram uma medida de confiabilidade operacional — na prática, o quanto o serviço cumpre as expectativas dos usuários. É onde SLI, SLO e error budget entram: as quatro métricas descrevem o processo de entrega, e a quinta descreve o resultado para quem usa.

Um time pode ter as quatro métricas em nível elite entregando rápido um produto instável. A quinta métrica é o contrapeso.

Como essas métricas são distorcidas

Toda métrica vira alvo, e todo alvo vira jogo. Vale conhecer as distorções antes de alguém as descobrir sozinho.

Frequência de deploy — fatiar uma mudança em cinco deploys sem valor independente para inflar a contagem. Ou contar deploy em ambiente de homologação.

Lead time — abrir o pull request só quando o código já está pronto e revisado informalmente, para que o relógio comece tarde. Ou medir a partir do merge, e não do primeiro commit.

Tempo de restauração — declarar o incidente resolvido quando o alerta silencia, com o usuário ainda afetado. Ou registrar o incidente só depois de já ter mitigado.

Taxa de falha — não registrar incidente pequeno. Chamar rollback de “ajuste de rotina”. Esta é a mais fácil de distorcer e a que menos gente audita.

Não faça isso

Usar métricas DORA para comparar times entre si, ou para avaliação individual de desempenho. No instante em que a métrica afeta a avaliação de alguém, ela deixa de medir o sistema e passa a medir a criatividade das pessoas em produzir o número.

Estas são métricas de tendência de um time ao longo do tempo. Um time que mexe em sistema legado regulado vai ter números piores que um time de produto novo — e isso não diz nada sobre nenhum dos dois.

Por onde começar a melhorar

Comece pelo lead time, porque ele expõe o gargalo e porque melhorá-lo geralmente melhora as outras três de tabela.

1. Meça o estado atual por duas ou três semanas antes de mudar qualquer coisa. Sem linha de base, você não sabe se melhorou.
2. Separe processo de espera. Desenhe o caminho do commit até produção com os tempos reais de cada etapa. O resultado costuma surpreender quem desenhou o processo.
3. Ataque a maior espera. Quase sempre é revisão de código parada ou aprovação manual. Pull request menor é revisado mais rápido — e reduzir o tamanho do lote melhora todas as quatro métricas ao mesmo tempo.
4. Torne o rollback trivial e testado. Isso derruba o tempo de restauração e, por consequência, reduz o medo que sustenta os processos pesados.
5. Só então automatize mais. Automatizar um processo ruim entrega um processo ruim mais rápido.

Leituras relacionadas

• Por que lotes pequenos vencem — a mecânica por trás de quase todos os ganhos aqui
• Quando a métrica vira alvo — lei de Goodhart aplicada a engenharia
• SPACE e produtividade — por que uma métrica só sempre mente
• Estratégias de deploy — como reduzir o risco de cada deploy individual