Incident Commander

O Incident Commander (IC) é o responsável por liderar e coordenar a resposta a incidentes de alta gravidade ou complexidade, especialmente quando a situação ultrapassa o nível de atuação do Analista do Command Center. Sua função é garantir uma gestão eficiente do incidente, definindo prioridades, coordenando as ações necessárias, acionando as equipes responsáveis e assegurando uma comunicação clara e contínua com todas as partes envolvidas até a completa restauração e estabilização do serviço.

O IC não é o especialista técnico que executa a correção. Sua função é coordenar a resposta, priorizar ações, garantir comunicação e manter o foco na restauração do serviço.
Infográfico de gestão de incidentes do Command Center: as 6 etapas do processo (detecção e triagem, quando o IC é acionado, IC assume o comando, resposta e coordenação, comunicação durante o incidente, encerramento), além dos blocos de War Room, boas práticas do papel e a missão do IC.

O papel

O conceito de Incident Commander (IC) tem origem no Incident Command System (ICS), uma estrutura criada originalmente para coordenar operações de emergência que envolvem múltiplas equipes, alta complexidade e necessidade de tomada rápida de decisão. Ao longo do tempo, esse modelo foi incorporado às práticas de SRE (Site Reliability Engineering) e à gestão de serviços de tecnologia como uma forma eficiente de centralizar a coordenação de incidentes críticos.

O principal objetivo do IC é evitar que cada equipe técnica atue de maneira isolada, tomando decisões desconectadas ou investigando o mesmo problema sem uma visão compartilhada da situação. Durante um incidente, o IC assume a responsabilidade pela coordenação da resposta, garantindo que todas as ações estejam alinhadas, priorizadas e direcionadas para a restauração do serviço no menor tempo possível.

Na prática, o Incident Commander não precisa ser a pessoa mais sênior da organização, nem necessariamente o profissional com maior conhecimento técnico sobre o sistema afetado. O papel exige, principalmente, capacidade de liderança, organização, comunicação e visão sistêmica.

Enquanto os especialistas técnicos concentram seus esforços em investigar sintomas, identificar a causa e implementar a solução, o IC mantém uma visão completa do incidente e conduz a operação como um todo. Entre suas principais responsabilidades estão:

  • Definir prioridades e próximos passos.
  • Organizar e distribuir responsabilidades entre as equipes envolvidas.
  • Garantir que as pessoas certas sejam acionadas no momento adequado.
  • Evitar atividades duplicadas ou investigações sem direcionamento.
  • Acompanhar a evolução das ações e remover impedimentos.
  • Manter uma comunicação clara, objetiva e contínua sobre o status do incidente.
  • Garantir que a resposta permaneça focada na mitigação do impacto e na restauração do serviço.

Dessa forma, o IC atua como o ponto central de coordenação do incidente, sem necessariamente executar diretamente a investigação ou a correção técnica. Essa separação de responsabilidades permite que os especialistas permaneçam concentrados na resolução do problema, enquanto o Incident Commander garante que a operação avance de maneira organizada, coordenada e eficiente.

Quando o IC é acionado

O Incident Commander (IC) deve ser acionado sempre que a gravidade, o impacto ou a complexidade de um incidente ultrapassar a capacidade de atuação e coordenação do Analista do Command Center. O objetivo é garantir que incidentes mais críticos recebam uma gestão estruturada, com as equipes adequadas envolvidas, decisões centralizadas e comunicação contínua até a restauração do serviço.

O acionamento do IC deve ocorrer, entre outros cenários, quando:

  • O Runbook disponível não resolve o incidente ou as ações previstas não produzem o resultado esperado.
  • Não existe um Runbook aplicável para o cenário identificado.
  • A severidade do incidente aumenta durante o atendimento.
  • O impacto operacional ou para o cliente ultrapassa o nível de atuação do Analista do Command Center.
  • Há risco de indisponibilidade generalizada, degradação significativa ou ampliação do impacto.
  • É necessária uma alteração em componente crítico, com potencial risco para outros serviços ou ambientes.
  • É necessária a atuação de equipes especializadas ou múltiplas áreas técnicas, exigindo coordenação centralizada.
  • O incidente apresenta alta complexidade, múltiplas dependências ou dificuldade de diagnóstico, tornando necessária uma gestão dedicada da resposta.

Nos incidentes classificados como P1 - Critical, o acionamento do Incident Commander é obrigatório desde o início do atendimento, garantindo uma coordenação imediata diante da criticidade e do potencial impacto ao negócio.

Para incidentes classificados como P2 - High, o acionamento do IC ocorre conforme a necessidade e a evolução do incidente. O Analista do Command Center deve realizar o escalonamento sempre que identificar aumento de impacto, dificuldade na resolução, necessidade de múltiplas equipes ou qualquer outro fator que torne necessária uma coordenação mais ampla da resposta.

Em resumo: o IC não é acionado apenas pela severidade do incidente, mas principalmente pela necessidade de uma coordenação centralizada para garantir uma resposta rápida, organizada e eficiente.

O fluxo abaixo ilustra esse processo até o ponto de escalonamento: da identificação do incidente ou alerta pelo Analista Command Center, passando pela verificação de Runbook, até o acionamento do N2 quando o problema não é resolvido no primeiro nível.

Fluxograma do processo de atendimento do Command Center: identificação do incidente ou alerta, verificação de runbook, execução de comandos pré-definidos, escalonamento para o N2 do cliente quando necessário, comunicação de estabilidade e encerramento do atendimento.

No fluxograma, "NOC" corresponde ao Analista Command Center. O indicador de MTTA e volume de acionamentos no rodapé é ilustrativo do tier de NOC Compartilhado e varia conforme o contrato.

Responsabilidades

Ao assumir formalmente o comando do incidente, o IC deve:

  • Avaliar ou reavaliar a severidade.
  • Definir prioridades.
  • Acionar as equipes N2/N3 necessárias.
  • Determinar a necessidade de abrir uma War Room.
  • Coordenar as ações técnicas, garantindo que exista um responsável por cada atividade.
  • Evitar execução paralela descoordenada entre as equipes envolvidas.
  • Manter os stakeholders informados durante todo o incidente.
  • Garantir o registro da linha do tempo do atendimento.
  • Avaliar os riscos de qualquer mudança proposta como mitigação.
  • Confirmar a restauração do serviço e conduzir o encerramento.
  • Solicitar Postmortem e RCA (Root Cause Analysis) quando aplicável.
  • Acompanhar as ações decorrentes do incidente até sua conclusão.

Na prática, boa parte dessas responsabilidades converge para manter um registro único e vivo do incidente - a mesma linha do tempo, atualizada continuamente, serve tanto para coordenar a resposta em tempo real quanto de base para o Postmortem e a RCA depois do encerramento.

War Room

Em incidentes críticos ou de alta complexidade, o Incident Commander (IC) pode estabelecer uma War Room como ponto central de coordenação da resposta. O objetivo é reunir, em um único ambiente, todas as pessoas, informações e ações necessárias para a gestão eficiente do incidente, evitando comunicações fragmentadas, informações desencontradas e decisões tomadas de forma isolada.

A War Room funciona como a fonte central de informações do incidente, proporcionando ao IC uma visão consolidada da situação e permitindo que todas as equipes envolvidas acompanhem a evolução do atendimento em tempo real.

Infográfico War Room - Linha do tempo: acompanhamento em tempo real da evolução do incidente, com os marcos incidente detectado, War Room iniciada, investigação iniciada, ação de mitigação, serviço estabilizado, serviço restaurado e encerramento do incidente, cada um com horário, descrição, responsável e status.

Nesse espaço, devem ser centralizados:

  • Participantes e equipes envolvidas: identificação clara das pessoas e áreas responsáveis pelo atendimento.
  • Decisões tomadas: registro das principais decisões, incluindo contexto e impactos.
  • Linha do tempo do incidente: acompanhamento cronológico dos principais eventos e mudanças ocorridas.
  • Evidências e informações relevantes: logs, alertas, métricas, análises e demais dados que apoiem a investigação.
  • Ações em andamento e responsáveis: definição clara de quem está executando cada atividade.
  • Próximos passos: organização das ações prioritárias e sequência da resposta.
  • Atualizações de status: comunicação contínua sobre impacto, progresso, mitigação e previsão de restauração.

A abertura de uma War Room permite que os especialistas técnicos permaneçam concentrados na investigação e na resolução do problema, enquanto o Incident Commander mantém a visão geral, coordena as equipes e garante que todas as ações avancem de forma alinhada e organizada.

Dessa forma, a War Room deixa de ser apenas um canal de comunicação e passa a atuar como o centro operacional do incidente, garantindo maior agilidade, transparência, rastreabilidade e eficiência durante todo o processo de resposta e restauração do serviço.

Comunicação durante o incidente

A comunicação é parte essencial da resposta operacional e deve ocorrer de forma contínua durante todo o ciclo de vida do incidente - não como uma atividade separada ou realizada apenas ao final do atendimento.

Durante incidentes críticos, o Incident Commander (IC) é responsável por garantir que as partes interessadas recebam atualizações claras, consistentes e adequadas ao nível de impacto do incidente. O objetivo é assegurar que todos os envolvidos tenham uma visão comum da situação, das ações em andamento e da evolução da recuperação.

As comunicações devem informar, sempre que aplicável:

  • O que aconteceu: descrição objetiva do incidente identificado.
  • Qual serviço ou ambiente está afetado: identificação clara dos sistemas, aplicações ou componentes impactados.
  • Qual é o impacto conhecido: abrangência do incidente para usuários, clientes e operação.
  • Qual é a severidade: classificação atual do incidente e seu nível de criticidade.
  • O que está sendo feito: principais ações de investigação, mitigação e recuperação em andamento.
  • Quem está atuando: equipes ou áreas responsáveis pelas ações necessárias.
  • Qual é o próximo marco ou atualização prevista: indicação clara de quando haverá uma nova comunicação, mesmo que ainda não exista uma previsão de resolução.
  • Quando o serviço for restaurado: confirmação da normalização ou recuperação do serviço.
  • Se existem riscos ou impactos residuais: identificação de degradações, limitações ou ações adicionais necessárias após a restauração.

A comunicação conduzida pelo IC deve ser objetiva, clara, factual e consistente, baseada exclusivamente em informações confirmadas até aquele momento. Hipóteses, suposições ou possíveis causas ainda não validadas não devem ser comunicadas como fatos.

Quando houver incerteza, ela deve ser explicitamente indicada. É preferível informar que uma investigação está em andamento e que determinada informação ainda está sendo validada do que compartilhar uma conclusão incorreta ou prematura.

Os canais oficiais de comunicação incluem Microsoft Teams, e-mail e WhatsApp, conforme os fluxos, contatos e canais previamente definidos na documentação disponibilizada para cada cliente.

Dessa forma, o Incident Commander garante que a comunicação acompanhe a evolução do incidente, mantendo clientes, equipes técnicas e demais partes interessadas informados, alinhados e conscientes do impacto, das ações em andamento e do processo de recuperação.

Encerramento

Após a confirmação da restauração do serviço, o Incident Commander (IC) conduz o processo de encerramento do incidente. A simples recuperação momentânea do ambiente não é suficiente para considerar o atendimento concluído: é necessário validar que o serviço foi efetivamente restaurado e permanece estável.

Antes de declarar o incidente como resolvido, o IC deve garantir, sempre que aplicável, que:

  • O serviço afetado foi restaurado e está operacional.
  • A estabilidade do ambiente foi confirmada por meio de monitoramento, testes ou validação técnica.
  • O impacto aos usuários ou ao negócio foi interrompido ou devidamente mitigado.
  • Não existem ações críticas pendentes para a continuidade do serviço.
  • As equipes envolvidas confirmaram a conclusão das atividades sob sua responsabilidade.
  • As partes interessadas foram comunicadas sobre a restauração do serviço.
  • Eventuais riscos, limitações ou impactos residuais foram identificados e registrados.

Somente após essas validações o incidente deve ser oficialmente considerado resolvido e encerrado.

O encerramento do incidente não significa, necessariamente, que todas as causas definitivas já foram eliminadas. Em alguns casos, o serviço pode ser restaurado por meio de uma mitigação temporária, sendo necessária uma investigação posterior para identificar a causa raiz e implementar uma solução definitiva.

O papel do IC, portanto, é garantir que o incidente seja encerrado de forma controlada, validada e comunicada, assegurando que a organização tenha clareza sobre o estado final do serviço e sobre quaisquer ações que ainda precisem ser realizadas após o encerramento operacional.

Boas práticas do papel

A atuação do Incident Commander (IC) exige disciplina operacional, capacidade de coordenação e consciência de que seu principal objetivo não é resolver sozinho o problema técnico, mas garantir que a resposta ao incidente aconteça de forma organizada, eficiente e coordenada.

Algumas boas práticas são fundamentais para o desempenho desse papel:

  • Delegar em vez de executar. O IC deve evitar assumir diretamente todas as atividades técnicas. Sua principal responsabilidade é coordenar a resposta, definir prioridades e garantir que cada ação tenha um responsável claramente definido. Delegar adequadamente evita que o IC se torne um gargalo e permite que mantenha a visão geral do incidente.
  • Definir claramente responsabilidades e próximos passos. Cada ação deve ter, sempre que possível, um responsável, um objetivo e um retorno esperado. Evite instruções genéricas como "alguém verifica isso?". Prefira direcionamentos claros, como "Equipe N2, verificar o comportamento do serviço X e retornar com uma atualização em 15 minutos".
  • Realizar handoffs explícitos. Em incidentes prolongados ou durante trocas de turno, a transferência da função de IC deve ser formal e estruturada. A pessoa que assume precisa receber o contexto completo, incluindo impacto atual, ações realizadas, atividades em andamento, responsáveis, decisões tomadas, riscos e próximos passos. A transição só deve ser considerada concluída após o reconhecimento explícito de quem está assumindo o comando.
  • Confiar na autonomia dos responsáveis pelas ações. Após acionar uma equipe especializada ou delegar uma atividade, o IC deve acompanhar o progresso sem microgerenciar a execução técnica. O papel do IC é remover impedimentos, alinhar prioridades e cobrar atualizações, permitindo que os especialistas tenham autonomia para investigar e executar a solução.
  • Manter uma única linha de coordenação. Mesmo com várias equipes atuando simultaneamente, é importante que exista clareza sobre quem está coordenando o incidente. Decisões, prioridades e mudanças de direcionamento devem passar pelo IC ou estar alinhadas com ele, evitando comandos conflitantes e esforços duplicados.
  • Registrar decisões e informações importantes. Decisões relevantes, mudanças de estratégia, ações executadas e eventos importantes devem ser registrados na linha do tempo do incidente. Isso garante rastreabilidade, facilita a comunicação e torna a transferência de contexto mais eficiente caso seja necessário realizar um handoff.
  • Alternar quem exerce o papel de IC. A função não deve ficar concentrada sempre na mesma pessoa ou apenas nos profissionais mais experientes. A rotatividade controlada permite desenvolver capacidade de liderança e resposta a incidentes em diferentes membros da equipe, reduzindo a dependência de indivíduos específicos e aumentando a maturidade operacional do time.
  • Monitorar a própria carga de trabalho. O IC deve estar atento à sua capacidade de manter uma coordenação eficiente. Se a quantidade de informações, decisões e interações começar a comprometer sua visão geral, esse é um sinal para solicitar apoio, designar funções auxiliares ou redistribuir responsabilidades. Acumular mais tarefas em um momento crítico tende a aumentar o risco de falhas na coordenação.
  • Separar coordenação de investigação técnica. Sempre que possível, quem está conduzindo a coordenação não deve ser a mesma pessoa responsável pela investigação profunda ou pela execução da correção. Essa separação permite que os especialistas se concentrem no problema técnico enquanto o IC acompanha o impacto, organiza as equipes, controla a comunicação e direciona a resposta.
  • Manter foco no impacto e na restauração do serviço. Durante um incidente, o objetivo prioritário é reduzir o impacto e restaurar a operação com segurança. A investigação detalhada da causa raiz pode continuar posteriormente, caso não seja necessária para a mitigação imediata. O IC deve evitar que o time perca tempo buscando respostas definitivas enquanto existe uma alternativa segura para restaurar o serviço.
Em resumo, um bom Incident Commander não é quem faz mais coisas durante um incidente - é quem garante que as coisas certas sejam feitas, pelas pessoas certas, no momento certo, com todos trabalhando de forma coordenada.