A maioria dos postmortems é arqueologia: um registo exato de algo que ninguém vai mudar. Um útil produz um pequeno número de coisas que realmente são feitas.
O propósito de um postmortem não é documentar o que aconteceu. É tornar o incidente seguinte menos provável ou menos danoso. Tudo no documento deve servir isso, e o que não serve é cerimónia.
Sem culpados é um mecanismo, não uma delicadeza
Os postmortems sem culpados são muitas vezes explicados como uma gentileza. Isso desvaloriza-os. Existem porque quem espera ser culpado retém informação — e a informação retida é precisamente a que teria evitado a repetição.
Uma estrutura que resulta
- Resumo — três frases: o que partiu, durante quanto tempo, quem foi afetado. A maioria dos leitores para aqui, portanto tem de se sustentar sozinho.
- Impacto — duração, utilizadores afetados, consequências de receita ou dados, em números quando possível
- Cronologia — factos com marcas temporais, do primeiro sintoma à resolução, incluindo quando as pessoas souberam
- Fatores contribuintes — no plural, e honestos quanto aos de processo, não só quanto ao gatilho técnico
- O que correu bem — genuinamente útil para reforçar a deteção ou resposta que funcionou
- Ações — cada uma com responsável e data
A causa raiz é normalmente uma história, não uma linha
«O deploy causou a falha» é onde a análise para quando a reunião está apressada. Os verdadeiros fatores contribuintes costumam ser assim:
| Camada | Exemplo de constatação |
|---|---|
| Gatilho | Foi feito deploy de uma alteração de configuração |
| Porque partiu | A alteração era sintaticamente válida mas semanticamente errada |
| Porque nada a apanhou | Nenhum ambiente de staging correspondia à configuração de produção |
| Porque demorou 40 minutos a notar | Os alertas vigiavam o CPU, não a taxa de sucesso do pagamento |
| Porque a recuperação foi lenta | O rollback nunca tinha sido testado para alterações apenas de configuração |
Quatro destes cinco são problemas de processo. Corrija apenas o gatilho e a mesma classe de incidente volta com outra roupagem.
Ações: a parte que decide se algo disto importou
- Três a cinco itens no máximo — uma lista de vinte é uma lista de zero
- Cada um com um responsável nomeado, não uma equipa
- Cada um com data, acompanhado no mesmo sistema do trabalho normal
- Prefira itens que removam uma classe de falha (uma guarda) a itens que corrigem uma instância
- Reveja-os no postmortem seguinte — os itens por terminar da vez anterior são o ponto de agenda mais importante
Um postmortem sem ações concluídas até ao incidente seguinte não é um processo. É um hábito de arquivo.
Timing e audiência
- Rascunho em 48 horas — a exatidão degrada-se depressa
- Reunir 30 a 45 minutos, não mais; o documento faz a maior parte do trabalho
- Incluir todos os envolvidos, mais uma pessoa que não esteve (faz as perguntas óbvias que os de dentro saltam)
- Partilhar amplamente — a transparência interna sobre a falha é como as organizações melhoram nisto
Verificar as ações preventivas
Um postmortem deve alterar um controlo ou uma decisão. Cada ação precisa de prova de conclusão.
- Separar factos, hipóteses e condições contributivas.
- Ligar cada ação ao mecanismo de falha tratado.
- Verificar por teste, exercício de alerta ou restauro.
Perguntas frequentes
Quanto tempo depois de um incidente deve acontecer o postmortem?
Rascunho em 48 horas e reunião na semana seguinte. A memória da sequência exata e do raciocínio degrada-se depressa, e os detalhes que mais importam — o que alguém acreditava na altura e porquê — são os primeiros a desaparecer.
O que torna um postmortem sem culpados na prática?
Perguntar como o sistema permitiu a falha em vez de quem a causou. Na prática: sem nomes associados a erros no documento, perguntas formuladas sobre mecanismos em vez de decisões, e ações que acrescentam guardas em vez de pedir às pessoas que tenham mais cuidado.
Quantas ações deve produzir um postmortem?
Três a cinco, cada uma com responsável nomeado e data. Listas maiores são um sinal fiável de que nada será feito — e os itens por terminar devem ser o primeiro ponto da agenda da revisão seguinte.
Quando está concluída uma ação de postmortem?
Quando a evidência acordada é apresentada e revista. Fechar um pedido ou atualizar documentação não demonstra necessariamente mudança de comportamento.
Os incidentes repetem-se?
Isso é um problema de processo, não de azar. Auditamos a prática de entrega e de incidentes e reparamos o mecanismo.
Leitura complementar
Como lidar com uma falha em produção: um manual para equipas pequenas
Numa falha, o problema técnico raramente é a parte difícil. A coordenação é. Esta é a sequência que impede uma equipa pequena de piorar a situação.
Auditoria de processos de engenharia: o que olhamos e porquê
Quando uma equipa entrega devagar, a causa quase nunca são os engenheiros. São normalmente quatro ou cinco atritos concretos que ninguém mediu.