Escalação de incidente em produção

Você é um especialista em resposta a incidentes (incident response) de sistemas de produção. Me ajude a estruturar/conduzir: [CONTEXTO — um incidente está acontecendo AGORA em [SISTEMA] e preciso de estrutura para conduzir bem/quero montar o processo de resposta a incidente do time antes que aconteça de novo/tivemos um incidente mal conduzido recentemente e quero corrigir o processo]. Entregue — se incidente ativo agora: os primeiros passos na ordem certa (declarar o incidente formalmente com a severidade estimada — a demora em declarar é a demora em mobilizar ajuda; nomear um incident commander — a pessoa que coordena e decide, sem necessariamente ser quem conserta tecnicamente, para que quem está debugando não precise também gerenciar comunicação; abrir um canal único de comunicação do incidente — evitar a informação fragmentada entre DMs e threads paralelas; estabilizar antes de investigar a fundo — a mitigação imediata como prioridade sobre entender a causa raiz completa); para o processo estruturado: os níveis de severidade definidos com critério objetivo (o que torna um incidente SEV1 versus SEV3 no MEU contexto — impacto no usuário, escopo, reversibilidade — com o protocolo de resposta correspondente a cada nível, incluindo quem é acionado e com que urgência), os papéis claros durante o incidente (incident commander coordenando, o time técnico executando, a comunicação externa/interna como responsabilidade separada e explícita — ninguém acumulando os três papéis num incidente sério), a escalação com critério (quando chamar mais gente, quando acordar alguém de madrugada, a cadeia de escalação definida com antecedência para não perder tempo decidindo isso NO meio da crise), a comunicação durante o incidente (o status atualizado em intervalos regulares mesmo sem novidade — 'ainda investigando, próxima atualização em 15 min' é melhor que silêncio; a comunicação externa ao cliente quando aplicável, honesta sem pânico desnecessário), o encerramento formal do incidente (o critério claro de quando considerar resolvido — não só 'parece que voltou ao normal' sem confirmação), o post-mortem sem culpa como etapa obrigatória e não opcional (a linha do tempo reconstruída, a causa raiz identificada através de investigação sistemática, as ações preventivas com dono e prazo — e a cultura blameless que faz as pessoas reportarem problema cedo em vez de esconder por medo), e o runbook de incidente documentado e testado antes da próxima crise (o documento vivo que o time revisa e simula periodicamente, não escrito uma vez e esquecido na gaveta). Objetivo: uma crise conduzida com calma e método — que termina resolvida rápido e vira aprendizado real, não numa segunda crise de comunicação por cima da primeira.