DORA Metrics: o que são, como medir e como melhorar na engenharia.

Com IA no desenvolvimento, gerar código ficou mais fácil. O problema é que mais código não significa, automaticamente, melhor entrega. O time pode abrir mais PRs, sobrecarregar o review, rodar mais pipelines e ainda assim demorar mais para colocar mudanças boas em produção. É nesse ponto que as DORA Metrics ajudam: elas mostram como o fluxo de entrega está funcionando de verdade

O erro mais comum é usar DORA como se fosse um painel de produtividade. Só que DORA ajuda mais quando responde outras perguntas: onde o trabalho está travando, onde a qualidade está falhando e quanto tempo o time leva para se recuperar quando algo quebra.

As métricas DORA nasceram da pesquisa do DevOps Research and Assessment, hoje parte do Google Cloud. Elas ficaram conhecidas pelas quatro métricas clássicas: Lead Time for Changes, Deployment Frequency, Change Failure Rate e MTTR. Mais recentemente, a própria DORA passou a descrever um modelo com cinco métricas, incluindo Deployment Rework Rate e usando Failed Deployment Recovery Time para uma leitura mais precisa da recuperação após deploys com falha.

Na prática, quando alguém fala em “DORA Metrics”, geralmente está falando das quatro métricas clássicas. Elas são um bom ponto de partida, desde que não sejam lidas de forma isolada. O mesmo número pode significar coisas bem diferentes dependendo do serviço, do time e do tipo de produto que está sendo entregue.

O que são DORA Metrics?

DORA Metrics são métricas usadas para medir a performance do fluxo de entrega de software. Elas ajudam times de engenharia a entender se conseguem entregar mudanças com frequência, com pouco atraso, com baixa taxa de falhas e com boa capacidade de recuperação.

Elas ajudam mais do que métricas de atividade, como número de commits, linhas de código ou pull requests abertos. Esses números mostram que algo está acontecendo, mas não mostram se a entrega melhorou. Um time pode parecer ocupado e ainda assim entregar pouco valor, fazer deploys frágeis ou acumular risco no caminho.

Um time pode fazer muitos commits pequenos e continuar demorando semanas para colocar mudanças em produção. Também pode abrir muitos PRs e criar uma fila de review que trava todo mundo. DORA força a conversa a sair do volume de trabalho e ir para o resultado do sistema de entrega.

Quais são as quatro métricas DORA?

As quatro métricas DORA mais usadas medem dois lados do mesmo fluxo: velocidade e estabilidade. A velocidade aparece em Deployment Frequency e Lead Time for Changes. A estabilidade aparece em Change Failure Rate e MTTR, ou, no modelo mais recente, Failed Deployment Recovery Time.

Métrica	O que mede	Por que importa	Onde investigar quando piora
Deployment Frequency	Quantas vezes o time faz deploy em produção em um período	Mostra se o time consegue entregar em lotes pequenos e frequentes	Pipeline, aprovações, medo de deploy, PRs grandes, dependência entre times
Lead Time for Changes	Tempo entre o commit de uma mudança e o deploy em produção	Mostra quanto tempo uma mudança leva para chegar ao usuário	Tempo até abrir PR, tempo em review, CI lento, QA manual, espera por deploy
Change Failure Rate	Percentual de deploys que causam incidente, rollback, hotfix ou intervenção	Mostra se a entrega frequente está mantendo qualidade suficiente	Testes frágeis, review superficial, PRs grandes, baixa observabilidade
MTTR ou Failed Deployment Recovery Time	Tempo médio para recuperar o serviço depois de uma falha	Mostra a capacidade do time de responder quando produção quebra	Alertas, rollback, playbooks, ownership, diagnóstico e logs

Deployment Frequency: como medir a frequência de deploy

Deployment Frequency mede quantas vezes um time coloca mudanças em produção durante um período. Pode ser por dia, semana, mês ou sprint, desde que o critério seja consistente.

A forma simples de calcular é:

Deployment Frequency = número de deploys em produção / período analisado

Se um serviço teve 20 deploys em 10 dias úteis, a frequência média foi de 2 deploys por dia útil. Em um time com deploy contínuo, talvez faça mais sentido olhar para a mediana diária ou semanal, porque a média pode esconder dias sem deploy e dias com vários deploys concentrados.

Como interpretar essa DORA Metric

Deploy frequente geralmente indica que o time consegue trabalhar em mudanças menores, revisar com menos atrito e colocar código em produção sem acumular tanto risco. Quando o deploy acontece raramente, o problema costuma estar no fluxo: PRs grandes demais, muitas aprovações manuais, pipeline instável ou receio de quebrar produção.

Essa leitura precisa ser feita por serviço. Um backend interno com deploy controlado não tem o mesmo ritmo de um SaaS com release contínuo. O problema não é simplesmente deployar pouco. O problema é ter mudanças prontas e ainda assim esperar dias ou semanas para colocá-las em produção.

Quando a frequência de deploy cai, algumas perguntas ajudam a encontrar o gargalo:

• Mudanças já aprovadas ficam paradas depois do merge?
• O time depende de uma janela fixa de release?
• O pipeline falha com frequência por motivos não relacionados à mudança?
• Existe muita dependência entre times para liberar uma alteração pequena?
• Os PRs ficam grandes demais para serem revisados com segurança?

Lead Time for Changes: como medir o tempo até produção

Lead Time for Changes mede o tempo entre o primeiro commit de uma mudança e o momento em que ela chega em produção. Essa é uma das métricas mais úteis para liderança técnica, porque mostra o tempo real que uma alteração leva para passar pelo sistema.

A forma básica é:

Lead Time for Changes = timestamp do deploy em produção – timestamp do primeiro commit

Exemplo:

• Primeiro commit: 1 de janeiro, às 10h
• Deploy em produção: 5 de janeiro, às 16h
• Lead Time: 4 dias e 6 horas

Essa conta parece simples, mas a definição precisa ser combinada antes. Alguns times medem a partir do primeiro commit. Outros medem a partir da abertura do pull request. Para comparar ao longo do tempo, escolha uma definição e mantenha a mesma lógica.

DORA Metrics ficam mais úteis quando você quebra o lead time

O número agregado mostra que existe atraso, mas não mostra onde ele acontece. Para encontrar o gargalo, quebre o lead time em etapas menores:

• Tempo entre primeiro commit e abertura do PR
• Tempo até o primeiro review
• Tempo entre primeiro review e aprovação
• Tempo entre aprovação e merge
• Tempo entre merge e deploy

Essa quebra muda a conversa. Se o tempo maior está antes da abertura do PR, talvez as tarefas estejam grandes demais. No review, o atraso pode indicar falta de contexto, poucos reviewers disponíveis ou PRs difíceis de revisar. Depois do merge, o gargalo pode estar no pipeline ou no processo de release.

Para times usando IA para gerar código, essa métrica merece ainda mais atenção. A IA pode reduzir o tempo de escrita, mas aumentar o tempo de revisão se o código chega maior, com menos contexto ou com mudanças espalhadas por arquivos demais. Nesse caso, o lead time não melhora porque o gargalo saiu da escrita e foi para o review.

Change Failure Rate: como calcular a taxa de falha nas mudanças

Change Failure Rate mede a proporção de deploys que causam algum problema em produção. Pode ser rollback, hotfix, incidente, degradação relevante ou qualquer mudança que exija intervenção imediata.

A fórmula é:

Change Failure Rate = deploys com falha / total de deploys x 100

Exemplo:

• Deploys no mês: 40
• Deploys que exigiram rollback ou hotfix: 4
• Change Failure Rate: 10%

A parte difícil não é a conta. É definir o que conta como falha. Um bug pequeno corrigido depois entra na métrica? Um alerta falso entra? Um hotfix preventivo entra? O time precisa combinar a regra, senão cada pessoa vai classificar de um jeito.

O que essa métrica revela sobre code review

Quando a taxa de falha sobe, normalmente existe algum problema antes da produção. Pode ser teste automatizado insuficiente, requisito mal entendido, mudança grande demais ou review feito só para aprovar sintaxe.

Code review entra nessa parte porque muitas falhas não aparecem como erro óbvio no diff. O código pode compilar, os testes podem passar e, ainda assim, a mudança pode quebrar uma regra de negócio, criar uma query pesada, alterar uma permissão sem querer ou mexer em um fluxo que o autor não conhecia bem.

Com assistentes de código, esse cuidado fica ainda mais importante. O código gerado pode parecer correto em uma leitura rápida, mas ainda precisa ser revisado dentro do contexto do produto. Review bom não é procurar apenas bug. É perguntar se aquela mudança faz sentido para aquele serviço, naquele fluxo e naquele risco.

MTTR e Failed Deployment Recovery Time: como medir recuperação

MTTR, ou Mean Time to Recovery, mede quanto tempo o time leva para restaurar o serviço depois de uma falha. Em muitos times, ele é calculado pela duração média dos incidentes.

A fórmula é:

MTTR = duração total dos incidentes / número de incidentes

Exemplo:

• Incidentes no mês: 3
• Duração total: 135 minutos
• MTTR: 45 minutos

A DORA passou a usar também o termo Failed Deployment Recovery Time, que foca no tempo de recuperação após um deploy que falhou e exigiu intervenção. Essa mudança ajuda a separar incidentes causados por deploy de outros tipos de falha operacional.

Para muitos times, essa distinção é útil. Se o serviço caiu por problema de infraestrutura externa, isso diz uma coisa. Se caiu porque um deploy quebrou o checkout, diz outra. As duas situações podem entrar em uma análise operacional, mas elas pedem ações diferentes.

O que olhar quando a recuperação demora

Um tempo de recuperação alto costuma aparecer quando o time demora para detectar, diagnosticar ou reverter. Cada etapa tem uma causa diferente.

• Quando a detecção demora, o time talvez não tenha alertas confiáveis ou esteja lidando com ruído demais.
• Se o diagnóstico demora, logs, traces e ownership provavelmente estão ruins.
• Se a reversão demora, o rollback pode depender de ação manual ou de alguém específico.
• Se o mesmo incidente volta, o postmortem não está gerando mudanças reais no sistema.

MTTR não melhora só cobrando o time para “resolver mais rápido”. A recuperação fica mais eficiente quando o sistema ajuda: deploys menores, feature flags, rollback simples, boa observabilidade e autonomia para agir quando algo quebra em produção.

Benchmarks das DORA Metrics

Benchmarks ajudam a ter uma referência, mas não devem virar ranking entre times. Um serviço legado com deploy regulado, um app novo e uma API interna operam sob restrições diferentes. Por isso, a comparação mais útil costuma ser do time com ele mesmo, olhando a evolução ao longo do tempo.

Como as classificações da DORA mudaram ao longo dos anos, use as faixas abaixo como referência, não como regra fixa.

Métrica	Faixa de atenção	Faixa saudável para muitos times	Como interpretar
Deployment Frequency	Menos de 1 deploy por mês	Semanal, diário ou várias vezes ao dia, dependendo do serviço	Pode indicar PRs grandes, pipeline instável ou excesso de aprovação manual.
Lead Time for Changes	Mais de 1 mês	Menos de 1 semana, ou menos de 1 dia em times com fluxo mais maduro	Quando sobe, quebre por etapa para descobrir se o atraso está no PR, no review, no CI ou no deploy
Change Failure Rate	Acima de 15% exige investigação	Entre 0% e 15%, com cuidado para não mascarar falhas	Com poucos deploys, pode esconder um processo conservador demais ou falhas não registradas.
MTTR ou Failed Deployment Recovery Time	Mais de 1 dia	Menos de 1 hora em serviços com boa operação	Depende da qualidade dos alertas, da facilidade de rollback, do diagnóstico e da autonomia do time responsável pelo serviço.

Um benchmark sozinho não diz muito. O mesmo lead time de três dias pode ser bom para um serviço complexo e ruim para uma API simples com mudanças pequenas. O contexto é o que transforma o número em diagnóstico.

Como criar um pipeline simples para medir DORA

Antes de comprar uma ferramenta ou montar um dashboard grande, o primeiro passo é definir como cada métrica será medida. A pior forma de implementar DORA é deixar cada time medir de um jeito e depois tratar os números como se fossem comparáveis.

Comece com uma tabela simples de definições:

Métrica	Evento inicial	Evento final	Fonte de dados
Lead Time for Changes	Primeiro commit ou abertura do PR	Deploy em produção	Git, GitHub, GitLab, ferramenta de CI/CD
Deployment Frequency	Deploy iniciado	Deploy concluído em produção	GitHub Actions, Jenkins, CircleCI, ArgoCD, ferramenta de release
Change Failure Rate	Deploy em produção	Incidente, rollback, hotfix ou intervenção ligada ao deploy	CI/CD, incident management, observabilidade, issue tracker
MTTR	Incidente detectado	Serviço restaurado	PagerDuty, Opsgenie, Datadog, New Relic, postmortems

Depois disso, automatize a coleta aos poucos. Não precisa começar perfeito. Muitas vezes um dashboard inicial com dados aproximados já revela onde o fluxo está travando.

Uma forma simples de começar:

• Escolha um serviço ou produto para medir primeiro.
• Defina os eventos que contam para cada métrica.
• Extraia dados das ferramentas que o time já usa.
• Valide manualmente uma amostra dos números.
• Revise os dados com o time a cada sprint ou mês.
• Escolha uma melhoria pequena com base no gargalo encontrado.

O cuidado principal é não transformar o dashboard no objetivo final. Se uma métrica não ajuda o time a tomar decisões, ela vira só mais um número na tela. Quando o time olha para o lead time e ainda não sabe o que investigar, provavelmente a métrica está agregada demais.

Como usar DORA sem cair em microgestão

DORA mede o sistema de entrega, não a produtividade individual. Usar essas métricas para cobrar devs por quantidade de deploys ou tempo entre commits cria incentivos ruins e deixa os dados menos confiáveis.

Um exemplo simples: quando o time passa a perseguir Deployment Frequency a qualquer custo, pode começar a fazer deploys pequenos que não entregam nada relevante. Quando a cobrança é reduzir Lead Time, pode empurrar mudanças com menos review. E quando o foco vira baixar Change Failure Rate acima de tudo, o time pode reduzir a frequência de deploy e ficar conservador demais.

O melhor uso é transformar cada número em uma pergunta:

• O lead time subiu nas últimas semanas. Em qual etapa ele subiu?
• A frequência de deploy caiu. Existe mudança pronta ficando parada?
• A taxa de falha aumentou. As falhas têm algo em comum?
• O tempo de recuperação piorou. Foi demora para detectar, diagnosticar ou reverter?

Essa diferença muda o comportamento do time. A métrica deixa de ser uma cobrança e passa a ser uma forma de escolher onde mexer no processo.

Como IA, pull requests e code review afetam DORA Metrics

Assistentes de código podem acelerar a escrita, mas não resolvem o fluxo inteiro de entrega. Depois que o código é gerado, ele ainda precisa passar por review, testes, integração e deploy. É aí que as DORA Metrics ajudam a mostrar se a velocidade extra virou entrega real ou só deslocou o gargalo para outra etapa.

Mais código não significa mais entrega

Em times sem um fluxo de review saudável, a IA pode aumentar o volume de PRs mais rápido do que o time consegue revisar. Isso aparece no lead time: PRs ficam parados, reviewers precisam lidar com mais contexto e mudanças pequenas começam a disputar atenção com mudanças grandes.

O efeito também aparece no Change Failure Rate. Quando o review vira uma checagem superficial, mais problemas chegam à produção. Não porque a “IA escreva código ruim” por padrão, mas porque mais mudanças entram no fluxo sem uma validação proporcional.

O que olhar além das métricas principais

Para entender o motivo por trás dos números, olhe também para:

• Tempo até o primeiro comentário no PR
• Tempo total em review
• Tamanho médio dos PRs
• Quantidade de arquivos alterados por PR
• Taxa de PRs reabertos ou revertidos
• Tipos de problema encontrados em review

É aqui que o code review assistido por IA pode ajudar, desde que seja usado com critério. desde que entre como apoio ao fluxo. O valor não está em aprovar qualquer mudança mais rápido, mas em reduzir espera, trazer contexto, apontar riscos recorrentes e deixar o reviewer focar nas decisões que exigem julgamento.

Se o time usa uma ferramenta como a Kodus, por exemplo, o time pode acompanhar sinais que explicam o comportamento das DORA Metrics: se o primeiro feedback chega mais rápido, se problemas repetidos aparecem menos em produção e se PRs grandes recebem alertas antes de virarem gargalo. Esses sinais não substituem DORA, mas ajudam a entender por que os números melhoram ou pioram.

Erros comuns ao implementar DORA Metrics

Medir sem uma linha de base

Sem ponto de partida, qualquer mudança parece uma opinião. Meça algumas semanas antes de mexer no processo. Mesmo que os dados não estejam perfeitos, eles ajudam o time a comparar tendência.

Comparar times diferentes como se fossem iguais

Um time cuidando de um sistema legado regulado não deve ser comparado diretamente com um time trabalhando em um serviço novo e isolado. A DORA funciona melhor por aplicação ou serviço, com contexto claro.

Otimizar uma métrica isolada

Aumentar deploy sem olhar para falhas pode piorar produção. Reduzir lead time sem olhar para review pode empurrar risco para frente. As métricas foram feitas para serem lidas juntas.

Usar métricas para pressionar pessoas

Quando a métrica vira cobrança individual, o time começa a otimizar o número, não o sistema. Aí aparecem distorções: deploys artificiais, incidentes mal classificados, PRs quebrados em pedaços sem necessidade e trabalho escondido fora do fluxo medido.

Montar um dashboard grande antes de saber a pergunta

Dashboard com muitas métricas costuma dar uma sensação falsa de controle. Comece com uma pergunta simples, como “por que nosso lead time subiu?” ou “por que os deploys estão falhando mais?”. Depois busque os dados necessários para responder.

Outras métricas que complementam DORA

DORA mostra o resultado do fluxo de entrega, mas nem sempre explica a causa. Por isso, alguns times combinam DORA com métricas de fluxo, code review e experiência de desenvolvimento.

Algumas métricas úteis:

• Cycle time: tempo entre o início ativo do trabalho e a entrega.
• Review time: tempo que um PR passa esperando ou recebendo revisão.
• PR size: tamanho médio dos pull requests, em arquivos, linhas ou escopo funcional.
• Queue time: tempo parado entre etapas, como espera por review, QA ou deploy.
• Rework: quanto trabalho volta por bug, requisito mal entendido ou mudança incompleta.
• Developer experience: sinais de atrito no ambiente, no CI, no setup local e nas ferramentas internas.

Essas métricas devem explicar DORA, não competir com ela. Se o lead time está alto, review time e queue time ajudam a encontrar onde o fluxo travou. Se a taxa de falha subiu, rework e tipos de comentário em review ajudam a entender o que está escapando.

Como começar sem tornar o processo pesado

Um jeito simples de começar é escolher um serviço e uma pergunta. Por exemplo: “por que mudanças pequenas estão demorando tanto para chegar em produção?”. A partir daí, meça Lead Time for Changes e quebre o tempo em etapas.

Depois de duas ou três semanas, olhe para os dados com o time. Se o maior atraso está no review, trabalhe no tamanho dos PRs, na distribuição de reviewers e no tipo de feedback que chega tarde demais. Se o atraso está depois do merge, olhe para CI, deploy e aprovações.

Para Change Failure Rate, comece registrando deploys que exigiram rollback, hotfix ou incidente. Não precisa resolver toda a taxonomia de falhas no começo. O importante é criar uma regra que o time consiga aplicar sempre.

Para MTTR, escolha uma definição simples de início e fim do incidente. Depois, separe o tempo de detecção, diagnóstico e recuperação. Essa separação evita uma discussão genérica sobre “demoramos muito” e leva o time para ações mais claras.

FAQ sobre DORA Metrics

O que são DORA Metrics?

DORA Metrics são métricas de entrega de software usadas para medir velocidade e estabilidade. As quatro mais conhecidas são Deployment Frequency, Lead Time for Changes, Change Failure Rate e MTTR. O modelo atual da DORA também considera Deployment Rework Rate e Failed Deployment Recovery Time.

Quais são as 4 métricas DORA?

As quatro métricas DORA clássicas são Deployment Frequency, Lead Time for Changes, Change Failure Rate e Mean Time to Recovery. Elas ajudam a entender a frequência de deploy, tempo até produção, taxa de falhas e capacidade de recuperação.

Qual é a diferença entre Lead Time e Cycle Time?

Lead Time for Changes costuma medir do commit até o deploy em produção. Cycle Time pode medir o tempo desde o início ativo do trabalho até a entrega. A diferença exata depende da definição do time, por isso é importante documentar os eventos usados em cada cálculo.

Qual é uma boa frequência de deploy?

Depende do contexto. Para muitos times, deploy diário ou várias vezes ao dia pode ser um sinal saudável. Em produtos com mais restrições, uma frequência semanal pode fazer sentido. O alerta aparece quando mudanças prontas ficam paradas sem um motivo técnico claro.

Change Failure Rate abaixo de 15% é bom?

Em muitos benchmarks, abaixo de 15% aparece como uma faixa saudável. Ainda assim, o número precisa de contexto. Uma taxa muito baixa com poucos deploys pode indicar que o time evita mudanças. Também pode indicar que falhas não estão sendo registradas corretamente.

DORA Metrics servem para times pequenos?

Sim, mas a leitura precisa considerar o tamanho do time. Quando há poucos deploys ou poucos incidentes, a média pode oscilar bastante. Por isso, vale olhar mais para tendências e gargalos do fluxo do que para comparação rígida com benchmarks.

Como code review afeta DORA Metrics?

Code review afeta principalmente o Lead Time for Changes e o Change Failure Rate. Quando o review demora, a mudança leva mais tempo para chegar em produção. Quando o review é superficial, problemas podem escapar e aparecer depois como incidente, rollback ou hotfix.

Devo usar DORA Metrics para avaliar desenvolvedores?

Não. DORA mede o sistema de entrega. Usar essas métricas para avaliar pessoas cria incentivo ruim e reduz a confiança nos dados. Elas funcionam melhor quando o time usa os números para melhorar processo, tooling, arquitetura e qualidade de entrega.

Fechando

DORA Metrics ajudam quando viram uma conversa sobre o fluxo real de entrega. Elas mostram se o time está entregando com frequência, quanto tempo uma mudança leva para chegar em produção, quantas mudanças falham e quanto tempo a recuperação demora.

Esses números ajudam quando levam o time a investigar causas concretas: PRs grandes, review lento, CI instável, testes fracos, deploy manual, pouca observabilidade ou rollback difícil. Para times usando IA no desenvolvimento, essa leitura fica ainda mais necessária, porque produzir código mais rápido não garante entrega melhor.

Comece pequeno. Escolha um serviço, combine as definições, valide os dados e ataque um gargalo por vez. DORA Metrics não precisa virar um painel enorme. Precisa ajudar o time a entender onde o trabalho trava e o que mudar primeiro.