São 2h47 de uma terça-feira qualquer. O dashboard de error rate passa de 0,2% para 18% em quatro minutos, e os alertas do PagerDuty começam a se acumular. Ainda ninguém sabe qual deploy causou isso, mas alguém no canal de incidentes já escreveu a frase que define se o resto do mês vai ser produtivo ou não: "vamos ver quem mexeu em quê".
Essa frase é o momento exato em que a maioria das equipes estraga a resposta a um incidente. Não porque encontrar a mudança que quebrou tudo esteja errado, isso precisa ser feito rápido, mas porque encarar isso como uma caça às bruxas muda o comportamento das pessoas durante a crise. Um engenheiro com medo de admitir "eu fiz esse deploy há vinte minutos" demora mais para falar, e esses vinte minutos de silêncio são o que separa um incidente de quinze minutos de um de duas horas.
O que fazer nos primeiros minutos
A primeira decisão não é encontrar a causa raiz, é conter o dano. Rollback se a mudança for recente e reversível, desligar a feature flag se o código novo estiver atrás de uma, redirecionar tráfego para uma região saudável se o problema for de infraestrutura. A causa raiz você investiga depois, com o sistema estável. Misturar diagnóstico com mitigação é o erro mais comum em incidentes que se arrastam: a gente fica lendo logs em vez de apertar o botão que estanca a hemorragia.
Um exemplo real desse tipo de problema: uma migração de banco de dados que adiciona um índice sem usar CONCURRENTLY no Postgres. Localmente roda em 200 milissegundos porque a tabela de teste tem 40 linhas. Em produção, com 80 milhões de linhas, a migração trava a tabela com um lock exclusivo por 40 minutos e derruba toda request que precisa escrever ali. Ninguém mexeu em código de negócio, o bug não está em nenhum pull request revisado com cuidado, está em um comando de infraestrutura que ninguém rodou contra um volume de dados realista.
Por que cultura blameless não é sinônimo de sem consequências
Blameless não significa que ninguém se responsabiliza por nada, significa que a análise foca no sistema que permitiu o erro, e não na pessoa que apertou o botão. Se um engenheiro conseguiu rodar essa migração sem CONCURRENTLY contra produção, a pergunta útil não é "por que ele foi tão descuidado", é "por que nosso pipeline de CI não bloqueou uma migração arriscada antes de chegar a esse ponto". A primeira pergunta termina numa conversa desconfortável com o RH. A segunda termina numa checagem automática que evita a próxima ocorrência do mesmo problema, não importa quem esteja de plantão naquele dia.
O postmortem que serve, não o que fica arquivado
Um postmortem útil tem quatro partes inegociáveis: uma linha do tempo com timestamps reais tirados de logs e métricas (não da memória, a memória durante um incidente de duas horas é péssima), o impacto medido em números concretos (usuários afetados, minutos de downtime, receita perdida se for o caso, não "foi grave"), a causa raiz técnica sem nomes próprios na narrativa, e uma lista de action items com dono e prazo, não uma lista de boas intenções.
A parte que mais fica de lado é o acompanhamento desses action items. É comum ver postmortems excelentes com cinco tarefas de acompanhamento, das quais três continuam abertas seis meses depois porque ninguém as priorizou frente ao roadmap de produto. Se o seu processo de incidentes não tem um mecanismo real para que esses itens disputem de verdade tempo de engenharia, o postmortem é teatro: documenta o problema mas não resolve, e o mesmo tipo de incidente volta a acontecer.
O que muda no sistema, não na pessoa
As equipes que reduzem a frequência de incidentes graves não fazem isso contratando gente mais cuidadosa, fazem isso adicionando camadas que tornam o erro individual menos custoso: canary deployments que expõem uma mudança a 5% do tráfego antes de chegar a 100%, feature flags que permitem desligar código novo sem um rollback completo, alertas baseados em SLOs com error budget em vez de limites arbitrários, e runbooks escritos para o incidente típico em vez de improvisar toda vez. Nenhuma dessas coisas evita que alguém cometa um erro. Todas reduzem o raio da explosão quando ele acontece, que é a única variável que, na prática, você consegue controlar.
Um incidente grave não é uma falha moral de ninguém, é informação sobre onde o seu sistema é frágil que você não tinha até aquele momento. As equipes senior não são as que nunca quebram produção, são as que têm um processo que transforma cada incidente numa melhoria concreta do sistema, em vez de gastar a energia do time procurando um culpado enquanto o relógio do MTTR continua correndo.
