Incident Response

Todo sistema complexo tem incidentes. A questão não é evitá-los completamente — isso é impossível — mas responder a eles de forma eficaz. A diferença entre um incidente que dura 20 minutos e um que dura 4 horas raramente é técnica: quase sempre é organizacional. Times que respondem bem a incidentes têm papéis claros, comunicação estruturada, processo de escalação previsível, e hábito de não tomar decisões precipitadas sob pressão. Times que respondem mal têm heróis individuais que fazem tudo sozinhos enquanto todos os outros observam ou interrompem.

Incident response como disciplina tem raízes no Incident Command System (ICS) desenvolvido pelos bombeiros americanos nos anos 1970 após o incêndio de Laguna Oaks em 1970, onde múltiplas agências respondendo sem coordenação central criaram um caos que piorou o desastre. O ICS definiu papéis, hierarquia de comando, e protocolos de comunicação que funcionavam mesmo quando o ambiente estava em chamas. O Google, Amazon e outras empresas de tecnologia adaptaram esses princípios para incidentes de software — com simplificações relevantes para o contexto digital.

Este conceito percorre as fases de resposta a incidentes, os papéis em um war room eficaz, e as práticas de comunicação que mantêm a situação controlada enquanto o problema é resolvido.

Fases do incident response

Um incidente bem gerenciado passa por cinco fases distintas. A confusão mais comum é misturar as fases — especialmente triage e diagnóstico, que são diferentes em propósito e urgência.

Fase 1 — Detecção

Um incidente começa quando é detectado — seja por alerta automático, por relatório de usuário, ou por engenheiro observando anomalia. A métrica de qualidade aqui é o tempo até detecção (TTD): quanto tempo passou entre a falha real e o time saber que havia uma falha?

A maior parte do trabalho de reduzir TTD é prévia ao incidente: alertas bem configurados, SLOs instrumentados, dashboards de health visíveis para o time de on-call. Um incidente detectado em 2 minutos por alerta é completamente diferente de um detectado em 20 minutos quando um usuário liga para suporte.

Fase 2 — Triage

Triage é a avaliação rápida de severidade — não diagnóstico de causa raiz. As perguntas de triage são: Quantos usuários estão afetados? Qual serviço está afetado? A falha está se espalhando ou está contida? Precisa de escalação imediata?

Triage deve durar no máximo 5 minutos. O objetivo é classificar a severidade e acionar as pessoas certas — não resolver o problema. Um engenheiro que passa 30 minutos fazendo triage sem escalar está usando triage para procrastinar a decisão de pedir ajuda.

Fase 3 — Mitigação

Mitigação é a ação de reduzir o impacto no usuário — mesmo que a causa raiz não tenha sido identificada ainda. Isso é uma distinção crucial: a mitigação não precisa resolver o problema permanentemente, precisa reduzir o dano enquanto a investigação continua.

Ações típicas de mitigação: rollback do último deploy (se o incidente coincide com um deploy recente), ligar um kill switch de feature flag para a feature problemática, escalar o número de instâncias se o problema é de capacidade, redirecionar tráfego para uma região sem o problema.

Fase 4 — Diagnóstico e resolução

Com o impacto mitigado (ou enquanto a mitigação está sendo aplicada em paralelo), a investigação da causa raiz pode acontecer com menos urgência. As ferramentas aqui são os logs, traces, métricas, e o histórico de mudanças recentes. A pergunta central: o que mudou? Deploys recentes, mudanças de configuração, aumento de tráfego, mudança de comportamento de dependências.

Fase 5 — Resolução e follow-up

O incidente é declarado resolvido quando o steady state foi restaurado e o risco de recorrência imediata foi mitigado. Depois da resolução: comunicar o encerramento para os stakeholders, garantir que o monitoramento voltou ao normal, e agendar o postmortem (se aplicável).

Papéis no war room

Um incidente P0 ou P1 requer mais de uma pessoa. O war room — físico ou virtual (Slack channel + video call) — precisa de papéis definidos para evitar que todos tentem resolver o problema ao mesmo tempo e ninguém coordene a resposta.

Incident Commander (IC)

O IC é quem comanda o incidente — não necessariamente quem vai digitar o comando que resolve o problema. Responsabilidades: manter a visão geral do estado do incidente, coordenar quem está fazendo o quê, tomar decisões quando há ambiguidade, escalar quando necessário, e garantir que comunicação está fluindo.

O IC não deve estar no terminal resolvendo o problema técnico. Quando o IC está com o SSH aberto e esquece de comunicar por 20 minutos, o resto do time fica sem informação e começa a tomar ações paralelas que podem piorar a situação.

Operations Lead

Engenheiro(s) que executam as ações técnicas: fazer deploy, alterar configuração, executar rollback, analisar logs. Reportam ao IC o que encontraram e o que estão fazendo. O Ops Lead comunica tudo no canal do incidente — mesmo ações pequenas — para que o IC tenha visibilidade completa.

Communications Lead

Responsável por comunicação com stakeholders externos ao war room: atualizar a página de status (Statuspage, Incident.io), responder tickets de suporte, atualizar o canal Slack público de incidentes, notificar gerentes e produto com updates regulares. O Communications Lead não deve estar diagnosticando o problema — a função é de relações-públicas internas.

Scribe

Documenta o que está acontecendo em tempo real: ações tomadas, hipóteses levantadas, evidências encontradas, decisões tomadas e por quê. O documento do scribe se torna a linha do tempo do postmortem. Em incidentes menores, o IC ou o Ops Lead pode acumular essa função, mas em incidentes complexos a documentação em paralelo é essencial.

Comunicação durante o incidente

A comunicação durante o incidente tem dois públicos com necessidades diferentes: o war room (comunicação técnica, detalhada, frequente) e os stakeholders (comunicação executiva, simples, regular).

Comunicação no war room: tudo que é relevante vai para o canal do incidente no Slack (ou equivalente). Hipóteses, ações, resultados, dados de métricas, links para dashboards. O canal é o estado compartilhado do incidente. Quem entrar depois deve conseguir entender o que aconteceu lendo o histórico.

Cadência de updates para stakeholders: a cada 15–20 minutos para incidentes ativos, os stakeholders precisam saber: status atual (ainda afetado, parcialmente mitigado, resolvido), número de usuários afetados, ação em andamento, ETA estimado. O ETA pode ser "desconhecido" — mas deve ser comunicado explicitamente como desconhecido em vez de simplesmente não comunicado.

Linguagem de comunicação: comunicação para stakeholders deve ser não-técnica. "Database primary failover triggered" não é comunicação adequada para o VP de Produto. "Serviço de checkout indisponível para ~30% dos usuários; equipe aplicando correção, ETA ~20 minutos" é.

Status pages

Para serviços com usuários externos ou parceiros, uma página de status pública (Statuspage.io, Incident.io, Atlassian Statuspage) é essencial. Ela serve dois propósitos: informar usuários afetados de que o problema é conhecido e sendo trabalhado (reduz tickets de suporte), e demonstrar transparência — uma empresa que comunica seus incidentes proativamente gera mais confiança do que uma que esconde.

Template de comunicação de incidente — update a cada 15 minutos:

[14:45] Investigando: Estamos cientes de uma degradação
no serviço de checkout. Aproximadamente 30% dos pedidos
estão encontrando erros. Nossa equipe está investigando.

[15:00] Identificado: Identificamos a causa como um
problema no serviço de processamento de pagamentos.
Aplicando correção.

[15:15] Monitorando: A correção foi aplicada. Taxa de erro
caiu de 30% para 2%. Continuamos monitorando para
confirmar recuperação completa.

[15:30] Resolvido: O serviço está operando normalmente.
Publicaremos um postmortem com detalhes em 5 dias úteis.

Escalação — quando e como

A decisão de escalar é uma das mais difíceis no incidente: escalar cedo demais gera ruído e "alarme de lobo"; escalar tarde demais prolonga o impacto por falta de expertise. As heurísticas que ajudam:

• Escalar se o incidente está ativo por mais de X minutos sem progresso (onde X é definido pelo SLO de MTTR do serviço)
• Escalar se a causa raiz envolve um componente que o time não tem expertise para diagnosticar
• Escalar se ações de mitigação foram tentadas e falharam
• Escalar se há risco de impacto financeiro, legal, ou de dados

A escalação deve ser para a pessoa certa, com o contexto certo. "Preciso de ajuda" não é escalação eficaz. "Serviço X está com taxa de erro de 15% há 30 minutos, tentamos rollback e ajuste de timeout sem sucesso, suspeito de problema no banco — você pode ajudar a investigar as queries lentas?" é.

Pós-incidente imediato

Nos 30 minutos após a resolução, enquanto o contexto ainda está vivo:

• Comunicar resolução para todos os stakeholders
• Verificar que todos os sistemas voltaram ao steady state (não apenas o serviço afetado)
• Verificar se monitoramento está funcionando normalmente
• Criar o ticket de postmortem com: hora de início, hora de fim, impacto estimado, ações tomadas (do registro do scribe)
• Garantir que a pessoa de on-call tem capacidade de continuar operando (descanso, se necessário)

Como praticar

1. Definir papéis e processo do war room. Documente no runbook do time: quem pode ser IC, como um IC é designado em um incidente P0, qual canal Slack é usado para o war room, qual o template de comunicação para stakeholders. Faça um tabletop exercise onde alguém pratica o papel de IC enquanto o facilitador "informa" sobre o incidente verbalmente.
2. Criar um template de atualização de status. Para cada nível de severidade (P0, P1, P2), crie um template de comunicação que funciona para: o canal interno do war room, o canal Slack de stakeholders, e a página de status pública (se aplicável). Teste que qualquer membro do time consegue usar o template sem treinamento.
3. Auditar o processo de escalação. Mapeie: quando alguém de on-call precisa escalar em um incidente P0, quem chamar, como chamar (telefone, Slack, PagerDuty), e o que informar. Verifique que todos os contatos estão atualizados. Muitos incidentes são prolongados porque a lista de escalação estava desatualizada.