MTTR ainda é útil. Ele informa às equipes se a produção volta a um estado saudável com rapidez suficiente.
Mas não é mais o único relógio que importa.
Quando o fluxo de trabalho de correção pode conectar observabilidade, histórico de implantação, propriedade de código e patches gerados por IA, uma nova métrica se torna prática: tempo para PR revisado.
O que a métrica significa
O PR de tempo para revisão mede o caminho de um sinal de produção até uma solicitação pull que o proprietário do código pode avaliar seriamente.
Não é uma diferença gerada aleatoriamente. Não é um resumo vago do incidente. Um PR revisável.
Isso significa que a solicitação pull inclui:
- o sinal de produção que desencadeou a investigação
- o serviço, arquivo, função ou caminho de código suspeito
- a implantação recente ou conjunto de alterações que pode estar relacionado
- um patch focado
- os testes que foram executados ou deveriam ser executados
- as suposições e o nível de confiança
- o revisor ou proprietário certo
A métrica termina quando o PR está pronto para uma decisão de engenharia significativa.
Por que isso é diferente do MTTR
O MTTR é orientado para resultados. O PR time-to-reviewed é orientado para o fluxo de trabalho.
O MTTR pergunta: “Quando nos recuperamos?”
Time-to-reviewed-PR pergunta: “Com que rapidez chegamos a um ponto de decisão de alta qualidade?”
Essa distinção é importante porque muitos incidentes são adiados antes mesmo de a mudança de código existir. Os engenheiros ainda estão coletando evidências, encontrando propriedade, comparando implantações ou decidindo se o problema pertence a outro sistema.
Se a equipe conseguir encurtar essa fase, a recuperação muitas vezes melhora naturalmente. Mesmo quando a resposta final é reversão ou escalonamento, a decisão acontece com melhores evidências e menos confusão.
A barra de qualidade
A métrica só funciona se “RP revisado” significar algo estrito.
Uma versão ruim dessa métrica recompensaria ferramentas que abrem solicitações pull barulhentas rapidamente. Isso cria fadiga de revisão e faz com que os engenheiros desconfiem da automação.
Uma boa versão recompensa o trabalho preparado, com escopo definido e apoiado em evidências.
O PR deve ser pequeno o suficiente para ser revisado, claro o suficiente para ser rejeitado e conectado o suficiente para produzir evidências para que o revisor não precise reconstruir o incidente do zero.
Métricas complementares úteis
O PR revisado não deve ser independente. Combine-o com sinais de qualidade:
- Taxa de aceitação de relações públicas
- taxa de edição do revisor
- taxa de diagnóstico falso
- taxa de reversão após correções assistidas por IA
- taxa de incidente duplicada após mesclagem
- tempo desde a abertura do PR até a decisão do revisor
Juntas, essas métricas mostram se a automação está economizando tempo ou simplesmente transferindo o trabalho para revisão.
Onde isso ajuda os líderes
Os líderes de engenharia precisam saber se as ferramentas para incidentes reduzem o arrasto operacional. Um gráfico que diz que a recuperação é mais rápida é útil, mas não explica para onde foi o tempo.
O PR do tempo para revisão torna a transferência visível. Ele mostra se a equipe pode passar do alerta para a evidência, da evidência para o código e do código para a propriedade sem costura manual.
Também expõe elos fracos. Se os PRs abrem rapidamente, mas não são revisados, o problema é propriedade ou pessoal. Se a evidência demorar muito, o problema é a integração. Se muitos PRs forem rejeitados, o problema é a qualidade do diagnóstico.
A questão não são mais métricas
O objetivo não é inventar outro painel para os engenheiros ignorarem.
O objetivo é tornar observável a qualidade da remediação.
Bugs de produção não são resolvidos quando um alerta é acionado e não são resolvidos quando um modelo escreve código. Eles avançam em direção à resolução quando o ser humano certo pode tomar uma decisão confiante com as evidências certas à sua frente.
Isso é o que mede o PR na hora de revisar.
