Relatório de incidente sem culpado: como escrever um que muda o sistema

Sexta, 17h40. O Carlos roda limpar-pedidos-teste.sql para zerar a base de homologação. A aba do terminal estava conectada à produção. Em 40 segundos, 1.800 pedidos do dia somem. A restauração do backup leva 2h10, porque ninguém tinha restaurado aquele backup antes. Na segunda, o relatório diz: "causa raiz: erro humano do colaborador Carlos". O script continua lá, a aba continua igual, e o Carlos nunca mais vai contar um quase-erro.

A resposta curta: o relatório de incidente (postmortem) existe para mudar o sistema, não para achar um culpado. Ele descreve o que aconteceu em linha do tempo, o impacto medido, os fatores que permitiram o erro e uma lista de ações, cada uma com dono e prazo. "Ter mais cuidado" não é ação.

Por que procurar culpado piora o próximo incidente

Quem errou o comando quase sempre fez o que parecia razoável com a informação que tinha. O Carlos não queria apagar produção. Ele viu um terminal que parecia o de homologação, com um prompt idêntico, usando a mesma credencial com permissão total. O erro dele foi o último elo de uma corrente que o sistema montou.

Quando o relatório termina num nome, duas coisas acontecem. Primeiro, a corrente fica intacta: a próxima pessoa cansada numa sexta à tarde cai no mesmo buraco. Segundo, todo mundo aprende que contar um erro tem custo. Os quase-acidentes, que são a melhor fonte de aviso que um time tem, param de ser relatados. O capítulo sobre cultura de postmortem do livro de SRE do Google trata exatamente disso: o relatório sem culpa parte do princípio de que as pessoas agiram com boa intenção e foca nas causas que podem ser corrigidas.

Sem culpa não quer dizer sem responsabilidade. As ações têm dono, e o dono responde pelo prazo. A diferença é que a responsabilidade aponta para o conserto, não para a punição.

Como escrever o relatório, passo a passo

1. Estabilize primeiro. O relatório vem depois que o serviço voltou. Durante o incidente, só anote horários e ações num canal único.
2. Monte a linha do tempo com fontes. Horário de cada evento, tirado de log, alerta, histórico do chat ou do terminal. Memória vem por último.
3. Meça o impacto. Quanto tempo, quantos usuários, quantos pedidos, quanto dinheiro, se souber. Número, não adjetivo.
4. Liste os fatores que contribuíram. Para cada momento da linha do tempo, pergunte: o que o sistema permitiu aqui? O que o alerta não mostrou? O que tornou a recuperação lenta?
5. Escreva ações concretas. Cada ação muda algo verificável, tem uma pessoa dona e uma data.
6. Revise em grupo, com quem estava no incidente. Leia a linha do tempo com eles. A pergunta da reunião é "o que faltou?", nunca "por que você fez isso?".
7. Acompanhe as ações. Revise a lista em duas semanas. Relatório com ações abertas para sempre é teatro.

O relatório do exemplo, reescrito

# Incidente 2026-10-09: pedidos do dia apagados em produção

Status: ações em andamento
Duração do impacto: 17h41 a 19h52 (2h11)
Impacto: 1.800 pedidos indisponíveis; checkout fora do ar 2h11;
         112 clientes contataram o suporte.

## Resumo
Um script de limpeza de homologação foi executado contra o banco
de produção. O backup da madrugada foi restaurado e os pedidos do
dia foram reconstruídos a partir dos eventos do gateway de pagamento.

## Linha do tempo (horário de Brasília)
17h40  Script iniciado em terminal conectado à produção.
17h41  Tabela pedidos esvaziada. Nenhum alerta dispara.
17h52  Suporte relata clientes sem pedidos no painel.
17h58  Plantão confirma a tabela vazia e abre o incidente.
18h05  Decisão: restaurar o backup das 03h00.
18h20  Descoberto que a restauração exige um volume maior que o
       disponível; volume novo provisionado.
19h30  Backup restaurado; pedidos entre 03h00 e 17h41 recriados a
       partir dos eventos do gateway.
19h52  Checkout liberado.

## Fatores que contribuíram
- Homologação e produção usam o mesmo usuário de banco, com
  permissão de DELETE em tudo.
- O prompt do terminal é idêntico nos dois ambientes.
- O script não confere em qual banco está conectado.
- Não há alerta para queda brusca no número de pedidos.
- A restauração nunca tinha sido ensaiada; o tamanho do volume
  necessário era desconhecido.

## O que funcionou
- Os eventos do gateway permitiram reconstruir os pedidos do dia.
- O suporte avisou rápido e com exemplos concretos.

## Ações
1. Usuário de banco separado por ambiente; produção sem DELETE
   para contas pessoais. Dono: Paula. Prazo: 2026-10-16.
2. Prompt do terminal com nome do ambiente em destaque.
   Dono: Diego. Prazo: 2026-10-14.
3. Script de limpeza aborta se o nome do banco não terminar em
   _homolog. Dono: Carlos. Prazo: 2026-10-13.
4. Alerta para queda de mais de 50% nos pedidos em 10 minutos.
   Dono: Renata. Prazo: 2026-10-20.
5. Ensaio mensal de restauração, com tempo medido.
   Dono: Paula. Prazo do primeiro ensaio: 2026-10-30.

Repare que o nome do Carlos só aparece como dono de uma ação. O relatório não diz "o Carlos errou"; diz "um script foi executado contra produção" e explica por que isso era fácil. As ações atacam três camadas: prevenir (credencial separada, script que confere o banco), detectar (alerta de queda) e recuperar (ensaio de restauração). Um bom relatório quase sempre tem ação nas três.

A ação 5 merece um guia próprio: backup que você consegue restaurar de verdade e rollback ensaiado tratam de transformar a recuperação em rotina, não em descoberta.

Perguntas que encontram o sistema por trás do erro

Na reunião de revisão, troque as perguntas que procuram uma pessoa por perguntas que procuram uma condição:

• Em vez de "por que você rodou isso?", pergunte "o que você via na tela naquele momento?".
• Em vez de "você não conferiu?", pergunte "o que teria avisado que era produção?".
• Em vez de "quem aprovou?", pergunte "que passo do processo deveria ter barrado isso, e por que não barrou?".
• Pergunte também "isso já quase aconteceu antes?". Muitas vezes, sim, e ninguém contou.

Se a resposta honesta a alguma pergunta for "o sistema permitia e nada avisava", você achou uma ação.

Quando escrever e quanto escrever

Combine critérios objetivos: impacto em cliente acima de um tempo definido, perda de dados, incidente de segurança, ou qualquer caso em que o plantão precisou improvisar. Quase-acidentes também valem um relatório curto. Não exija o texto perfeito no mesmo dia: peça a linha do tempo em 24 horas, enquanto os detalhes estão frescos, e o relatório completo em poucos dias úteis.

Guarde os relatórios num lugar que o time inteiro lê, e permita buscar por sistema. Quando o mesmo fator aparece em três incidentes, ele vira uma decisão de arquitetura e merece um registro de decisão próprio.

Erros comuns

• "Causa raiz: erro humano". Encerra a investigação no ponto mais barato e deixa intacta a condição que vai causar o próximo incidente.
• Ação sem dono ou sem prazo. Fica aberta para sempre, e o mesmo incidente volta com outra data no título.
• Ação vaga, como "melhorar o monitoramento". Ninguém sabe quando ela está pronta, então ela nunca fica.
• Linha do tempo de memória. Horários errados escondem onde a demora realmente aconteceu, e a ação ataca a etapa errada.
• Punir quem relatou. Na próxima vez, o erro é escondido até virar um incidente maior.
• Ignorar o que funcionou. O que salvou o dia não é protegido e pode ser removido numa refatoração qualquer.

Checklist

• A linha do tempo tem horários tirados de log, alerta ou chat.
• O impacto está em números: duração, usuários, pedidos.
• Os fatores que contribuíram descrevem condições do sistema, não falhas de caráter.
• Há ações para prevenir, detectar e recuperar.
• Toda ação tem uma pessoa dona e uma data.
• A revisão aconteceu com quem estava no incidente.
• Existe uma data marcada para conferir se as ações foram feitas.

Abra o relatório do último incidente do seu time: ele gerou uma mudança que você consegue apontar no sistema hoje, ou terminou num pedido para todo mundo ter mais cuidado?