Meu sistema crítico está fora do ar
Resposta rápida
Sistema crítico fora do ar exige resposta em minutos, em quatro frentes simultâneas. Primeiro, confirme o escopo real (quem está afetado, quais processos param, desde quando) — sem isso, qualquer decisão é cega. Segundo, acione fornecedor ou time interno responsável com o SLA contratual em mãos: a ligação certa, no canal certo, com o ticket aberto na severidade certa. Terceiro, comunique o negócio em uma única mensagem clara: o que está fora, impacto esperado, próxima atualização em quanto tempo (sempre dê próximo prazo, mesmo que ainda não tenha solução). Quarto, comece a contingência: o que pode rodar manual, qual sistema secundário absorve carga, quem precisa parar de tentar usar. Restaurar serviço é o objetivo imediato; RCA detalhado e prevenção vêm depois, mas precisam vir.
Na empresa pequena, o "sistema crítico" costuma ser o ERP ou a plataforma que sustenta venda. O time interno é mínimo; o fornecedor (ou MSP) é quem efetivamente recupera. A primeira ação é abrir o ticket na severidade alta — não relegar à fila padrão — e ligar em paralelo, porque ticket sozinho rara vez dispara prioridade. Tenha o número do suporte fora do sistema (na agenda do celular, impresso na recepção) e a referência do contrato em mãos para o atendente. Como costuma haver pouca redundância, contingência manual ganha peso: anotar pedidos em papel, processar depois; comunicar clientes pelo telefone. Comunicação interna cabe em conversa direta com dono e gestores; comunicação externa (cliente afetado) é o que costuma ser esquecido — e o que mais cobra depois.
Na empresa média, há time interno de TI e contrato com SLA formal. O risco no minuto zero é o erro de classificação: incidente que deveria ser severidade 1 sobe como 2, e o relógio do fornecedor não corre na velocidade certa. Tenha matriz de severidade pré-acordada, conhecida por todo o time de suporte, com critério objetivo (quantos usuários afetados, processo de negócio impactado, tempo fora). Monte mini war room mesmo informal — chamada de voz com TI, gestor da área afetada e contato do fornecedor — em vez de troca de mensagens dispersas. Estabeleça cadência fixa de atualização ao negócio (a cada 30-60 minutos, mesmo sem novidade), porque silêncio é interpretado como descontrole.
Na empresa grande, há NOC, processos formais de incident management, SLA contratual com penalidade. O risco característico é a inflação de cerimônia: muitas calls, muita gente, ninguém decidindo. A solução é incident commander designado — uma pessoa com autoridade clara para coordenar a resposta, decidir escaladas e mudanças de severidade, e ser o ponto único de comunicação com o negócio. Use o runbook de incidente já existente, ative o canal dedicado (war room virtual, ponte de voz), e mantenha cadência rigorosa de atualização. Em paralelo, RH e comunicação institucional precisam ter rascunho pronto caso o incidente vire externo (mídia, clientes em massa). RCA pós-incidente é mandatório e segue rito formal — sem ele, a próxima crise repete a mesma falha.
- Sistema essencial parou e usuários estão sem conseguir trabalhar
- Operação de venda, atendimento ou produção está travada
- Telefone do TI está tocando sem parar
- Não há clareza ainda sobre a causa, só sobre o efeito
- O fornecedor ou time interno foi acionado mas a resposta está vaga
- O negócio está pedindo prazo e você ainda não tem como dar
Os primeiros minutos: estabilizar antes de explicar
Nos primeiros minutos, o erro mais comum é tentar entender a causa antes de dimensionar o estrago. Inverta: dimensione primeiro (quem está afetado, qual processo parou, desde quando), acione segundo (com a severidade correta e canal certo), comunique terceiro (mensagem única ao negócio com próximo prazo). A causa raiz fica para o RCA — agora o objetivo é restaurar serviço.
- Confirme o escopo real. Quem está afetado, quais processos param, desde quando, qual a abrangência (todos os usuários, uma unidade, um perfil). Sem isso, decisões são cegas.
- Classifique a severidade. Use matriz pré-acordada com o fornecedor. Sistema crítico parado raramente é severidade média — abra como alta ou crítica de cara, mesmo que precise corrigir depois.
- Acione no canal certo. Ticket aberto na severidade certa, ligação em paralelo, contato direto se houver. Ticket sozinho costuma ficar na fila.
- Monte o war room mínimo. Chamada de voz com TI, gestor da área afetada, contato do fornecedor. Centraliza decisão e elimina troca de mensagens dispersas.
- Comunique o negócio em mensagem única. O que está fora, impacto esperado, próxima atualização em X minutos. Não improvise grupos paralelos; canalize tudo por uma única mensagem oficial.
- Acione a contingência. O que pode rodar manual, qual sistema secundário absorve carga, quem precisa parar de tentar usar. Reduz pressão sobre o sistema e sobre o suporte.
- Mantenha cadência de atualização. A cada 30-60 minutos, mesmo sem novidade. Silêncio é interpretado como descontrole; atualização regular preserva confiança mesmo sem resolução.
Comunicação durante a crise
Comunicação ruim transforma incidente técnico em crise de credibilidade. Algumas regras que costumam fazer diferença: uma única voz oficial (não três grupos no WhatsApp com versões diferentes); cadência fixa (mesmo sem novidade, atualize no prazo prometido); honestidade sobre o que não sabe ("ainda investigando a causa, próxima atualização em 30 minutos" é melhor que estimativa inventada); separação entre comunicação interna (técnica, ao time afetado) e externa (negócio, ao cliente se for o caso).
Depois de restaurar: RCA que evita reincidência
Restaurar o serviço é o fim da crise imediata, não o fim do trabalho. O RCA (Root Cause Analysis) precisa acontecer enquanto a memória está fresca — idealmente dentro de uma semana. O objetivo não é encontrar culpado, é identificar a causa raiz (não apenas o sintoma) e propor ações que reduzam probabilidade ou impacto de reincidência.
Um RCA bom costuma cobrir: linha do tempo dos fatos, causa raiz identificada (e diferenciada do gatilho imediato), por que a detecção foi do tamanho que foi (mais cedo era possível?), por que a recuperação demorou o que demorou (poderia ser mais rápida?), ações para evitar reincidência (separar as que dependem de TI, fornecedor e negócio) e ações para reduzir impacto se reincidir. Documente, compartilhe com a diretoria e acompanhe a implementação das ações — RCA sem follow-up é teatro.
Tentar entender antes de dimensionar. Investigar causa enquanto se ignora escopo gera resposta proporcional à dor sentida pelo TI, não à dor sentida pelo negócio. Dimensione primeiro, sempre.
Classificar abaixo da severidade real. Por timidez ou para não escalar interno, o ticket vira severidade 2 quando deveria ser 1. O fornecedor responde no SLA da severidade aberta, não na que era a correta.
Dar prazo otimista para acalmar. Prazo inventado quebra duas vezes: na primeira quebra técnica e na perda de credibilidade. Trabalhe com "próxima atualização em X", não com "voltamos em Y".
Comunicação dispersa em vários canais. Três grupos com versões diferentes confundem mais que ausência total. Voz oficial única, cadência fixa, canal definido.
Pular o RCA porque o serviço já voltou. Sem entender causa raiz, a próxima crise repete a mesma falha. RCA é o investimento que reduz a próxima crise.
- O serviço foi validado como funcional para os principais cenários de uso
- O negócio foi avisado da normalização pela mesma voz oficial da crise
- A causa raiz preliminar está identificada (não só o gatilho)
- Há acordo sobre data e responsáveis pelo RCA
- Logs e evidências do incidente foram preservados
- Ações imediatas para reduzir reincidência (workaround, monitoramento extra) estão em curso
- O fornecedor está engajado na investigação se a causa foi do lado dele