Métricas DORA Mudaram: Por Que Agora São Cinco?
Em 2024, a DORA adicionou formalmente deployment rework rate (taxa de retrabalho em deployments) ao seu conjunto estabelecido de métricas de desempenho da entrega de software, ampliando o modelo de quatro para cinco métricas. A nova métrica calcula a proporção de deployments não planejados realizados em resposta a um incidente em produção e, com isso, torna o trabalho reativo de entrega visível, em vez de deixar change fail rate (taxa de falha de mudanças) funcionar como uma aproximação desse retrabalho.
Ao separar esses sinais, o modelo se torna mais específico: líderes de engenharia podem diferenciar deployments que exigem intervenção imediata dos deployments adicionais que as equipes realizam para corrigir problemas em produção. Essa distinção importa ao avaliar o desempenho da entrega, comparar relatórios atuais com dashboards históricos ou decidir como atualizar as práticas de medição.
A DORA passou a usar cinco métricas principais em 2024
O modelo atual da DORA contém cinco métricas de desempenho da entrega de software distribuídas em duas dimensões: três descrevem throughput (ritmo de entrega), enquanto duas descrevem instabilidade.
| Dimensão atual | Métrica | O que ela responde |
|---|---|---|
| Throughput | Change lead time | Quanto tempo uma mudança leva para ir do commit à produção |
| Throughput | Deployment frequency | Com que frequência uma organização faz deployments em produção |
| Throughput | Failed deployment recovery time | Quanto tempo leva para se recuperar de um deployment com falha |
| Instabilidade | Change fail rate | A proporção de deployments que exigem intervenção imediata |
| Instabilidade | Deployment rework rate | A proporção de deployments que são respostas não planejadas a incidentes em produção |
Se você precisa relembrar o modelo histórico de quatro métricas, consulte nosso explainer anterior sobre métricas DORA. Ainda assim, a atualização importante é que deployment rework rate agora aparece como uma métrica de instabilidade separada, em vez de permanecer implícita em outra medição.
As cinco métricas DORA atuais
As cinco métricas devem ser lidas em conjunto porque cada uma descreve uma parte diferente do sistema de entrega de software. Deployment frequency e change lead time mostram o ritmo da entrega, e failed deployment recovery time (tempo de recuperação após falha de deployment) mostra a rapidez com que a organização se recupera quando um deployment causa uma falha. Change fail rate mostra com que frequência os deployments exigem intervenção imediata, e deployment rework rate mostra quanto da atividade de deployment é reativa e não planejada por causa de incidentes em produção.
Juntos, esses sinais impedem que um volume alto de deployments seja interpretado isoladamente como saudável, já que parte deles pode representar entrega planejada de produto enquanto outra parte pode ser trabalho corretivo que deslocou o plano. A quinta métrica oferece às equipes uma forma de separar esses dois tipos de atividade.
A terminologia de confiabilidade e recuperação mudou primeiro
O caminho de quatro para cinco não foi uma única atualização de nomenclatura. Em 2021, a DORA discutiu reliability, ou confiabilidade, como uma dimensão adicional e às vezes se referiu a ela como uma quinta métrica; no entanto, o próprio histórico da DORA descreveu posteriormente essa formulação como imprecisa porque reliability não se comportava como as quatro métricas de desempenho da entrega de software.
A terminologia de recuperação também mudou, pois, em 2023, a DORA refinou time to restore service para failed deployment recovery time, de modo que a medição se concentrasse nas indisponibilidades causadas por deployments de software. Em seguida, deployment rework rate se tornou uma quinta métrica de fato em 2024.
Como resultado, fontes atuais podem parecer inconsistentes mesmo quando cada uma reflete corretamente a versão disponível na época de sua publicação, porque uma fonte que diz “quatro métricas mais reliability” não está descrevendo a mesma estrutura do modelo atual de cinco métricas.
Por que a DORA adicionou deployment rework rate
A DORA adicionou deployment rework rate porque change fail rate vinha cumprindo duas funções: ela media a proporção de deployments que exigiam intervenção imediata enquanto também funcionava como uma aproximação do retrabalho criado pelas falhas. Ao introduzir uma métrica separada, a DORA pôde testar e medir esse retrabalho mais diretamente.
A distinção é importante na operação porque as métricas respondem a perguntas diferentes. Uma mudança com falha pergunta: esse deployment exigiu uma resposta imediata, como rollback, hotfix ou outra intervenção? O retrabalho pergunta: quanto da atividade posterior de deployment não foi planejada porque a equipe precisou tratar um incidente em produção?
Vamos considerar um período hipotético com 100 deployments: cinco exigem intervenção imediata, produzindo uma change fail rate de 5%, enquanto as equipes fazem oito deployments não planejados para tratar incidentes em produção, produzindo uma deployment rework rate de 8%. Esses números são ilustrativos, não benchmarks, e a diferença existe porque as duas métricas contam eventos distintos: o deployment que falhou e os deployments corretivos que vieram depois.
Já que cada taxa conta um evento diferente, um deployment com falha pode, em princípio, levar a mais de um deployment corretivo. Dependendo da janela de relatório, um deployment de retrabalho também pode ser contado em um período diferente daquele da falha original. Essas são inferências derivadas das definições das métricas, e não regras adicionais de classificação da DORA, e mostram por que tratar as taxas como equivalentes pode esconder uma diferença importante.
Como deployment rework rate é calculada
Deployment rework rate é a proporção de deployments não planejados feitos por causa de incidentes em produção em relação a todos os deployments realizados no mesmo período de medição; expressa em porcentagem, a conta é:
Deployment rework rate = (deployments não planejados feitos para tratar incidentes em produção / total de deployments) × 100
Usando o exemplo hipotético acima, oito deployments corretivos não planejados divididos por 100 deployments totais resultam em uma deployment rework rate de 8%.
O Quick Check da DORA apresenta a métrica como a porcentagem aproximada de deployments nos seis meses anteriores que não foram planejados e foram realizados para tratar um bug percebido pelo usuário. Essa formulação é útil para uma avaliação, mas uma equipe que está construindo um dashboard operacional precisa de um processo de classificação repetível.
No mínimo, estabeleça quatro regras:
- Defina o que conta como um deployment em produção e aplique esse denominador de forma consistente.
- Marque se cada deployment era planejado ou não planejado no momento em que ocorreu.
- Conecte um deployment não planejado ao incidente em produção ou defeito percebido pelo usuário que ele trata.
- Use a mesma janela de tempo para o numerador e o denominador.
O cálculo é bem simples, mas a classificação é a parte difícil: se as equipes classificarem deployments corretivos de formas diferentes, suas taxas não serão comparáveis. Por isso, evite inventar um atalho baseado em tempo, como tratar todo deployment feito dentro de um número fixo de horas após um incidente como retrabalho, a menos que a organização adote e documente essa regra explicitamente; a definição da DORA se concentra no motivo do deployment, e não em uma janela de tempo arbitrária.
Qual é a diferença entre change fail rate e deployment rework rate?
Change fail rate mede a proporção de deployments que exigem intervenção imediata, enquanto deployment rework rate mede a proporção de todos os deployments que não foram planejados e foram realizados por causa de um incidente em produção. Em outras palavras, a primeira começa com o deployment que causou um problema, enquanto a segunda começa com a atividade de deployment corretivo criada por problemas em produção.
| Pergunta | Change fail rate | Deployment rework rate |
|---|---|---|
| O que é contado no numerador? | Deployments que exigem intervenção imediata | Deployments não planejados feitos em resposta a incidentes em produção |
| Qual é o denominador? | Total de deployments no período de medição | Total de deployments no período de medição |
| O que ela revela? | Com que frequência mudanças implantadas precisam de uma resposta imediata | Quanto da atividade de deployment é trabalho corretivo reativo |
| No exemplo hipotético de 100 deployments | 5 deployments com falha = 5% | 8 deployments corretivos = 8% |
Nenhuma das métricas substitui a outra: uma equipe pode ter uma change fail rate relativamente baixa e ainda consumir uma parcela relevante da capacidade de deployment com retrabalho se as falhas levarem a várias versões corretivas, enquanto um deployment com falha resolvido por meio de rollback pode aumentar a change fail rate sem criar vários deployments de retrabalho posteriores.
Ler as duas em conjunto ajuda os líderes a fazer perguntas melhores. As falhas são frequentes? Quando uma falha acontece, ela cria uma sequência longa de entregas corretivas? O trabalho reativo está consumindo uma parcela crescente da atividade de deployment mesmo que a taxa de falha pareça estável? Esses são comportamentos diferentes do sistema e exigem investigações diferentes.
Por que referências a quatro métricas ainda são comuns
Uma razão para referências a quatro métricas continuarem visíveis é o timing. A quinta métrica foi adicionada em 2024, portanto conteúdos e ferramentas mais antigos ainda podem refletir a estrutura anterior. Mudanças na terminologia de reliability e recovery também contribuíram para múltiplas versões históricas do framework.
Resultados públicos de busca confirmam que a linguagem de quatro métricas continua visível; no entanto, eles não mostram quantas organizações ainda usam esse modelo nem se uma transição organizacional está em andamento.
Ao comparar um dashboard com uma fonte atual da DORA, verifique três pontos antes de presumir que um deles está errado:
- a data de publicação ou implementação;
- se reliability é apresentada como dimensão, resultado ou métrica;
- se a recuperação é chamada de time to restore service ou failed deployment recovery time.
Juntos, esses detalhes identificam qual versão do modelo uma fonte está usando e também evitam que dados históricos de tendência sejam reinterpretados silenciosamente com base em uma definição mais nova.
O que o modelo de cinco métricas muda para líderes de engenharia
A tarefa imediata não é descartar todo dashboard de quatro métricas, mas explicitar as definições e decidir como introduzir deployment rework rate sem comprometer a interpretação histórica.
Uma transição prática pode incluir os seguintes passos:
- Preserve a série histórica das quatro métricas e registre as definições usadas em cada período.
- Adicione deployment rework rate com uma regra documentada para classificar deployments corretivos não planejados.
- Renomeie ou anote métricas de recuperação se os dados históricos usavam a definição mais ampla de time to restore service.
- Analise throughput e instabilidade em conjunto, em vez de tratar o volume de deployments como um sinal isolado de sucesso.
- Atualize glossários internos, notas de dashboards e materiais de liderança para que os leitores saibam quando o modelo mudou.
Acima de tudo, use as métricas para diagnosticar o sistema de entrega, e não para ranquear desenvolvedores individualmente, porque uma deployment rework rate crescente é um ponto de partida para examinar padrões de incidentes, práticas de release, cobertura de testes, arquitetura ou feedback operacional, e não evidência de que uma pessoa específica esteja tendo desempenho insuficiente.
A DevStats oferece um relatório de métricas DORA para analisar sinais de entrega. Independentemente da ferramenta usada, o modelo atual de cinco métricas é mais útil quando cada métrica tem uma definição documentada, regras de coleta consistentes e contexto suficiente para apoiar uma decisão.