Blameless Postmortems & On-Call
Premissa: o sistema e o culpado, nao a pessoa. Como conduzir, runbooks e cultura de oncall
A premissa fundamental: pessoas inteligentes cometem erros quando o sistema lhes permite. Em vez de "quem causou", a pergunta certa e "por que o sistema permitiu que essa falha humana virasse incidente?". Isso muda completamente o que voce aprende.
Por que "blameless"?
Quando o time procura culpado, todo mundo aprende a esconder erros — incidentes futuros viram piores porque as pessoas tentam consertar sozinhas em panico, ou nao reportam ate ser tarde demais. Pesquisa de Google SRE: equipes que adotaram blameless aumentaram a quantidade de incidentes reportados em ~3x, e o tempo de detecao caiu por que pessoas escalam mais cedo.
O contrato com a equipe
- Ninguem e punido por causar um incidente. Apertou deploy sexta as 17h59 e quebrou prod? Aprende, melhora a deploy guardrail.
- A excecao e dishonestidade. Mentir sobre o que aconteceu, encobrir, dificultar investigacao — isso sim e problema cultural.
- O foco e o sistema. "Por que conseguimos deployer sem revisao?" e melhor que "Por que voce nao reviu?"
- Aprendizado e o output. Um postmortem sem action items concretos foi tempo perdido.
Antipatterns culturais
| Comportamento | O que sinaliza | Custo |
|---|---|---|
| "Quem fez esse merge?" | Procurando culpado | Pessoa esconde proximo erro |
| "Voce nao testou?" | Atacando individuo | Reuniao vira defensiva, ninguem fala |
| Postmortem fechado a alguns | Esconde aprendizado do time amplo | Mesmo incidente acontece em outro servico |
| Action items sem owner ou prazo | Performance ritual | Nada muda, incidente repete |
| "Vamos so treinar a pessoa" | Confunde sintoma com causa | Sistema continua fragil |
Outra pessoa faria o mesmo? O teste mental do blameless: se voce trocasse a pessoa por qualquer outro engenheiro do time naquele contexto (cansacao, falta de info, ferramenta confusa), o erro aconteceria de novo? Se sim, o sistema e o problema. Quase sempre e sim.
Como tratar um engenheiro que causou um incidente serio?
A reuniao de postmortem trata do incidente, nao da pessoa. Voce agradece a transparencia (especialmente se a pessoa se reportou); investiga por que o sistema permitiu o erro (faltou guardrail, faltou review, faltou alerta cedo); e converte action items em mudanca do sistema. Conversas de performance/desempenho da pessoa, se cabiveis, sao em outro espaco, com manager — nunca na reuniao de incidente. Misturar as duas coisas mata a cultura. Excecao: dishonestidade ou negligencia repetida (mesmo padrao varias vezes apos action items claros) — ai vira topico de performance, fora do postmortem.