Postmortem sem culpado

Um postmortem existe para o sistema aprender, não para o time se defender. O teste é simples: se o documento termina com “fulano esqueceu de”, ele não produziu nenhuma mudança — porque a próxima pessoa, cansada, no mesmo cenário, vai esquecer de novo.

Erro humano nunca é a causa raiz

“A pessoa aplicou o comando errado em produção” é o começo da investigação, não o fim. As perguntas úteis vêm depois:

• Por que era possível rodar aquilo em produção sem revisão ou confirmação?
• O ambiente estava identificado de forma inequívoca no terminal?
• O comando certo era mais trabalhoso que o errado?
• Por que o efeito só apareceu vinte minutos depois?
• O que impediu a detecção automática?

Cada resposta aponta para uma mudança possível no sistema — guarda-corpo, confirmação, alerta, permissão. Culpa não aponta para nenhuma.

Estrutura do documento

Curto e específico. Um postmortem de duas páginas que alguém lê vale mais que dez páginas arquivadas.

# Incidente 2026-08-14 — Checkout indisponível (Sev 1)

**Impacto.** 41 minutos (13h55–14h36). ~12.000 tentativas de compra falharam;
3,1% do orçamento de erro mensal consumido. Nenhum dado perdido.

**Resumo.** Uma alteração de configuração reduziu o pool de conexões do banco de
200 para 20. O serviço passou a esgotar o pool sob tráfego normal.

## Linha do tempo
| Horário | Evento |
| --- | --- |
| 13h48 | Deploy do serviço de pedidos (PR #482) |
| 13h55 | Erros 5xx começam a subir |
| 14h07 | Alerta de burn rate dispara; plantão acionado |
| 14h12 | Incidente declarado; comando assumido |
| 14h29 | Rollback iniciado |
| 14h36 | Taxa de erro normalizada |

## Fatores contribuintes
- O valor do pool ficava em um `values.yaml` sem comentário sobre o efeito.
- Nenhum teste de carga roda antes de produção.
- O alerta levou 12 minutos para disparar (janela de 5m + `for: 5m`).
- O painel de saturação do pool existia, mas não estava no dashboard do serviço.

## O que funcionou
- Rollback levou 7 minutos e foi executado sem hesitação.
- A comunicação com suporte saiu antes do primeiro chamado de cliente.

## Ações
| Ação | Dono | Prazo | Verificação |
| --- | --- | ---: | --- |
| Validar limites mínimos do pool no CI | @ana | 21/08 | PR com valor inválido falha |
| Painel de saturação do pool no dashboard | @bruno | 18/08 | Painel visível na primeira tela |
| Alerta de pool > 80% por 2 min | @bruno | 21/08 | Teste com carga sintética dispara |
| Teste de carga no pipeline de homologação | @carla | 04/09 | Relatório anexado ao PR |

Linha do tempo e fatores contribuintes

Use o canal do incidente como fonte: horários reais, não lembrança. Registre também o tempo de detecção (quando começou até o alerta) e de mitigação (alerta até normalizar) — os dois melhoram por caminhos diferentes.

Fale em fatores contribuintes, no plural, e não em causa raiz única. Incidente sério quase sempre é a conjunção de várias condições: uma mudança sem guarda-corpo, um alerta lento, um painel que faltava. Corrigir só a primeira deixa as outras esperando o próximo evento.

Ações com dono, prazo e verificação

A seção de ações é a única parte que muda o futuro. Regras que a mantêm honesta:

• Dono é uma pessoa, nunca um time inteiro.
• Prazo é uma data. “Em breve” significa nunca.
• Cada ação diz como se verifica que ela funcionou.
• Ações entram no backlog normal, com prioridade — combinada ali, não depois.
• No máximo cinco. Vinte ações é uma lista de desejos, e nenhuma será feita.
• Prefira eliminar a classe do problema a corrigir a instância: um guard-rail vale por dez avisos em documentação.

Revise as pendentes na reunião semanal do time. Postmortem cujas ações ninguém acompanha é ficção.

O que garante que seja mesmo sem culpa

Cultura não vem do texto; vem de sinais consistentes:

• Quem estava no teclado participa da escrita e não é identificado como causa.
• Liderança pergunta “o que tornou isso possível?” e nunca “quem fez?”.
• O documento é público internamente, e ninguém é penalizado por publicá-lo.
• Incidente evitado por pouco (near miss) também rende postmortem — é aprendizado de graça.

Se as pessoas escondem erro por medo, você perde a informação mais valiosa que o sistema produz. E aí o próximo incidente será uma surpresa completa.

Próximo passo: para que quem responde não adoeça no processo, veja Plantão sustentável.