Seu MTTR Vai Melhorar Este Ano, Tenha Você Melhorado em Incidentes ou Não

Tempo médio de resolução é uma média, e uma média é uma afirmação sobre uma população. Mude quais incidentes caem nessa população e o número se move sem que ninguém tenha melhorado em nada.

É isso que os respondentes de incidente baseados em IA estão fazendo com o MTTR agora. Eles absorvem o alerta de disco cheio, o certificado expirado, o rollback cujo culpado é o último deploy. Esses sempre foram o grosso da contagem e a base da distribuição de dificuldade. Tire-os da fila humana, feche-os sem humano no circuito, e a média cai. A capacidade da organização de sobreviver a uma falha genuinamente inédita permanece intocada por essa aritmética. O painel vai sugerir o contrário, e vai fazer isso em verde.

A Previsão, e Quem a Faz

Sylvain Kalache, que lidera AI Labs e relações com desenvolvedores na Rootly, enuncia a divisão de forma direta: “o MTTR médio da maioria dos incidentes vai cair…mas…o tempo de resolução vai disparar para incidentes complexos.”

Duas observações sobre essa frase antes de construir em cima dela. Primeira: a Rootly vende simulação de incidentes, que é justamente o remédio que o artigo do Kalache recomenda. Segunda: a previsão é dele e não foi medida. Ninguém publicou a série segmentada que confirmaria ou mataria a hipótese.

Então a previsão é uma hipótese. O que a torna digna do tempo do leitor é que o mecanismo por baixo dela tem quatro décadas, está bem documentado e pode ser verificado de forma independente.

A Versão de 1983 Desse Argumento

Lisanne Bainbridge, pesquisadora de fatores humanos, escreveu Ironies of Automation em 1983. A frase em que Kalache se ancora é o argumento inteiro em uma oração: a automação “reduz as oportunidades dos operadores de praticar o trabalho de rotina, enquanto os mantém responsáveis por situações novas e anormais.”

Leia as duas metades como um balanço. De um lado, repetições removidas. Do outro, responsabilidade mantida. O trabalho rotineiro que a automação leva embora é também o trabalho que constrói o modelo mental que um engenheiro usa quando algo sem precedente quebra. Ninguém aprende como um sistema distribuído se comporta sob estresse lendo o diagrama de arquitetura. Aprende sendo acordado às 3 da manhã por uma longa série de falhas chatas e majoritariamente resolvíveis, formando devagar a intuição sobre qual subsistema mente para você.

A formulação de Kalache para a consequência merece ficar fixada acima do canal de incidentes: “quanto mais bem-sucedida ela se torna, menos preparados os humanos podem estar para o momento em que ela falha.”

Repare na ressalva nas palavras dele. Podem estar. Ele não afirma ter medido a degradação. Eu também não.

A Aviação Já Precificou Essa Troca

A comparação que Kalache busca é a de motores a jato, e é a útil porque os números existem.

A aviação comercial moderna opera com menos de um desligamento de motor em voo a cada 100.000 horas de voo de motor. Essa confiabilidade é real, foi conquistada, e é a razão de ninguém pensar duas vezes antes de embarcar. Também significa que um piloto em atividade pode passar a carreira inteira sem enfrentar a falha que está certificado para enfrentar.

Quando a falha chega, o relógio é curto. O voo 235 da TransAsia Airways caiu 117 segundos depois do primeiro alerta. O que quer que a tripulação fosse trazer para aquele problema, já tinha trazido antes do primeiro alerta disparar. Não havia tempo para adquirir.

A resposta da aviação a essa aritmética é uma cadência obrigatória: as regras da FAA exigem que comandantes completem treinamento recorrente ou uma verificação de proficiência a cada seis meses. O que eu tiro dessa regra é o formato dela, não o raciocínio por trás: ela trata a prática como algo agendado de antemão, antes de qualquer decadência observada.

Não vou dizer que seis meses é o intervalo certo para resposta a incidentes em software. Esse número foi definido para outro domínio de falha, por gente com dados de acidentes que eu não tenho. O que transfere é o formato da política: a prática é agendada em cadência, é obrigatória, e é desacoplada de ter havido ou não uma quebra recente.

A Correção É Uma Divisão de Métrica

Reverter a resposta a incidentes com IA não está em discussão, e nem deveria. Ela funciona. A correção barata e imediata é parar de reportar um número só.

Segmente o MTTR em faixas antes que ele chegue a um painel. Um corte inicial que funciona:

• Incidentes fechados por automação, sem humano no circuito.
• Incidentes fechados por um humano com assistência de IA.
• Incidentes que exigiram diagnóstico humano, em que a IA contribuiu com contexto e não com a resolução.

Depois reporte cada série separadamente, e reporte a composição ao lado delas. A composição é a parte que vale reportar primeiro, porque é ela que move o agregado. Se a faixa rotineira cresce de minoria para clara maioria do volume de incidentes, o MTTR agregado cai só por isso, e a terceira faixa pode estar ficando mais lenta o tempo todo sem que o número do topo pisque.

Essa terceira série é a sua saúde operacional de verdade. É a de amostra pequena, variância alta e resultado constrangedor. É também a única que informa o que acontece no dia em que a automação for justamente a coisa que está errada.

Duas travas na divisão. Atribua a classe de complexidade no momento da resolução, e não no momento do acionamento, porque rótulos de severidade definidos durante o incidente codificam pânico mais do que dificuldade. E mantenha as faixas estáveis por pelo menos um ano, porque uma taxonomia redefinida a cada trimestre produz linhas de tendência sem significado.

O Mesmo Formato, em Outros Três Lugares

Um agregado que melhora enquanto sua cauda piora é uma falha geral de medição. Resposta a incidentes é apenas onde ela está mais visível hoje.

O preço do token é o irmão mais claro. O preço por token não é a unidade que carrega retentativas, reverificação e tentativas abandonadas, então ele pode cair sem que o custo de uma tarefa concluída caia junto. Discutimos a versão contábil disso em custo por tarefa concluída: a unidade que ficou mais barata é diferente da unidade que a empresa compra. O trabalho de supervisão que torna a saída da IA utilizável aparece no mesmo lugar, que é uma linha de custo que vale desenhar.

A terceira instância é uma bateria de testes verde. Percentual de cobertura é um agregado sobre asserções, e sobe alegremente enquanto as asserções que pegariam uma regressão real seguem não escritas. Mesma estrutura. Um número melhora porque a população fácil dele cresceu.

E quando a IA está verificando a IA na resposta a incidentes, o próprio circuito precisa de uma checagem, que é o argumento em o loop de reverificação. Aquilo é uma pergunta de mecanismo. Esta aqui é uma pergunta de medição, e a de medição sai mais barato resolver.

Faça Isso Agora

Abra seu rastreador de incidentes. Puxe os últimos dois trimestres. Marque cada incidente com uma das três faixas acima, na mão se for preciso, e plote o MTTR por faixa em vez do total. É um trabalho manual curto.

Você está procurando uma coisa: se a série de diagnóstico humano está estável, caindo ou subindo enquanto o agregado cai. Se estiver subindo, você tem um número para levar à próxima revisão operacional, e é um número que ninguém na sala tem hoje.

Se as três séries saírem indistinguíveis, você também aprendeu algo, e construiu o instrumento que vai precisar quando elas divergirem. E elas vão divergir, porque a composição vai continuar mudando esteja você medindo ou não.

---

Fontes

• Sylvain Kalache (AI Labs e DevRel na Rootly). “AI handles incidents, engineers lose touch with their systems.” Setembro de 2026.

A Victorino ajuda organizações de engenharia a instrumentar operações assistidas por IA para que as métricas reportadas à liderança sobrevivam ao contato com os incidentes que importam: contato@victorino.com.br | www.victorino.com.br