O que você faz para evitar que o mesmo tipo de incident aconteça uma segunda vez?

Question

Accepted Answer

Conduza um **postmortem blameless** que encontre a causa sistêmica, depois converta-a em itens de ação **concretos, com responsáveis e rastreados** — e verifique que eles de fato sejam entregues. O objetivo não é encontrar quem culpar; é mudar o sistema para que a mesma classe de falha se torne impossível ou autodetectável.

## O loop central

1. **Postmortem blameless.** Construa uma linha do tempo honesta: o que aconteceu, quando detectamos, como respondemos, qual foi o impacto. A culpa mata a verdade de que você precisa.
2. **Cave até a causa sistêmica**, não o gatilho. "Um engenheiro subiu uma config ruim" é um gatilho; "não havia validação ou rollout em etapas para configs" é a causa. Use os **Cinco Porquês**, mas pare no sistema, nunca em uma pessoa.
3. **Gere camadas de prevenção**, não uma única correção:
   - **Prevenir** — tornar a falha impossível (validação, tipos, guardrails).
   - **Detectar** — pegá-la mais cedo (alertas, SLOs, checks sintéticos).
   - **Mitigar** — limitar o raio de impacto (rollback, flags, circuit breakers).
4. **Atribua responsáveis e prazos.** Um item de ação sem responsável é um desejo. Rastreie-os como trabalho real no backlog.
5. **Verifique e feche o loop.** A correção foi entregue? Ela teria pego o problema original? O MTTR e a detecção realmente melhoraram?

## Trade-offs e armadilhas

- **Postmortems que produzem documentos, não mudanças** — a falha mais comum. Sem acompanhamento, você reencontrará o mesmo incident.
- **Corrigir em excesso o sintoma específico** enquanto a classe do bug permanece aberta. Conserte a categoria, não só esta instância.
- **Fadiga de alertas** por empilhar detecção sem ajuste; alertas ruidosos são ignorados e o próximo incident escapa.
- **Cultura de culpa** empurra o reporte para a clandestinidade; você perde os quase-acidentes, que são suas lições mais baratas.
- Trate **incidents repetidos como um sinal de falha de processo**, não azar — rastreie a recorrência como uma métrica.

## Por que isso importa

Incidents são uma mensalidade que você já pagou; o único desperdício é não aprender com eles. Um time que sistematicamente previne a recorrência fica mais confiável a cada trimestre, enquanto um time que apenas apaga incêndios revive as mesmas quedas para sempre. Construir esse loop de aprendizado — e a segurança para ser honesto nele — é uma das coisas mais duradouras que um Tech Lead pode deixar.