Como reduzir MTTR: 7 práticas que funcionam de verdade
MTTR é o segundo número mais importante em SRE depois do uptime. Veja 7 práticas concretas pra reduzir tempo médio de recuperação de incidents — da detecção ao runbook.
Por que MTTR importa mais que MTBF
Todo mundo persegue 99.99% uptime — o número bonito que vai no contrato. Mas quando você quebra esse número em duas variáveis, o que dá pra controlar de verdade é o MTTR (Mean Time To Recovery), não o MTBF (Mean Time Between Failures).
1. Alerta na pessoa, não no canal
Email pra "ops@empresa.com" é a forma mais comum — e a pior. Email é assíncrono, sem urgência, e ninguém olha em domingo às 3h da manhã.
2. Acknowledge separado de resolução
Erro clássico: incident continua disparando alerta enquanto o oncall já está trabalhando nele. Resultado: spam + plantonista irritado + escalação errada.
3. Runbook por tipo de alerta
Não escreva runbook genérico. Escreva um por alerta. "API /checkout retornou 5xx" tem runbook diferente de "Postgres latência > 500ms".
4. Correlação automática com deploys
A maioria dos incidents é causada por deploy recente. Se seu alerta menciona "deploy X de Y minutos atrás", o oncall já sabe onde olhar.