Incidentes e postmortem sem culpa

1. O que é um incidente

Incidente é qualquer problema que afeta os usuários e pede resposta agora: o site fora do ar, pagamentos falhando, dados errados na tela. Um bom sinal para abrir um incidente é o error budget sendo gasto rápido demais. Na dúvida, abra. Fechar um incidente que era alarme falso custa pouco.

2. Primeiro restaurar, depois entender

Durante o incidente, o objetivo é o usuário voltar a ser atendido. A investigação da causa vem depois, com calma. Caminhos rápidos para restaurar:

• desfazer o último deploy ou reverter o último commit, no GitOps;
• desligar a funcionalidade nova por uma feature flag;
• mandar o tráfego para outra região ou réplica saudável.

Anote tudo o que for feito, com horário. Essas anotações viram a linha do tempo do postmortem.

3. Três papéis que evitam o caos

A documentação aberta de resposta a incidentes da PagerDuty descreve vários papéis. Para começar, três bastam:

• Coordenação. Organiza a resposta, decide prioridades, distribui tarefas. Não digita comando.
• Investigação. Uma ou mais pessoas que mexem no sistema, sempre avisando antes no canal do incidente.
• Comunicação. Atualiza clientes, suporte e liderança, para que quem investiga não seja interrompido.

Num time pequeno, uma pessoa pode acumular dois papéis. O importante é todo mundo saber quem coordena.

4. Comunicar sem a resposta

Silêncio gera ansiedade e boato. Uma mensagem honesta, mesmo sem a causa, já ajuda. Modelos para adaptar:

Estamos investigando falhas no pagamento desde as 14h10.
Parte dos clientes não consegue concluir compras.
Próxima atualização até as 14h40.

Identificamos que o problema começou após uma mudança das 14h05
e estamos revertendo. Próxima atualização até as 15h.

O pagamento voltou ao normal às 14h52. Vamos publicar o que aconteceu
e o que muda nos próximos dias.

5. Postmortem sem culpa

Postmortem é o texto que conta o que aconteceu, por que aconteceu e o que muda. O livro de SRE do Google insiste num ponto: ele é sem culpa. Parte do princípio de que todas as pessoas agiram com boa intenção, com a informação que tinham.

A troca de pergunta é o que importa:

Com medo de punição, as pessoas escondem detalhes, e a causa real não aparece. Sem culpa, o time aprende com fatos.

6. Um modelo para copiar

# Postmortem: [título curto]
Data: | Duração: | Severidade:

## Resumo
Duas ou três frases: o que os usuários sentiram e por quanto tempo.

## Impacto
Quantos usuários, quais funções, quanto do error budget foi gasto.

## Linha do tempo
14h05 mudança X entra em produção
14h10 alerta de taxa de erro no checkout
14h12 incidente aberto, coordenação com Ana
14h48 reversão concluída
14h52 serviço normal

## O que contribuiu
Fatores do sistema e do processo, não pessoas.

## O que funcionou bem

## Ações
| Ação | Dono | Prazo |
| Bloquear deploy sem teste de integração no pipeline | Ana | 20/11 |

Ação boa é concreta e tem dono e prazo. "Ter mais cuidado" não é ação: não muda nada no sistema.

7. Missão final