70% dos incidentes vêm de mudanças? A origem do número mais repetido da TI

Toda apresentação de TI tem um slide com esse número. A frase varia pouco: 70 a 80 por cento dos incidentes vêm de mudanças. Inclusive, ela aparece em business case de CAB, em proposta comercial de ferramenta, em treinamento de ITIL e em post de blog. Quase ninguém pergunta de onde ela saiu.

O problema não é o número ser alto demais. Acontece que ele funde três afirmações diferentes, publicadas em décadas diferentes, sobre coisas diferentes. Ademais, duas delas sequer falam de incidentes.

Nesta página rastreamos a procedência de ponta a ponta. Você vai ver o que cada documento realmente disse e em que ponto a citação se deformou. Por fim, vai saber qual número ainda dá para usar em 2026 sem levar um contra-argumento na reunião.

A afirmação que ninguém confere

A versão em português costuma vir sem sobrenome. Um artigo brasileiro típico afirma que oitenta por cento dos incidentes de TI vêm de “mudanças na topologia da infraestrutura ou software”. Em seguida, atribui tudo a “um estudo”. Sem publicador, sem ano, sem link.

Essa ausência não é descuido isolado. Ou seja, ela é a regra: o número circula há mais de vinte anos justamente porque soa plausível para quem opera TI. Todo mundo já viu um deploy derrubar produção na sexta-feira.

Além disso, a afirmação é conveniente. Ela justifica orçamento de gestão de mudanças, comitê de aprovação, ferramenta de configuração e consultoria. Por isso, quem cita raramente tem incentivo para conferir.

Vale destacar o efeito colateral. Quando alguém do time de negócio finalmente pede a fonte, a resposta demora e a credibilidade da área inteira paga o preço.

A trilha das fontes: o que cada documento realmente diz

Existem quatro documentos por trás da frase. No entanto, nenhum deles diz exatamente o que a citação popular afirma. A tabela abaixo mostra a afirmação literal de cada um, o escopo real e o status da fonte hoje.

2001 e 2004: o alicerce que não fala de incidentes

A citação de 2001 é a mais repetida e a menos verificável. Ela aparece em dezenas de blogs, sempre com a mesma frase e nunca com o título do relatório. Isto é, ninguém consegue abrir o documento original.

Já o Visible Ops Handbook é rastreável. Na página oficial do método, o instituto afirma que quase 80% das paradas são autoinfligidas. Vale dizer, isso inclui erro de operação, procedimento mal executado e configuração manual, não só mudanças formais.

2010: a nota que virou fonte de tudo

A nota de pesquisa G00208328, assinada por Ronni J. Colville e George Spafford em outubro de 2010, é o documento mais próximo da frase popular. Ainda assim, ela diz outra coisa.

O texto original é uma previsão: até 2015, oitenta por cento das paradas em serviços de missão crítica viriam de pessoas e processos. Além disso, o mesmo texto restringe a fatia. Mais da metade dessas paradas viria de mudança, configuração e release.

Portanto, a parcela atribuída a mudanças fica acima de quarenta por cento das paradas. Ela nunca chegou aos 70 a 80 por cento que a citação popular anuncia.

2016: o único percentual que aguenta auditoria

Curiosamente, existe um “70%” perfeitamente rastreável. Ele está na introdução do manual de confiabilidade do Google, na seção sobre gestão de mudanças. O texto afirma que cerca de 70% das paradas vêm de mudanças em produção.

Esse dado tem escopo declarado. Ele vale para a infraestrutura do Google, medida por quem pratica Site Reliability Engineering em escala planetária. Portanto, não é uma média de mercado, muito menos uma média brasileira.

Onde a citação se deforma: três erros que viraram um número só

Comparar os quatro documentos revela um padrão. A frase popular não inventou nada do zero: ela empilhou fontes distintas e apagou as diferenças entre elas. São três erros encadeados.

Erro 1: troca de denominador. “Downtime não planejado” e “incidentes” não são a mesma métrica. Por exemplo, uma operação pode ter centenas de incidentes de baixo impacto e uma única parada relevante. Como resultado, o percentual muda por completo quando você troca horas de indisponibilidade por contagem de chamados.

Erro 2: a aritmética perdida. A nota de 2010 fala em oitenta por cento e, logo depois, restringe a mais da metade desses. Contudo, quem cita costuma ignorar o segundo filtro e promove o total inteiro para a conta de mudanças. O resultado correto seria algo acima de quarenta por cento.

Por fim, erro 3: previsão tratada como medição. O texto de 2010 projeta um cenário até 2015. É importante notar que ele nunca foi uma medição de campo. Em 2026, citá-lo como retrato atual ignora pipeline automatizado, infraestrutura como código e canary deployment, práticas que mudaram a natureza do risco de mudança.

Afinal, qual é o número certo?

Não existe um percentual universal de incidentes causados por mudanças. O dado verificável vem do livro de SRE do Google: cerca de 70% das paradas decorrem de mudanças em produção. A empresa mediu isso nos próprios sistemas, em 2016.

Fora desse escopo, o valor varia por operação. A única resposta defensável é medir a sua.

Em resumo, três frases resolvem a citação sem folclore. Primeiro: o Google mediu cerca de setenta por cento em ambiente próprio. Segundo: a Gartner projetou, até 2015, mais de quarenta por cento das paradas críticas ligadas a mudança, configuração e release. Terceiro: o seu número é o único que serve para decisão interna.

Nesse sentido, a distinção importa na hora de comparar benchmarks. Do mesmo modo, isso vale para tempo de resolução. Os benchmarks de MTTR e gestão de incidentes só fazem sentido quando você conhece a amostra, o ano e o método de cada valor.

O substituto medível: change failure rate

O change failure rate é a métrica que ocupa hoje o lugar do folclore. O programa DORA, mantido pelo Google Cloud, define a taxa de falha de mudanças. É a proporção de implantações que exigem intervenção imediata depois do deploy, em geral um rollback ou um hotfix. O denominador é claro: deploys.

Vale destacar a diferença de perguntas. A frase antiga responde “quanto do meu problema vem de mudança”. Em contrapartida, o change failure rate responde “quanto do que eu mudo dá errado”. As duas são úteis, mas medem coisas opostas.

Vale uma ressalva sobre edições. O relatório mais recente do programa saiu em 23 de setembro de 2025, com quase 5.000 respondentes.

Essa edição abandonou os grupos elite, alto, médio e baixo. Em vez deles, passou a trabalhar com sete perfis de time. Por isso, cite sempre a edição junto do número, como explicamos no guia sobre as métricas DORA.

Como medir a taxa real da sua operação

Medir dá menos trabalho do que parece. A conta básica é uma divisão: incidentes com causa “mudança” sobre o total de incidentes do período, sempre com a janela declarada. Isto é, taxa = incidentes_com_causa_mudanca / incidentes_totais.

Em síntese, o que sustenta essa conta é a disciplina de registro. Três controles bastam para o número parar de pé.

1. Campo de causa obrigatório no fechamento. Sem taxonomia fixa, cada analista escreve uma coisa. Portanto, use uma lista curta e fechada, com “mudança” como categoria explícita e separada de “falha de hardware” ou “capacidade”. O post mortem é o momento natural para revisar essa classificação.

2. Janela de correlação declarada. Defina em quanto tempo após uma mudança um incidente ainda conta como derivado dela. Por exemplo, muitas operações adotam 24 horas ou 72 horas. O valor importa menos que a consistência, desde que você publique a janela junto do resultado.

3. Correlação automática entre mudança e alerta. Outro ponto: aqui entra o monitoramento. Quando a plataforma marca o horário de cada deploy na mesma linha do tempo dos alertas, a análise de causa raiz ganha objetividade. Sem isso, o campo de causa vira chute retroativo.

Feito esse trio, a operação passa a produzir um dado próprio. Consequentemente, a discussão com a diretoria muda de tom. Em vez de citar uma nota de 2010, você mostra a sua série histórica dentro da gestão de incidentes de TI.

Por que isso importa para quem opera TI

Citar um número folclórico tem custo real. Antes de tudo, o custo é político: basta um interlocutor pedir a fonte para o business case inteiro perder força na frente do financeiro.

O segundo custo é de alocação. Ou seja, se você acredita que oitenta por cento dos problemas vêm de mudanças, investe quase tudo em comitê de aprovação. Entretanto, os dados abertos sugerem uma divisão mais equilibrada entre mudança, capacidade, dependência externa e erro de operação.

Existe ainda um efeito perverso. Processos de aprovação pesados empurram os times para mudanças informais, fora do fluxo oficial, que ninguém registra. Assim, a operação piora e o indicador melhora, porque a mudança problemática nem chega a virar registro.

Por fim, cabe ressaltar o ponto prático. Em suma, um comitê não detecta nada em tempo real. Quem detecta é o monitoramento correlacionando deploy, métrica e alerta na mesma janela.

Metodologia e como citar esta página

Esta página compila afirmações públicas sobre a relação entre mudanças e paradas de TI. Antes de tudo, consultamos cada fonte diretamente em 08/08/2026. Em seguida, registramos publicador, ano e escopo declarado ao lado de cada número.

Adotamos três critérios. Primeiro, só entram afirmações com publicador identificado. Segundo, previsões aparecem marcadas como previsão, com o prazo original. Terceiro, números sem documento recuperável ficam sinalizados como atribuição em circulação, nunca como dado.

Além disso, não reproduzimos gráficos nem tabelas de relatórios pagos. A nota Gartner G00208328 aparece apenas por descrição, com identificador e data, conforme a prática usual de citação de pesquisa licenciada.

Como citar esta página: OpServices. Incidentes causados por mudanças: a origem do número. opservices.com.br, 2026. Consulta em 08/08/2026.

Conclusão

O número que abre este artigo não é mentira nem verdade. Ele é uma colagem de quatro peças: uma frase de 2001 sobre downtime e um livro de 2004 sobre paradas autoinfligidas. A elas se somam uma previsão de 2010 com prazo até 2015 e uma medição de 2016 feita dentro do Google. Cada peça tem escopo próprio. A soma delas nunca apareceu em publicação alguma.

Para quem opera TI, a conclusão prática é simples. Portanto, pare de citar percentual de terceiro em decisão interna. Meça a sua taxa com campo de causa fechado, janela declarada e correlação automática entre mudança e alerta. Ao mesmo tempo, acompanhe o change failure rate, que tem denominador claro e definição pública.

Assim você troca uma frase de efeito por uma série histórica. Dessa forma, na próxima vez que alguém pedir a fonte, a resposta vem do seu próprio ambiente, com data e método.

Quer instrumentar essa correlação entre mudanças, alertas e incidentes na sua operação? Fale com um especialista da OpServices e veja como medir o seu número.