DORA Metrics: o que são, as 5 métricas e como implementar

Medir o desempenho de um time de engenharia de software é um dos problemas mais complexos da gestão de TI. Linhas de código escritas, número de commits, velocidade de sprint — todas essas métricas capturam atividade, não resultado. Elas dizem o quanto o time está ocupado, não o quanto está sendo eficaz.

As DORA Metrics surgiram para resolver exatamente esse problema. Desenvolvidas pelo programa DevOps Research and Assessment — hoje parte do Google Cloud — elas são o único conjunto de métricas validado por mais de uma década de pesquisa com dezenas de milhares de times ao redor do mundo. Elas medem o que realmente importa: velocidade e estabilidade de entrega de software.

Neste guia técnico atualizado com os dados do relatório 2024/2025, você vai entender o que são as DORA Metrics, como cada uma funciona, quais são os benchmarks de performance e como implementá-las na prática em times de DevOps e SRE.

O que são DORA Metrics?

DORA Metrics são um conjunto de indicadores de performance criado pelo programa DevOps Research and Assessment (DORA) para medir a eficácia de times de engenharia de software. Elas foram introduzidas em 2013 e popularizadas pelo livro “Accelerate”, de Nicole Forsgren, Jez Humble e Gene Kim, publicado em 2018.

A base do framework é simples: times de alto desempenho entregam software com mais frequência, com menos falhas e se recuperam de incidentes mais rapidamente. As DORA Metrics quantificam exatamente essas quatro dimensões, permitindo que times meçam onde estão e monitorem sua evolução ao longo do tempo.

A pesquisa por trás das métricas é incomum pelo volume e pelo rigor. O relatório Accelerate State of DevOps já coletou dados de mais de 39.000 profissionais ao redor do mundo. Isso confere uma base empírica raramente encontrada em frameworks de gestão de TI.

As 5 DORA Metrics (framework atualizado 2024)

O framework original tinha 4 métricas. Em 2024, o relatório DORA introduziu uma quinta métrica e reorganizou as dimensões. O framework atual agrupa as métricas em duas categorias: throughput (velocidade de entrega) e instabilidade (qualidade e confiabilidade).

1. Deployment Frequency (Frequência de Deploy)

Categoria: throughput

Mede com que frequência o time faz deploys em produção. É o indicador mais direto de agilidade: times que deployam com frequência têm ciclos de feedback menores, lotes de mudança menores e menor risco por deploy.

Os benchmarks do relatório DORA 2024 para Deployment Frequency são: times Elite deployam múltiplas vezes ao dia; times High deployam entre uma vez ao dia e uma vez por semana; times Medium deployam entre uma vez por semana e uma vez por mês; times Low deployam com menos de uma vez por mês.

O principal obstáculo para aumentar a frequência de deploy é a ausência de automação no pipeline de CI/CD. Times que dependem de processos manuais tendem a criar lotes grandes de mudança, o que aumenta o risco e reduz a frequência em um ciclo vicioso.

2. Lead Time for Changes (Tempo de Ciclo de Mudança)

Categoria: throughput

Mede o tempo desde o commit de código até o deploy em produção. Captura a eficiência de todo o pipeline de entrega: revisão de código, testes automatizados, aprovações e processo de deploy.

Os benchmarks são: Elite — menos de 1 hora; High — entre 1 dia e 1 semana; Medium — entre 1 semana e 1 mês; Low — mais de 1 mês.

Lead time alto geralmente indica gargalos estruturais: filas de revisão de código, testes manuais lentos, processos de aprovação burocrático ou dependências entre times que criam esperas. O value stream mapping é a ferramenta recomendada para identificar onde o tempo está sendo desperdiçado no pipeline.

3. Change Failure Rate (Taxa de Falha de Mudança)

Categoria: instabilidade

Mede a porcentagem de deploys que causam degradação em produção e exigem rollback, hotfix ou outro tipo de remediação. É o indicador de qualidade do processo de entrega.

Os benchmarks são: Elite — entre 0% e 5%; High — entre 5% e 10%; Medium/Low — entre 10% e 15%+.

Change Failure Rate alta geralmente indica ausência de testes automatizados de qualidade, deploys sem observabilidade adequada para detectar regressões rapidamente ou processos de revisão de código insuficientes. Times com alto CFR frequentemente compensam com Deploy Frequency baixa — o que é a resposta errada para o problema certo.

4. Failed Deployment Recovery Time (Tempo de Recuperação de Deploy Falho)

Categoria: throughput — renomeado e realocado em 2024

Anteriormente chamado de MTTR (Mean Time to Recover), essa métrica foi renomeada e movida da categoria de estabilidade para throughput no relatório 2024. Mede quanto tempo leva para restaurar o serviço após um incidente ou deploy problemático em produção.

Os benchmarks são: Elite — menos de 1 hora; High — menos de 1 dia; Medium — entre 1 dia e 1 semana; Low — mais de 1 semana.

O tempo de recuperação é diretamente impactado pela qualidade da observabilidade: times com rastreamento distribuído e correlação automática de alertas identificam a causa raiz em minutos, não em horas. A relação com os 4 sinais de ouro do SRE é direta — latência, tráfego, erros e saturação são os primeiros sinais de um deploy problemático.

5. Deployment Rework Rate — nova métrica de 2024

Categoria: instabilidade

Introduzida no relatório Accelerate State of DevOps 2024, a Rework Rate mede a proporção de deploys não planejados realizados para corrigir problemas visíveis ao usuário em produção. Ela captura o quanto do esforço de deploy do time é trabalho reativo em vez de entrega de valor.

A pesquisa DORA encontrou forte correlação entre Rework Rate e Change Failure Rate, sugerindo que as duas métricas juntas fornecem uma visão mais completa da qualidade do processo de entrega do que qualquer uma isolada. Times com alta Rework Rate estão gastando capacidade de engenharia em correções que poderiam ter sido evitadas com melhor qualidade no pipeline.

Os benchmarks de performance em 2024

O relatório DORA 2024 — o décimo da série, com dados de mais de 39.000 profissionais — introduziu uma mudança significativa na forma de classificar times. Os quatro níveis de performance (Elite, High, Medium, Low) foram mantidos para as métricas individuais, mas o framework de comparação de times evoluiu para 7 arquétipos que combinam performance de entrega com fatores humanos como burnout, fricção e bem-estar da equipe.

Essa mudança reflete uma maturidade crescente na pesquisa: performance técnica sem saúde organizacional não sustenta resultados de longo prazo. Um time que deploya 50 vezes por dia mas opera com burnout crônico não é um time Elite sustentável.

Outro dado relevante do relatório 2025 — publicado como “State of AI-Assisted Software Development” — é que a adoção de IA em DevOps cresce rapidamente (de 42% em 2024 para 54% em 2025), mas os efeitos nas DORA Metrics são mistos: IA melhora throughput mas pode aumentar instabilidade quando adotada sem as bases técnicas corretas.

Como as DORA Metrics se relacionam com SLOs e observabilidade

As DORA Metrics e os SLOs (Service Level Objectives) são frameworks complementares que operam em camadas diferentes da confiabilidade de software.

As DORA Metrics medem a saúde do processo de entrega — o quanto o pipeline de desenvolvimento até produção é eficaz. Os SLOs medem a saúde do serviço em produção — o quanto o sistema está cumprindo os objetivos de confiabilidade prometidos ao negócio.

Um time pode ter DORA Metrics excelentes (deploys frequentes, lead time curto) mas SLOs violados se o sistema em produção é instável. E pode ter SLOs cumpridos mas DORA Metrics ruins se opera com deploys mensais cheios de risco.

A gestão de alertas e a análise de causa raiz estruturadas também impactam diretamente o Failed Deployment Recovery Time — um dos principais gargalos em times com MTTR alto é a falta de clareza sobre a causa raiz durante incidentes, não a falta de capacidade técnica para fazer rollback.

Como implementar DORA Metrics na prática

A implementação começa pela coleta de dados, não pela definição de metas. Muitos times cometem o erro de definir alvos aspiracionais antes de entender onde estão. O primeiro passo correto é estabelecer o baseline dos últimos 90 dias para cada métrica.

Passo 1: instrumentar o pipeline de CI/CD

Deployment Frequency e Lead Time for Changes precisam de dados do pipeline de entrega. Ferramentas como GitHub Actions, GitLab CI, Jenkins e Azure DevOps expõem esses dados via API ou integração nativa com plataformas de métricas DORA.

Passo 2: conectar dados de incidente

Change Failure Rate e Recovery Time exigem dados do sistema de gerenciamento de incidentes. A integração entre o pipeline de deploy e o sistema de incident management (PagerDuty, OpsGenie, ServiceNow) permite correlacionar automaticamente deploys com incidentes subsequentes.

Passo 3: definir a janela de tempo correta

DORA Metrics são métricas de tendência, não de estado pontual. O valor de uma semana não diz nada. O valor de 90 dias comparado ao trimestre anterior revela se o time está evoluindo. Configure dashboards com janelas deslizantes de 30 e 90 dias para acompanhar tendências.

Passo 4: evitar o uso punitivo das métricas

O erro mais frequente e mais danoso em implementações de DORA Metrics é usá-las para avaliar performance individual de engenheiros. A pesquisa DORA é explícita sobre isso: as métricas medem o sistema de entrega, não as pessoas. Times que as adotam de forma punitiva observam comportamentos de distorção (gaming) que invalidam os dados e destroem a confiança psicológica necessária para alta performance.

Conclusão

As DORA Metrics transformaram a forma como times de engenharia medem e comunicam performance. Elas oferecem uma linguagem comum entre engenharia e negócio — em vez de “estamos fazendo muitos deploys”, você pode dizer “nossa Deployment Frequency cresceu de semanal para diária no último trimestre, reduzindo o Lead Time em 68%”.

A implementação bem-sucedida começa pelo baseline honesto, avança com a integração de dados do pipeline e amadurece com o uso das métricas para identificar gargalos sistêmicos. A 5ª métrica, Rework Rate, introduzida em 2024, adiciona uma camada importante de visibilidade sobre o custo oculto do trabalho reativo.

O próximo passo natural após estabelecer DORA Metrics é conectá-las aos SLOs do serviço em produção, fechando o loop entre a saúde do processo de entrega e a saúde do sistema entregue. Para estruturar essa estratégia na sua organização, fale com nossos especialistas.