Resposta a Incidentes: Runbooks, Papéis e o Que Fazer Quando Tudo Cai

Todo sistema que roda tempo suficiente vai falhar. A pergunta que separa uma operação madura de uma amadora não é "como evitar todo incidente" — isso é impossível — mas "o que fazemos quando um acontece". Times que respondem bem a incidentes não são os que têm engenheiros mais heróicos; são os que têm processo: papéis definidos, runbooks prontos, comunicação clara e um ritual de aprendizado depois. Improviso sob pressão é o que transforma um problema de dez minutos numa saga de horas.

Resposta a incidentes é a disciplina de detectar, mitigar, resolver e aprender com falhas em produção de forma organizada. Este guia percorre o ciclo de vida de um incidente e as práticas que fazem cada etapa correr sem pânico.

O que é (e o que não é) um incidente#

Um incidente é qualquer evento não planejado que degrada ou interrompe um serviço a ponto de exigir resposta imediata. Nem todo bug é incidente, e nem todo alerta é incidente. A distinção prática: se está afetando usuários agora, ou vai afetar em breve se ninguém agir, é incidente.

O primeiro instrumento de organização é a classificação por severidade. Ela alinha a resposta ao tamanho do problema, evitando tanto o exagero (acordar dez pessoas por um soluço) quanto o descaso (tratar uma queda total como ticket comum):

• SEV1 / Crítico: serviço principal fora, perda de dados, impacto amplo em

usuários ou receita. Resposta imediata, todas as mãos, comunicação externa.

• SEV2 / Alto: funcionalidade importante degradada, parte dos usuários

afetada, sem workaround trivial. Resposta rápida, on-call acionado.

• SEV3 / Médio: impacto limitado, com workaround, sem urgência de madrugada.

Tratado em horário comercial.

Definir esses níveis antes do incidente é o que evita a discussão inútil de "isso é grave?" no meio do fogo. A severidade dita quem é acionado, quão rápido, e quanto de comunicação o caso exige.

Os papéis: quem faz o quê no meio do caos#

O erro mais comum em incidentes grandes é ter cinco engenheiros mexendo na mesma coisa, ninguém coordenando e ninguém comunicando. Papéis claros resolvem isso. Mesmo em times pequenos, onde uma pessoa acumula funções, saber qual "chapéu" está usando muda o comportamento.

Incident Commander (IC)#

O comandante do incidente. Não é quem mexe no sistema — é quem coordena. O IC mantém a visão geral, decide prioridades, delega, e garante que o processo anda. A regra de ouro: o IC não deveria estar de mãos no teclado consertando; ele orquestra para que quem conserta tenha espaço para pensar. Em um incidente sério, ter alguém explicitamente "com o chapéu de IC" evita a paralisia de decisão coletiva.

Operações / responder#

Quem efetivamente investiga e aplica as mudanças no sistema. Foca em uma coisa por vez, comunica o que está fazendo ao IC, e não aplica mudanças arriscadas sem alinhar. Em SEV1, pode haver vários responders, cada um em uma frente, coordenados pelo IC.

Comunicador#

Responsável por manter os interessados informados — outros times, liderança, e, quando aplicável, os clientes via página de status. Libera o IC e os responders de ficarem respondendo "e aí, já resolveu?" a cada dois minutos, o que sozinho já justifica o papel.

O runbook: pensamento enlatado para a hora errada#

Um runbook é um documento com o passo a passo para diagnosticar e resolver uma classe conhecida de problema. É pensamento feito com calma, guardado para o momento em que você não tem calma. Às três da manhã, com adrenalina alta, ninguém raciocina no seu melhor — o runbook é a memória externa que impede erros óbvios.

Um bom runbook para um sintoma específico contém:

```text RUNBOOK: Latência alta na API de pedidos

SINTOMA: p99 de /api/pedidos acima de 2s por mais de 5 min ALERTA: "pedidos-latencia-alta" no Grafana

DIAGNÓSTICO (nesta ordem):

1. Checar dashboard de pedidos: latência do banco subiu junto?

-> se sim, ir para o runbook de banco lento

1. Checar saturação de conexões do pool (métrica db_pool_in_use)
2. Ver traces recentes com trace_id dos requests lentos
3. Checar se houve deploy nos últimos 30 min (correlação comum)

MITIGAÇÃO:

• Se foi deploy recente: reverter para a release anterior (ver runbook de rollback)
• Se pool saturado: escalar réplicas via kubectl scale ...
• Se banco lento sem deploy: acionar DBA on-call

ESCALAÇÃO: se não mitigou em 20 min, subir para SEV2 e acionar IC sênior ```

Repare que o runbook não promete resolver tudo — ele estrutura a investigação, lista as hipóteses mais prováveis em ordem, e define quando escalar. Os melhores runbooks nascem dos post-mortems: cada incidente novo que não tinha runbook vira um runbook para a próxima vez.

Um cuidado importante: runbook desatualizado é pior que ausência de runbook, porque manda você por um caminho que não existe mais. Trate-os como código — revisados, versionados, testados. Um comando no runbook que aponta para um serviço extinto vai custar minutos preciosos no pior momento.

A resposta, passo a passo#

Com papéis e runbooks no lugar, o fluxo de um incidente ganha forma:

Detecção. Idealmente, o alerta chega antes do cliente reclamar. Alertas bons são acionáveis — disparam sobre sintomas que afetam o usuário (latência, taxa de erro, indisponibilidade), não sobre causas intermediárias que podem ser ruído. Um alerta que dispara e ninguém precisa fazer nada treina o time a ignorar alertas.

Triagem e mobilização. Classifica a severidade, aciona quem precisa, e — em SEV1/SEV2 — abre um canal dedicado de comunicação (uma sala, um canal de chat) onde tudo sobre o incidente acontece. Nomeia o IC.

Mitigação antes de resolução. Este é o ponto que iniciantes erram: o objetivo imediato não é entender a causa raiz, é parar a dor do usuário. Se reverter o último deploy faz o serviço voltar, reverta agora e investigue a causa depois, com o sistema estável. Mitigar primeiro, entender depois.

Resolução e verificação. Com a dor estancada, resolve-se a causa de fato e confirma-se, com métricas, que o serviço voltou ao normal — não pela sensação de que "parece ok", mas pelos indicadores voltando ao verde.

Encerramento. Comunica-se a resolução, fecha-se o canal, e agenda-se o post-mortem. O incidente não acabou de verdade até o aprendizado ser capturado.

Comunicação: o que dizer, e para quem#

Durante o incidente, a comunicação interna deve ser frequente e factual: o que sabemos, o que estamos fazendo, qual a próxima atualização. Silêncio gera pânico e enche o canal de "novidades?". Uma cadência fixa ("atualizo a cada 15 minutos, mesmo que seja para dizer que ainda estou investigando") acalma todos.

Para o cliente, honestidade e ausência de jargão. Uma página de status que reconhece o problema, descreve o impacto em termos que o usuário entende e promete uma próxima atualização vale mais que silêncio ou que promessas vazias de "já vai voltar". A confiança se perde no incidente mal comunicado, não no incidente em si.

O post-mortem sem culpa: onde o valor real aparece#

O incidente termina, o serviço voltou, todo mundo quer esquecer. É exatamente aqui que os times medíocres param e os bons começam. O post-mortem sem culpa (blameless) é a reunião onde se reconstrói o que aconteceu para aprender, não para achar um culpado.

A premissa é psicológica antes de técnica: se as pessoas temem punição, elas escondem informação, e você nunca descobre a causa real. O post-mortem parte do princípio de que ninguém age de má-fé — as pessoas fazem o melhor com a informação e as ferramentas que tinham no momento. Quando "o fulano derrubou o banco" vira "o sistema permitiu que um comando de rotina derrubasse o banco sem confirmação", a conversa muda de caça às bruxas para melhoria de sistema.

Um post-mortem útil produz:

• Linha do tempo factual: o que aconteceu, quando, o que foi observado.

Reconstruída com logs e o trace_id dos eventos, não de memória.

• Análise de causa: não só a causa técnica imediata, mas os fatores que

permitiram que ela virasse incidente (faltou alerta? faltou runbook? um health check mal configurado?).

• Ações de melhoria concretas, com dono e prazo. Um post-mortem que gera uma

lista de "deveríamos" sem responsável nem data é teatro.

As melhores ações de melhoria atacam o sistema, não as pessoas: adicionar o alerta que faltou, criar o runbook que não existia, corrigir o health check que causou a cascata, adicionar a confirmação no comando destrutivo. Cada incidente bem aproveitado torna a próxima falha da mesma classe menos provável ou menos grave.

Preparar em tempo de paz#

Tudo o que foi descrito funciona porque é preparado antes do incidente, na calmaria. A pior hora para descobrir que ninguém sabe quem é o Incident Commander, que o runbook está desatualizado ou que ninguém tem acesso ao painel de métricas é no meio do fogo. Operações maduras investem em prontidão:

• Escala de plantão (on-call) sustentável. Quem responde precisa estar

descansado e ter as ferramentas à mão. Uma escala que esgota as pessoas produz respostas piores e rotatividade. Plantão bom é rotativo, previsível e com carga humana.

• Ferramentas de acesso prontas. Painéis, logs e comandos de mitigação

acessíveis rapidamente, com as permissões já resolvidas. Ninguém deveria pedir acesso a um sistema no meio de um SEV1.

• Simulados de incidente. Assim como se testa a restauração de backup, vale

ensaiar a resposta a incidentes com cenários controlados — os chamados "game days". Eles revelam runbooks furados, papéis mal entendidos e lacunas de ferramenta, sem o custo de um incidente real.

O tempo investido em preparação se paga com juros no primeiro incidente sério. Processo ensaiado é processo que funciona sob pressão; processo só documentado é processo que ninguém segue quando a adrenalina sobe.

O ciclo virtuoso#

Resposta a incidentes bem-feita fecha um ciclo. O alerta detecta cedo. Os papéis organizam a resposta. O runbook acelera a mitigação. A comunicação preserva a confiança. O post-mortem gera melhorias que viram novos runbooks e novos alertas — que tornam o próximo incidente mais raro e mais brando.

O objetivo nunca é zero incidentes; é reduzir o tempo de detecção e recuperação (o MTTR) e garantir que a mesma falha não te pegue duas vezes da mesma forma. Sistemas complexos falham — é da natureza deles. O que você controla é a qualidade da sua resposta. E essa qualidade não vem de heróis acordados às três da manhã, mas do processo chato e disciplinado que você montou com calma, muito antes do alerta tocar.