Change failure rate

A maioria dos líderes de engenharia conhece a frequência de deploy do time. Poucos sabem qual porcentagem desses deploys está quebrando coisas silenciosamente. O change failure rate mede exatamente isso: a fatia dos deploys que resulta em degradação de serviço, incidente ou rollback. Quando esse número é invisível, o squad entrega cada vez mais rápido em direção à instabilidade, e o custo aparece como trabalho não planejado, burnout do plantão e perda de confiança dos stakeholders. Esta página cobre a definição, a fórmula, os benchmarks do DORA metrics, um exemplo real e passos concretos para reduzir o seu change failure rate.

Principais conclusões

• Change failure rate é a porcentagem de deploys em produção que resultam em degradação de serviço, incidente ou rollback. É uma das quatro DORA metrics e reflete diretamente a estabilidade do seu processo de entrega. Uma taxa alta sinaliza que o squad gasta tempo significativo em remediação não planejada em vez de entregar valor novo.
• A fórmula é: Change failure rate = (número de deploys com falha / total de deploys) × 100. Segundo o relatório DORA State of DevOps 2023, times de elite atingem um change failure rate de 5% ou menos, enquanto os de baixo desempenho veem taxas acima de 15%. Essa diferença se traduz diretamente em capacidade de engenharia perdida apagando incêndios.
• O erro mais comum dos times é confundir um change failure rate baixo com uma frequência de deploy baixa. Alguns squads reduzem os deploys para evitar falhas, o que mascara a causa raiz e desacelera a entrega sem melhorar a qualidade. O objetivo é deploys frequentes e estáveis, não menos deploys com a mesma fragilidade de base.
• O DevStats rastreia o change failure rate automaticamente conectando ao seu pipeline de CI/CD, ao provedor Git e às ferramentas de incidente, com benchmarks comparados a mais de 1.000 times de engenharia. Comece um teste gratuito e veja seus números em menos de dois minutos.

Definição de change failure rate

Change failure rate é a porcentagem de deploys de software que causam uma falha em produção, exigindo hotfix, rollback ou resposta a incidente. Ele mede a confiabilidade do seu processo de entrega, não a frequência dele.

Tecnicamente, o cálculo é: Change failure rate = (deploys com falha / total de deploys) × 100. Um deploy "com falha" inclui qualquer mudança que resulte em degradação de serviço, incidente P1/P2 ou rollback emergencial. Times que monitoram as quatro DORA metrics juntas têm a visão mais clara da saúde da entrega, já que o change failure rate é mais significativo quando lido junto com a frequência de deploy e o mean time to restore.

Do ponto de vista de negócio, cada deploy com falha é trabalho não planejado. Esse trabalho consome capacidade de engenharia orçada para features, comprime os compromissos futuros do sprint e corrói a reputação de confiabilidade do seu produto.

Por que o change failure rate importa para times de engenharia

Quando os squads não rastreiam o change failure rate, a instabilidade se normaliza. Os incidentes parecem azar aleatório em vez de um sinal de um processo mensurável. O trabalho de remediação não planejada se acumula sprint após sprint, e a acurácia do planejamento piora porque uma parcela significativa de cada sprint é consumida por incêndios que não estavam no board no início da semana.

Para líderes de engenharia, as consequências são concretas. Um change failure rate alto comprime o throughput efetivo do squad, aumenta a carga do plantão e cria um ciclo em que os players passam mais tempo consertando do que construindo. Isso também afeta diretamente a confiança dos stakeholders: incidentes repetidos em produção tornam mais difícil defender a velocidade do time para product e liderança executiva.

O change failure rate é uma das quatro DORA metrics, inserido no framework mais amplamente adotado para medir performance de entrega de software. Medir é o primeiro passo. O que você faz com esse dado, onde apertar os gates de code review, como estruturar o batching de deploy, quais partes do pipeline precisam de mais cobertura de testes, é decisão do líder de engenharia.

Como medir o change failure rate

Para calcular o change failure rate, você precisa de duas contagens em uma janela de tempo definida: o número de deploys que dispararam um incidente em produção ou exigiram rollback, e o total de deploys nessa mesma janela. Divida o primeiro pelo segundo e multiplique por 100. A maioria dos times define "falha" como qualquer deploy que resulte em incidente P1 ou P2, um deploy de hotfix em até 24 horas, ou um rollback iniciado pelo engenheiro de plantão.

As fontes de dados necessárias são o pipeline de CI/CD para registros de deploy, a ferramenta de gerenciamento de incidentes (PagerDuty, OpsGenie ou equivalente) para contagem de incidentes, e o provedor Git para correlacionar commits a deploys. Sem os três conectados, você provavelmente está subcontando as falhas. O recurso de deploy e os benchmarks do DevStats expõem esses dados automaticamente e comparam sua taxa com pares do setor.

Change failure rate na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que a velocidade de sprint do squad parecia saudável no papel, mas a rotação de plantão estava sendo massacrada semana sim, semana não. Ela puxou três meses de dados de deploy e incidentes e encontrou um change failure rate de 18%. As falhas se concentravam em um único serviço tocado por quatro players diferentes, sem ownership compartilhado e com cobertura mínima de testes automatizados. Esse padrão não era visível até a métrica ser calculada e mapeada para serviços específicos.

Ela tomou duas decisões: atribuiu um owner dedicado a esse serviço e adicionou uma etapa obrigatória de teste de integração no pipeline de deploy antes que qualquer mudança chegasse à produção. Após seis semanas, o change failure rate desse serviço caiu para 6%. Ela mediu o resultado rastreando tanto a taxa de incidentes no serviço quanto o percentual de trabalho não planejado nos sprints seguintes, o que liberou cerca de dois dias de capacidade do squad por semana para trabalho de feature planejado.

Como melhorar o change failure rate

1. Adicione testes de integração automatizados nos seus serviços de maior risco. Identifique quais serviços aparecem com mais frequência nos postmortems de incidentes. Para cada um, adicione testes de integração que rodem no pipeline de deploy antes de qualquer mudança chegar à produção. Isso captura regressões antes que virem incidentes.
2. Aperte os requisitos de code review para arquivos de alto churn. Revise seus dados de code review para encontrar os arquivos alterados com mais frequência e com menos cobertura de revisão. Exija pelo menos dois revisores para mudanças nesses arquivos. Alto churn com revisão superficial é um dos indicadores antecedentes mais fortes de falhas futuras.
3. Reduza o tamanho do batch de deploy. Batches grandes dificultam isolar qual mudança causou a falha. Deploys menores e mais frequentes tornam os rollbacks mais rápidos e a análise de causa raiz mais fácil. Se o squad está fazendo batching para reduzir risco, isso é um sinal de que o pipeline precisa de mais confiança, não de menos deploys.
4. Monitore o PR cycle time como indicador antecedente. Quando o PR cycle time dispara, as mudanças ficam mais tempo em revisão, acumulando conflitos de merge e combinações não testadas. Cycle times longos costumam preceder aumentos na taxa de falha em um a dois sprints.
5. Conduza postmortems sem culpa e aja sobre os achados sistêmicos. Cada postmortem de incidente deve produzir pelo menos uma mudança de processo, não apenas um fix para o bug imediato. O DevStats expõe os padrões de deploy e incidente que dão dados reais para os postmortems, mas o líder de engenharia decide quais mudanças sistêmicas priorizar.

Change failure rate vs. mean time to restore

Change failure rate e mean time to restore (MTTR) são ambas métricas de estabilidade do DORA metrics, mas medem coisas diferentes: o change failure rate mede com que frequência os deploys causam falhas, enquanto o MTTR mede com que rapidez o squad se recupera quando elas ocorrem.

Use o change failure rate para diagnosticar seu processo de prevenção e o MTTR para diagnosticar seu processo de recuperação. Um squad pode ter um change failure rate baixo mas um MTTR alto, o que significa que as falhas são raras, mas dolorosas quando ocorrem.