As DORA Metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate e Mean Time to Recovery — são um dos jeitos mais eficientes de entender como está a performance do seu time de engenharia.
Criadas pela equipe da DevOps Research and Assessment (DORA), hoje parte do Google Cloud, essas quatro métricas vêm sendo usadas por empresas de todos os tamanhos para identificar gargalos, medir evolução e justificar decisões com dados. Mas pra isso funcionar de verdade, você precisa olhar pra elas com um olhar mais estratégico, e menos operacional.
Esse guia é exatamente sobre isso: como medir as DORA Metrics do jeito certo e usar cada uma como alavanca pra melhorar entregas.
Deployment Frequency: com que frequência você entrega valor em produção?
Essa é a métrica mais direta: ela mede quantas vezes por dia, semana ou mês seu time faz deploy em produção. E embora pareça simples, ela revela muito mais do que parece.
Se o time faz deploy frequente, significa que os ciclos são curtos, o risco é menor e o feedback vem mais rápido. Se o deploy demora pra acontecer, pode ter gargalo em revisão de PRs, medo de quebrar algo, ou falta de automação no pipeline.
Como calcular:
- Defina o período (ex: 10 dias)
- Conte quantos deploys aconteceram
- Divida o número de deploys pelos dias
Se foram 20 deploys em 10 dias, você tem uma média de 2 deploys por dia.
Benchmarks (State of DevOps Report):
- Baixa performance: menos de 1 vez por mês
- Média: entre 1x/mês e 1x/semana
- Alta: pelo menos 1x por semana ou mais
Change Failure Rate: quantas mudanças em produção quebram algo?
Essa métrica mostra a proporção de deploys que resultam em rollback, hotfix ou incidentes em produção. Ela é essencial pra entender a estabilidade das suas entregas.
Se o time está entregando rápido, mas sempre quebrando algo, o problema não está na velocidade, mas na qualidade. Essa é a métrica que te obriga a olhar pra testes, cobertura de QA, revisões e validação de requisitos.
Como calcular:
- Conte todos os deploys feitos em um período
- Conte quantos deram problema
- Divida os com falha pelo total e multiplique por 100
Exemplo:
- 20 deploys, 3 com falha
- CFR = (3 / 20) × 100 = 15%
Benchmarks:
- Baixa performance: acima de 15%
- Média: entre 5% e 15%
- Alta: menos de 5%
Mean Time to Recovery (MTTR)
Mean Time to Recovery: quando quebra, quanto tempo leva pra voltar ao normal?
Falhas vão acontecer. A questão é: seu time consegue reagir rápido?
O MTTR mostra quanto tempo leva, em média, pra restaurar o serviço depois de um problema em produção. É uma medida da sua resiliência operacional.
Como calcular:
- Liste os incidentes no período
- Registre o timestamp de início e fim de cada um
- Calcule o tempo de duração e tire a média
Exemplo:
- Incidentes: 3
- Duração total: 135 minutos
- MTTR = 135 / 3 = 45 minutos
Benchmarks:
- Baixa performance: mais de 1 dia
- Média: entre 1h e 1 dia
- Alta: menos de 1h
Um MTTR alto geralmente aponta pra falta de observabilidade, processos de resposta mal definidos ou pouca autonomia do time em incidentes.
Por que medir bem essas métricas muda o jogo
Olhar pra essas métricas de forma superficial não resolve. O valor está em usá-las pra responder perguntas reais:
- Por que nossas entregas estão lentas?
- Por que a gente quebra tanto em produção?
- Onde vale investir pra melhorar o fluxo?
Métrica boa não é pra encher dashboard. É pra guiar decisões. E quando bem usadas, as DORA Metrics ajudam a transformar a cultura do time: de reativa pra evolutiva, de opinativa pra orientada por dados.
Comece pequeno. Escolha uma métrica. Meça. Mostre pro time. Melhore. Repita.
FAQ: DORA Metrics na prática
Preciso medir todas as 4 métricas desde o início?
Não. Comece com uma ou duas que sejam mais simples de extrair e que respondam perguntas urgentes do seu time. Lead Time e Deployment Frequency são boas portas de entrada.
Com que frequência devo acompanhar essas métricas?
Depende do seu ciclo. Revisar a cada sprint ou quinzenalmente costuma ser o suficiente pra identificar tendências sem sobrecarregar.
Essas métricas funcionam mesmo em times pequenos?
Sim. Times pequenos têm a vantagem de poder agir rápido com base nos dados. As métricas só precisam ser adaptadas para não reagir a variações muito bruscas.
Como garantir que essas métricas não sejam usadas pra microgerenciar?
Deixe claro que o foco é melhorar o sistema, não medir indivíduos. Compartilhe os dados com o time, estimule conversas, não cobranças. Cultura vem antes do dashboard.
