O que São as Métricas DORA? Guia Prático para Devs

O que sao as metricas dora? São quatro medições que quantificam a performance na entrega de software: Frequência de Deployment, Lead Time para Mudanças, Taxa de Falha de Mudanças e Tempo para Restaurar Serviço. Desenvolvidas por Nicole Forsgren, Jez Humble e Gene Kim, validadas em dezenas de milhares de times de engenharia, e adquiridas pelo Google em 2018. Este guia cobre o que cada métrica rastreia, como os benchmarks funcionam na prática, e os limites do modelo.

De onde vieram as métricas DORA e por que a pesquisa importa

O programa DORA começou em 2014 com uma pergunta específica: o que os times de software de alto desempenho fazem de maneira diferente? O time de pesquisa rodou surveys anuais com dezenas de milhares de desenvolvedores em diferentes indústrias, procurando pelas práticas que prediziam resultados fortes de entrega de software.

O descoberta que virou referência foi contraintuitiva. Times elite não negociavam velocidade por estabilidade. Eles entregavam mais rápido e tinham menos incidentes em produção. Esse resultado desmentiu a justificativa padrão para desacelerar ciclos de release: se deployamos menos vezes, vamos quebrar menos coisas.

Os dados diziam o oposto. Times que deployavam com frequência construíram melhores loops de feedback, capturavam problemas mais cedo e se recuperavam mais rápido quando algo dava errado. Velocidade e estabilidade não estavam em oposição. Estavam correlacionadas.

Google adquiriu o programa DORA em 2018. O time agora publica o anual State of DevOps Report, atualizou o modelo em 2025 com uma quinta métrica (Taxa de Retrabalho), e mantém a pesquisa como uma iniciativa aberta em dora.dev.

As quatro medições e o que cada uma realmente rastreia

O modelo foi atualizado em 2025 para adicionar Taxa de Retrabalho como quinta métrica, mas as quatro chaves originais continuam sendo a baseline para a maioria das ferramentas e discussões de times.

Frequência de Deployment

Quantas vezes seu time empurra para produção. Essa é a definição completa.

Times elite deployam sob demanda: múltiplas vezes por dia quando algo está pronto. Baixo desempenho significa uma vez por mês ou menos, às vezes uma vez a cada vários meses. Para um builder solo, qualquer cadência consistente de ship semanal coloca você solidamente no bracket de alto desempenho só por essa métrica.

Frequência de deployment é um proxy para confiança no pipeline. Times que deployam infrequentemente geralmente têm infraestrutura frágil, gates de testes manuais pesados, ou cadeias de aprovação organizacional que desaceleram releases. Times que shipam múltiplas vezes por dia automatizaram a maioria desses gargalos. A frequência é um sintoma, não a causa.

Lead Time para Mudanças

O tempo desde um commit chegar ao versionamento até essa mesma mudança estar viva em produção.

A maioria dessa duração não é escrever código. É esperar: esperando a fila de pull requests limpar, esperando pipelines de CI/CD terminarem, esperando um slot de deployment, esperando alguém com acesso disparar a release. Um lead time de poucas horas significa o workflow é apertado e largamente automatizado. Um lead time medido em semanas significa algo estrutural está adicionando friction em um ou mais desses pontos de handoff.

Para desenvolvedores solo, lead time é tudo aquilo que fica entre fazer push de um commit e usuários verem o resultado. Às vezes é um pipeline de deployment que leva doze minutos. Às vezes é hesitação interna sobre se uma mudança é estável o bastante para shippar.

Taxa de Falha de Mudanças

O percentual de deployments que causa um problema sério o bastante para requerer um hotfix, rollback ou resposta de incidente.

Esse é o sinal de qualidade no modelo DORA. O State of DevOps Report 2024 coloca times elite em torno de 5% de taxa de falha de mudanças. Baixo desempenho roda em 46 a 63%. Se aproximadamente metade dos seus deployments requerem intervenção imediata, sua cobertura de testes e processo de review têm gaps estruturais significativos.

Taxa de falha de mudanças não mede qualidade de código de forma abstrata. Mede se as mudanças que você shippa se comportam como esperado no ambiente de produção especificamente. Uma suite de testes que passa localmente mas não cobre os caminhos de integração que falham em produção não vai mover esse número.

Tempo para Restaurar Serviço

Quando um deployment causa um incidente, quanto tempo até o serviço estar restaurado?

Isso foi originalmente labelado Mean Time to Recovery (MTTR). O time DORA atualizou o framing em 2025 para Failed Deployment Recovery Time, rastreando especificamente recuperação de incidentes causados por deployment ao invés de falhas de infraestrutura ou outages de terceiros. A distinção importa porque incidentes causados por deployment estão totalmente no controle do time, o que os torna o alvo certo para melhoria de processo.

Times elite restauram serviço em menos de uma hora. Baixo desempenho pode levar dias até uma semana. Se você é um builder solo, essa métrica é largamente sobre ter monitoring em lugar nenhum. Times sem infraestrutura de alerting descobrem sobre falhas por reclamações de usuários ao invés de sinais automatizados, o que adiciona horas a qualquer tempo de recuperação.

Como os tiers de performance funcionam na prática

O relatório State of DevOps agrupa times em quatro tiers baseado nos seus números de DORA. Essas são faixas aproximadas do relatório de 2024, não cutoffs rígidos:

| Tier | Frequência de Deployment | Lead Time | Taxa de Falha | Tempo de Recuperação | |---|---|---|---| | Elite | Múltiplas vezes por dia | Menos de 1 hora | Menos de 5% | Menos de 1 hora | | Alto | Diário a semanal | 1 dia a 1 semana | 5-10% | Menos de 1 dia | | Médio | Semanal a mensal | 1 semana a 1 mês | 10-15% | 1 dia a 1 semana | | Baixo | Mensal ou menos | 1 a 6 meses | 46-63% | 1 semana a 6 meses |

O gap entre elite e baixo não é incremental. De acordo com o relatório de 2024, times de baixo desempenho podem levar mais de 180 vezes mais tempo para deployar e mais de 2.500 vezes mais tempo para se recuperar de incidentes comparado a times elite. Essas não são diferenças marginais.

Atingir o tier elite é alcançável com investimento sustentado em automação de CI/CD, cobertura de testes e tooling de observabilidade. Não acontece escrevendo código mais rápido. Acontece removendo os passos manuais e períodos de espera entre commitar código e ter ele rodando em produção de forma confiável.

Como as ferramentas de desenvolvimento com IA estão mudando os números de DORA em 2026

Em 2026, ferramentas de coding com IA ficaram comuns o bastante para afetar as métricas DORA de maneiras que merecem rastreamento específico.

Times usando Cursor, GitHub Copilot ou ferramentas similares estão escrevendo código mais rápido, o que tende a empurrar a frequência de deployment para cima. Lead time também encurtou em muitos times porque mais código é produzido por desenvolvedor por semana, o que significa mais commits fluindo pelo pipeline.

Taxa de falha de mudanças foi em ambas as direções. Times com processos de review fortes e cobertura de testes mantiveram suas taxas de falha estáveis enquanto shipavam mais. Times que shipam código gerado por IA sem review adequado viram as taxas de falha aumentarem. O modelo DORA não se importa como o código é escrito. Mede o que acontece depois que o código shippa para produção.

O State of DevOps Report 2024 do DORA encontrou que 41% dos times pesquisados relataram usar ferramentas de desenvolvimento assistidas por IA. Esses times mostraram frequência de deployment mais alta sem um aumento proporcional em taxa de falha de mudanças quando a adoção de IA foi pareada com testes automatizados e pipelines de review.

Aqui é onde coinca na prática: IA acelera a frente do pipeline significativamente. DORA te diz se essa aceleração está sendo absorvida de forma limpa ou criando instabilidade downstream.

Ferramentas para rastrear métricas DORA sem overbuildar sua stack

A maioria dos times começam a medir métricas DORA puxando dados de ferramentas que já usam: GitHub ou GitLab para eventos de deployment e timestamps de commit, PagerDuty ou OpsGenie para dados de tempo de recuperação, e o sistema de gerenciamento de incidentes para contagens de taxa de falha de mudanças.

Várias plataformas construíram dashboards de DORA especificamente ao redor dessas quatro métricas.

Para um builder solo sem orçamento de tooling: um script que registra o timestamp de cada deployment de produção e cada evento de recuperação te dá frequência de deployment e tempo de recuperação com zero custo de infraestrutura. Lead time pode ser aproximado dos timestamps de commit no Git log.

Onde as métricas DORA têm limites reais

Medir DORA é útil. Tratar como a imagem completa da performance de engenharia cria vários pontos cegos específicos que merecem ser nomeados.

Acúmulo de débito técnico. Alta frequência de deployment com baixa taxa de falha de mudanças não te diz nada sobre se o codebase está ficando mais difícil de trabalhar ao longo do tempo. Um time pode atingir números DORA elite enquanto steadily acumula o tipo de débito que torna cada novo feature mais lento para shippar. DORA mede output de delivery; não mede o estado do que você está deliverando.

Alinhamento de outcomes. Frequência de deployment mede output, não outcomes. Shippar cinco vezes por dia não importa se nenhuma dessas mudanças move uma métrica que o produto ou o negócio se importa. Feature flags, infraestrutura de A/B testing e business metrics tracking ficam completamente fora do modelo DORA.

Sustentabilidade. O time de pesquisa DORA adicionou uma dimensão de experiência do desenvolvedor ao framework em 2023, reconhecendo que performance alta sustentável requer engenheiros que não estão rodando em burnout. As quatro métricas principais não rastreiam se atingir números elite está vindo a um custo em outro lugar.

Use DORA como uma ferramenta de diagnóstico baseline, não um scoreboard. As perguntas que as métricas levantam são frequentemente mais acionáveis que os números eles mesmos. Uma taxa de falha de mudanças de 30% é menos útil que saber quais tipos de mudanças falham mais frequentemente e por quê.

Por onde começar se você nunca rastreou isso

Um side project de seis meses sem dados de DORA é normal. A maioria dos times pequenos e builders solo nunca mediram nada disso.

Se você está começando do zero, pegue frequência de deployment e lead time primeiro. Ambos são fáceis de extrair dos timestamps de commit Git e deployment logs, e eles te dão feedback imediato sobre se seu pipeline tem friction desnecessária. Um lead time de três dias para uma mudança que leva quarenta minutos para escrever é um sinal que vale a pena investigar.

Taxa de falha de mudanças e tempo para restaurar requerem incidentes acumularem antes dos números significarem algo. Quando algo quebra em produção, registre o timestamp em que foi detectado e o timestamp em que foi resolvido. Esse dado compõe ao longo do tempo.

Um hábito prático: depois de qualquer incidente de produção, faça duas perguntas. Quanto tempo levou para detectar esse problema? Quanto tempo da detecção até resolução? Esses dois números são os inputs para tempo de restauro. Rastreá-los consistentemente por seis meses te dá história o bastante para saber se seu processo de recuperação está melhorando ou ficando flat.

Três razões para medir métricas DORA mesmo como dev solo, uma razão para não se importar: as métricas tornam friction invisível visível, elas criam accountability para investimentos de automação, e elas te dão algo concreto para melhorar entre trabalho de feature. A razão para não se importar: se você é pré-launch sem usuários de produção, os números não significam muito ainda. Comece a medir quando você estiver shippando para usuários reais regularmente.

Não é uma ideia perfeita. É uma ideia realizável.