Um template de post-mortem que produz mudança

Já li centenas de post-mortems, meus e de outras pessoas. Os bons compartilham uma propriedade que não tem nada a ver com qualidade de escrita: trinta dias depois, alguma coisa no sistema está diferente por causa deles. Os ruins costumam ser mais bem escritos. Têm linha do tempo, causa raiz, lista de ações, e nenhuma das ações sai do papel.

A diferença é estrutural. Um post-mortem que produz mudança é construído em torno de perguntas que forçam especificidades desconfortáveis. Este é o template que eu uso, e o motivo de cada seção existir.

Impacto, na unidade do cliente

Não 'a API ficou degradada por 42 minutos'. Em vez disso: quantos usuários foram afetados, o que eles não conseguiram fazer, quantos pedidos ou consultas ou mensagens foram perdidos ou atrasados, e quanto custou, em dinheiro, confiança ou horas de suporte. Se o número não é conhecido, escreva 'desconhecido' e adicione descobrir às ações. O objetivo é tornar o peso do incidente visível para quem decide no que a engenharia vai trabalhar em seguida.

Linha do tempo, com os intervalos nomeados

Uma linha do tempo da primeira causa até a recuperação completa, com horários. A parte útil não são os eventos, são os intervalos entre eles. Quanto tempo entre a falha começar e alguém perceber? Entre perceber e entender? Entre entender e agir? Entre agir e recuperar? Cada intervalo é um problema separado com uma solução separada. Quarenta minutos entre falha e detecção é problema de alerta. Quarenta minutos entre detecção e entendimento é problema de observabilidade. Quarenta minutos entre entendimento e recuperação é problema de deploy ou de runbook.

Causas contribuintes, no plural

Quase nunca existe uma causa raiz só. Existe um gatilho, e existem três ou quatro condições que transformaram o gatilho em queda. O deploy ruim foi o gatilho. A falta de health check deixou ele chegar em todas as instâncias. A ausência de canary fez ele chegar de uma vez. O limiar do alerta estava alto demais para disparar. O runbook apontava para um dashboard velho. Cada um desses é uma causa, e corrigir só o gatilho garante que o próximo gatilho vai encontrar as mesmas condições esperando.

Eu pergunto 'o que teria transformado isso num não-evento' para cada camada: prevenção, detecção, mitigação, recuperação. Cada camada geralmente rende uma mudança concreta.

Ações com dono, data e teste

É aqui que a maioria dos templates falha. 'Melhorar o monitoramento' não é ação. 'Adicionar alerta de latência p99 acima de 2 segundos por 5 minutos no endpoint de checkout, com dono nomeado, pronto até tal data, verificado disparando em staging' é ação. Todo item precisa das quatro partes: o que exatamente, quem, quando e como vamos saber que funcionou.

Depois, a regra dura: as ações vão para o mesmo tracker do trabalho de produto, com o mesmo processo de priorização. Se moram num documento separado, morrem nesse documento. Se alguém decide não fazer uma delas, essa decisão fica escrita com o nome de quem decidiu, para que o próximo post-mortem possa referenciar com honestidade.

As perguntas que deixam ele honesto

• O que acreditávamos sobre o sistema que se mostrou falso?
• Que sinal estava disponível antes do incidente e ninguém estava olhando?
• O que a pessoa de plantão precisou improvisar que deveria estar escrito?
• Qual dessas ações teríamos rejeitado como desnecessária um mês atrás, e por quê?
• Qual é o próximo incidente que esse mesmo conjunto de condições produziria, se não corrigirmos nada?

Essa última é a pergunta em que eu insisto. Ela transforma o post-mortem de um relatório sobre o passado numa previsão sobre o futuro, e previsão é o que consegue orçamento.

Uma última coisa, sobre culpa. A pessoa que fez o deploy ruim não é a causa. O sistema que deixou um push virar queda é a causa. Diga isso com clareza, e as pessoas vão contar o que realmente aconteceu em vez do que protege elas. Mas sem culpa não quer dizer que nada muda. Quer dizer que as mudanças caem sobre o sistema, não sobre a pessoa, e o template acima é como você garante que elas caiam em algum lugar.