A crença mais difundida sobre incidentes de produção é que o que importa mesmo é a velocidade da resposta — quanto mais rápido o time reagir, melhor o resultado. Essa premissa soa razoável até você observar o que de fato acontece nos primeiros minutos de uma crise real: pessoas duplicando esforços, ninguém coordenando comunicação com stakeholders, engenheiros atropelando uns aos outros nos canais, e decisões críticas sendo tomadas por quem gritou mais alto. A velocidade sem estrutura não resolve incidentes, ela amplifica o caos.
Por que a maioria dos times ainda improvisa
Quase todo time tem algum runbook, algum canal de #incidents no Slack e alguma definição vaga de severidade. O problema é que essas peças existem de forma isolada, sem constituir um processo coerente. Quando o incidente de fato acontece, ninguém sabe quem está no comando, quem fala com o cliente, quem documenta a timeline. Cada pessoa age segundo o seu instinto — que é diferente do instinto de todo mundo ao redor.
Isso não é falha de caráter. É falha de design. Um processo de incident response não nasce naturalmente da boa vontade de engenheiros competentes. Ele precisa ser deliberadamente desenhado, documentado e, principalmente, exercitado antes de ser necessário de verdade. Times que só testam o processo durante incidentes reais estão aprendendo da forma mais cara possível.
A anatomia de um incidente bem gerenciado
Um incidente estruturado começa com a clareza de severidade. Não basta ter um SEV1, SEV2, SEV3 no papel: cada nível precisa ter critérios objetivos — impacto financeiro, percentual de usuários afetados, degradação de SLA — e implicações claras de resposta. SEV1 acorda todo mundo às três da manhã. SEV3 pode esperar o horário comercial. Quando esses critérios não estão definidos, cada engenheiro de plantão decide por conta própria o que é grave o suficiente para escalar.
A partir da declaração de severidade, três papéis precisam ser atribuídos de forma explícita. O Incident Commander, ou IC, é quem comanda a cena: não necessariamente o mais técnico da sala, mas quem mantém o processo, delega investigações, toma decisões quando há impasse e determina quando o incidente está resolvido. O Tech Lead foca exclusivamente em diagnosticar e mitigar — sem se preocupar com comunicação ou coordenação. O Comms Lead cuida dos stakeholders internos e externos, alimentando status pages e respondendo mensagens de líderes que querem saber o que está acontecendo. Quando esses papéis não estão claros, o Tech Lead perde tempo respondendo no Slack enquanto o sistema ainda está falhando.
A armadilha do herói solitário de plantão
Existe uma versão romantizada de incident response em que o engenheiro mais experiente aparece, acessa o terminal e, com uma sequência de comandos enigmáticos, resolve tudo em vinte minutos. Esse herói existe em alguns times, e essa é exatamente a razão pela qual esses times têm um problema grave.
O herói solitário cria dependência, acumula burnout e não transfere conhecimento. Quando ele sai de férias, o time fica com medo de qualquer alerta. Quando ele pede demissão — e ele vai pedir, porque herói de plantão não aguentam muito tempo —, o time descobre que ninguém mais sabe como funciona a infraestrutura crítica. Incident response estruturado é, entre outras coisas, uma estratégia de distribuição de conhecimento. Quando o processo existe e os papéis são rodízio, mais pessoas entendem os sistemas, mais pessoas se sentem capazes de responder, e a dependência de uma única pessoa diminui.
Como construir um processo que reduz MTTR sem destruir o time
O indicador que mais importa para avaliar a saúde do processo não é o número de incidentes — é o MTTR, o tempo médio para recuperação. Reduzir MTTR é uma consequência de várias decisões de design, não de pressionar o time a trabalhar mais rápido sob estresse.
A primeira alavanca é a qualidade dos alertas. Times que têm dezenas de alertas barulhentos treinam os engenheiros a ignorar notificações, criando um risco sistêmico: quando o alerta que realmente importa chega, ele se perde no ruído. Menos alertas, mais precisos, com contexto suficiente para que o engenheiro entenda de imediato o que está errado e onde olhar — isso reduz os primeiros minutos de desorientação que custam muito MTTR.
A segunda alavanca é o runbook vivo. Não o documento criado uma vez e esquecido, mas um recurso atualizado após cada incidente com os diagnósticos que funcionaram, os comandos que ajudaram, os falsos positivos a evitar. O runbook não substitui o julgamento, mas elimina o tempo gasto reinventando soluções para problemas já vistos.
A terceira alavanca é a prática deliberada. Fire drills — simulações de incidentes em horário comercial, com cenários planejados — são a diferença entre um time que conhece o processo intelectualmente e um time que consegue executá-lo sob pressão. A resistência a fazer simulações costuma vir do argumento de que "temos trabalho real pra fazer". O custo de um time despreparado durante um SEV1 de domingo à noite responde esse argumento com clareza.
O postmortem como sistema de aprendizado
A parte mais subestimada do incident response é o que acontece depois que o sistema volta. O postmortem blameless — sem atribuição de culpa individual — existe por uma razão técnica, não apenas ética: sistemas complexos falham por causa de condições sistêmicas, não por causa de um engenheiro que tomou uma decisão ruim às duas da manhã com informações incompletas. Culpar pessoas é uma explicação que fecha a conversa. Entender as condições que tornaram aquela falha possível é o que evita a próxima.
Um bom postmortem tem uma timeline factual do incidente, uma análise de causa raiz que vai além do sintoma imediato — cinco porquês até chegar na condição sistêmica —, e ações corretivas com dono e prazo definidos. O que distingue um postmortem que gera aprendizado de um que é apenas burocracia é a honestidade das perguntas: o que o sistema de monitoramento não detectou? Que decisão de arquitetura tornou esse blast radius tão grande? O processo de deploy tinha algum gate que poderia ter evitado isso?
O aprendizado acumulado em postmortems bem feitos é um dos ativos mais valiosos de um time de engenharia. É o conhecimento coletivo sobre como os sistemas falham — e esse conhecimento, sistematizado, é o que permite construir sistemas progressivamente mais resilientes.
Leia também
- SRE na prática: o que muda quando engenharia e operações se fundem
- Métricas Site Reliability Engineering: Definindo e Monitorando SLIs, SLOs e SLAs
- Bug Tracking: Guia Completo
- Bug Tracking: Boas Praticas com Casos Reais
- Bug Tracking: Boas Praticas com Checklist
- Ciclo de Testes de Software: Tendencias com Checklist