O guia prático que ninguém te conta sobre a cultura de pós-mortem
A maioria das empresas que diz querer fazer um explique o que aconteceu de verdade está fazendo errado desde o começo. Eles marcam uma reunião, chamam os envolvidos, alguém anota em um quadro branco e todo mundo volta pro trabalho achando que agora "o problema foi resolvido". A realidade é bem mais chata e exige processo. O que existe por trás dessa expressão é o conceito de post-mortem ou incidente review, popularizado pela engineering culture da Netflix e depois adotado massivamente em operações de infraestrutura, SRE e DevOps. Não é sobre apontar dedos. É sobre reconstruir a linha do tempo de forma objetiva e extrair ações que realmente sejam feitas.
Como estruturar um verdadeiro explique o que aconteceu
O primeiro passo é documentar a linha do tempo em milissegundos. Não "na sexta à tarde", mas "às 14:32:07 UTC o alert disparou porque o threshold de latência no serviço X foi atingido". Quando eu trabalhava em uma equipe de infraestrutura, lidávamos com um incidente de banco de dados onde o DBA que estava de plantão conseguiu recuperar parcialmente os dados após 4 horas, mas só porque encontrou um wal-level configuration desatualizado num arquivo de backup que não deveria existir naquela versão. Isso foi registrado no post-mortem como raiz do problema, não como causa secundária. A estrutura mínima que funciona é:
- Impacto: Quantos usuários foram afetados, por quanto tempo, qual o custo estimado (financeiro ou de reputação).
- Linha do tempo: Do primeiro sinal ao momento em que a situação foi estabilizada.
- Causa raiz: Não a causa superficial, aquela que te leva a dar dois passos de "por quê" antes de parar. O problema real.
- Ações corretivas: Cada item precisa de dono e prazo. Ação sem dono é só uma sugestão bonita no documento.
O erro mais comum que vejo é a causa raiz ser algo vago como "falha humana" ou "deploy ruim". Isso não explica nada. Se o deploy errou, qual mecanismo de proteção falhou? Por que o rollback automático não disparou? Qual teste no pipeline deveria ter pegado aquilo?
👉 Clique no botão abaixo para saber mais sobre o assunto!
A armadilha que quase todo mundo cai
Documentar o post-mortem é fácil. O problema real é garantir que as ações saiam do documento e virem rotina. Eu vi equipes que tinham post-mortems impecáveis, com 20 páginas bem escritas, e seis meses depois tudo voltava ao estado anterior porque ninguém acompanhava o fechamento das ações. Uma prática que funcionou na minha experiência foi vincular cada ação corretiva a um ticket de tracking interno, com SLA de cumplimiento. Se a ação era "refatorar o script de deploy para incluir verificação de compatibilidade de schema", o ticket não era fechado até que o código fosse mergiado e testado. Sem isso, vira papelada.
Também tem o detalhe do timing. Fazer o post-mortem muito rápido depois do incidente gera conclusões superficiais porque as pessoas ainda estão no modo reativo. Mas esperar semanas também é ruim porque os detalhes somem da memória. O sweet spot que eu via funcionar era 24 a 48 horas após a estabilização completa, com os dados técnicos já coletados. Outro ponto que poucos consideram: o post-mortem deve ser feito com as pessoas envolvidas presentes, mas o documento final precisa ser acessível a qualquer membro da equipe. Informações técnicas de alto nível devem estar visíveis para toda a organização, enquanto os detalhes sensíveis podem ficar em versão interna restrita. Não adianta ter um excelente explique o que aconteceu se ele fica trancado numa pasta que só três pessoas acessam.
O formato do documento também importa menos do que o conteúdo, mas ter um template padrão economiza tempo e evita que cada post-mortem seja uma obra diferente. Template não significa rigidez. Significa que você gasta menos tempo pensando na estrutura e mais tempo preenchendo o que realmente importa.
