Não é preciso montar uma equipe de comando ou fazer uma reunião de duas horas para aprender com uma falha em produção. Uma revisão breve registra o que as pessoas usuárias perceberam, recompõe a sequência dos fatos e escolhe uma mudança de sistema que reduza a chance ou o impacto de repetição. O objetivo não é provar que você “deveria ter sabido”; é melhorar o ambiente da próxima decisão.
| Seção | Pergunta | Evidência útil |
|---|---|---|
| Resumo | O que falhou e para quem? | Horários, duração, usuários e efeito no negócio |
| Detecção | Como você percebeu? | Alerta, teste sintético, chamado ou descoberta manual |
| Linha do tempo | O que observou e fez? | Deploys, logs, mudanças e mitigação com horários |
| Condições contribuintes | Por que falha passou ou foi difícil de detectar? | Teste ausente, padrão inseguro, dependência ou runbook |
| Acompanhamento | O que reduzirá chance ou impacto? | Ação pequena, responsável, prazo e prova |
“A importação terminou com zero registros depois de o provedor mudar um campo” é observação; “esqueci de testar” ainda explica pouco. Pergunte por que a mudança passou despercebida, como o importador chamou isso de sucesso e qual validação teria alertado antes de afetar dados. Várias condições podem ter se combinado; não force uma única causa raiz.
Esse princípio também ajuda no trabalho individual. A vergonha incentiva esconder quase-incidentes. Considere que você tomou a melhor decisão possível com a informação e as ferramentas disponíveis naquele momento. Depois melhore o sistema: validação de contrato, padrão seguro, rollback, alerta, teste de backup ou runbook mais claro. Responsabilidade não é se culpar; é mudar as condições que estão ao seu alcance.
“Reescrever a integração” não é plano. Prefira “rejeitar uma versão de esquema desconhecida e alertar antes de gravar qualquer linha”. Defina prazo realista e prova de conclusão: teste, sinal no dashboard, exercício de restauração ou verificação do runbook. Uma ação de alto valor concluída é melhor que uma lista esquecida.
Resumo: … Impacto: … Detecção: … Linha do tempo: … Condições contribuintes: … O que funcionou: … Ações: responsável / prazo / evidência. Guarde junto ao runbook, remova identificadores de clientes e acompanhe até verificar as ações.
Um postmortem individual pode levar dez minutos e ocupar uma página. Preserve evidências, descreva o impacto, explique as condições sem culpar e escolha uma melhoria verificável. Só há valor quando a lição muda um teste, proteção, alerta ou procedimento de recuperação.