Resposta a incidentes

Incidente não é uma questão de talento individual; é uma questão de processo ensaiado. Times que resolvem rápido não têm pessoas mais espertas — têm papéis definidos, um canal só, e o hábito de mitigar antes de entender. Sem isso, cinco pessoas competentes investigam a mesma hipótese em paralelo enquanto ninguém avisa o suporte.

Severidade: combine antes

Severidade define quem é acordado e com que urgência. Escreva a tabela e deixe-a acessível no canal de plantão:

Sev	Situação	Resposta
1	Serviço principal indisponível ou perda de dados	Acorda o plantão na hora, comando declarado, comunicação externa
2	Degradação séria para muitos usuários, ou funcionalidade crítica fora	Plantão em horário estendido, comunicação interna
3	Impacto limitado, com contorno conhecido	Horário comercial, vira ticket

Na dúvida, classifique para cima. Rebaixar depois é barato; descobrir tarde que era Sev 1 custa horas de impacto. Quem recebe o alerta pode declarar — não espere autorização de gestão para abrir um incidente.

Papéis: comando, comunicação e operação

Mesmo com três pessoas, separe as funções — o erro mais comum é a mesma pessoa investigar e responder a diretoria ao mesmo tempo, fazendo mal as duas coisas.

• Comando (IC). Coordena, decide, mantém a lista de hipóteses e o que já foi descartado. Não mexe no sistema — se estiver com as mãos no teclado, ninguém está coordenando.
• Comunicação. Atualiza status page, suporte e as pessoas interessadas em intervalo fixo (a cada 30 minutos, mesmo sem novidade). “Ainda investigando, próxima atualização às 15h” é uma atualização válida.
• Operações. Executa: consulta, muda, reverte. Anuncia no canal antes de agir.

Quem declarou o incidente assume o comando até passar explicitamente para alguém: “Ana, você assume o comando?” — “Assumo.” Transferência silenciosa não existe.

Os primeiros dez minutos

 1. Declare. Abra o canal do incidente e diga a severidade.
 2. Assuma o comando, em voz alta, e nomeie comunicação e operações.
 3. Responda: qual é o impacto no usuário? Desde quando? Quantos afetados?
 4. Pergunte o que mudou: deploy, feature flag, migração, mudança de infra, certificado.
 5. Se houver mudança recente suspeita, reverta. Não peça diagnóstico primeiro.
 6. Comunique externamente se for Sev 1 ou 2.
 7. Registre tudo no canal, com horário — isso vira a linha do tempo do postmortem.

# "O que mudou?" — comece por aqui, quase sempre a resposta está nos últimos deploys
kubectl rollout history deployment/loja -n prod
kubectl get events -A --sort-by=.lastTimestamp | tail -40
git log --since="3 hours ago" --oneline --all

Mitigar antes de diagnosticar

O objetivo durante o incidente é parar o impacto, não descobrir a causa raiz. Causa raiz é trabalho do postmortem, com calma e sem pressão.

Mitigações que resolvem a maioria dos casos: reverter o deploy, desligar a feature flag, crescer réplicas, desviar tráfego para outra região, ativar modo degradado (desligar recomendação e manter o checkout), limitar taxa da origem abusiva.

Reverta primeiro e investigue com o sistema saudável. A exceção é migração de banco: uma reversão de schema pode piorar tudo — por isso migração se faz em expand/contract, para que a versão anterior continue funcionando.

Comunicação com quem não é técnico

Diga impacto, escopo e próximo passo, sem jargão e sem prometer prazo que você não tem:

14h20 — Estamos com falhas no checkout desde 13h55. Parte das pessoas não consegue finalizar a compra; navegação e carrinho funcionam. Já identificamos a origem e estamos revertendo. Próxima atualização às 14h50.

Nunca escreva “resolvido” antes de confirmar pelos números — a métrica de sintoma voltando ao normal, não o gráfico de CPU.

Encerramento e transição

Encerre explicitamente: sintoma normalizado por tempo suficiente, comunicação final enviada, incidente marcado com horário de início e fim. Antes de todo mundo dispersar, combine três coisas: quem escreve o postmortem, até quando, e o que precisa de acompanhamento imediato (fila acumulada, dado inconsistente, alerta silenciado que precisa voltar).

Se o incidente durar horas, faça passagem de turno formal: estado atual, hipóteses descartadas, ações em andamento e quem assume o comando. Cansaço causa mais erro que falta de conhecimento.

Próximo passo: transforme o que aconteceu em mudança real com Postmortem sem culpado.