O que eu entendo sobre chamados de deus na prática
Muita gente confunde a nomenclatura porque o termo não é padronizado entre os setores, mas no dia a dia de suporte técnico e gestão de TI os tipos de chamados de deus se dividem em categorias bem distintas. O nome coloquial vem do fato de que esses chamados chegam sem aviso, com urgência absoluta e normalmente fora do horário comercial. Eu já lidei com isso durante anos em ops de infraestrutura, então vou listar como eles aparecem de verdade, sem romantização.
Tipos de chamados de deus mais comuns
O primeiro tipo é o chamado de indisponibilidade crítica. Servidor cair, link de internet cortado, banco de dados retornando erro 500 para todos os usuários. Esse é o mais óbvio e também o mais perigoso se você não tiver playbooks definidos, porque todo mundo começa a entrar na mesma sala de guerra ao mesmo tempo e o caos se instala em trinta segundos. Já vi gerente, desenvolvedor e fornecedor do Data Center discutir juntos enquanto o SLA já tinha estourado há quatro minutos. O segundo tipo é o chamado de segurança ativo. Vazamento de dados, acesso não autorizado detectado, ransomware aparecendo nos logs. Esse exige uma abordagem completamente diferente porque o primeiro impulso natural é tentar resolver rápido, o que costuma destruir evidências ou espalhar a infecção. A regra prática aqui é isolar primeiro, documentar tudo, só depois investigar. Não adianta correr. Eu perdi uma janela de resposta por três horas em 2019 porque apressei o isolamento de uma VM comprometida e o malware conseguiu se propagar para dois servidores de backup antes que eu percebesse.
O terceiro tipo é o chamado de conformidade ou auditoria surpresa. Um regulador ou departamento jurídico solicita acesso imediato a logs, retenção de dados ou suspensão de um processo automatizado. Parece menos urgente, mas o prazo costuma ser de horas, não de dias. A maioria das equipes trata isso como secundário até o contador do regulador mandar um email cobrando. O quarto tipo é o chamado de integração com cliente externo. API de pagamento no ar, sistema de um parceiro estratégico fora do ar, falha em envio de NFC-e ou XML que para a operação inteira. Esse é interessante porque a pressão vem de dois lados: seu chefe quer resolver rápido e o cliente quer uma justificativa por escrito. Eu desenvolvi um template de resposta técnica padronizado que reduz o tempo médio de comunicação nesses casos de cerca de quarenta minutos para oito minutos, porque elimina a necessidade de reescrever a mesma explicação a cada novo solicitante.
Existe ainda o chamado de deus silencioso, aquele que não chega como emergência mas que, se não for resolvido nas próximas seis horas, vira emergência. Uma fila de processamento emperrada, um trabalho noturno que não terminó, um cache corrompido que só mostra efeito no dia seguinte. Esse é o mais traiçoeiro porque ninguém liga antes do prazo estourar. Recomendo monitoramento preditivo com alertas baseados em tendências, não apenas em thresholds fixos. Thresholds fixos simplesmente não funcionam nesse cenário.
Como tratar cada tipo sem perder a cabeça
A primeira coisa que eu faço, antes de qualquer análise técnica, é classificar corretamente o chamado. Errar a classificação é o erro mais caro que existe porque determina quem é chamado, qual playbook é aberto e quanto tempo o SLA leva para vencer. Se você abrir um chamado de segurança como se fosse indisponibilidade comum, vai seguir o fluxo errado e perder tempo precioso. O segundo passo é a comunicação. Um único canal oficial, preferencialmente um thread único no chat da equipe ou uma linha dedicada no sistema de tickets. Eu já vi equipes com sete canais paralelos discutindo a mesma crise e nenhuma decisão sendo documentada. Isso gera versões diferentes do mesmo problema e, quando o chamado é encerrado, ninguém consegue explicar exatamente o que foi feito.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O terceiro passo é a execução guiada por checklist, não por memória. Checklist mesmo, impresso ou em sistema, com cada ação numerada. Eu uso checklists personalizados para cada tipo de chamado de deus e reviso eles trimestralmente. O que funcionava em 2022 já estava obsoleto em 2023 por causa de mudanças na stack. Checkpoints de verificação a cada três ações ajudam a detectar desvios antes que se tornem problemas maiores. Quarto passo, e o mais negligenciado: documentação pós-crise em até vinte e quatro horas. Sem isso, o mesmo erro se repete. A documentação não precisa ser um documento formal, mas precisa conter: o que aconteceu, qual foi a causa raiz, o que funcionou, o que falhou e qual ação corretiva foi implementada. Eu vejo equipes que levam uma semana para fechar esse relatório e, no final, nunca o revisitam. O ideal é revisar esses relatórios em revisões mensais de pós-mortem.
Armadilhas que eu vi dar errado
A armadilha número um é a pressa mal direcionada. Correr para resolver é natural, mas muitas vezes a solução rápida cria um problema pior. Um reboot de emergência pode mascarar um bug de memória que vai acontecer de novo em três dias. Um workaround no firewall que abre brechas de segurança. Sempre valide a solução antes de aplicar em produção, mesmo que o tempo aperte. A armadilha número dois é a dependência de uma única pessoa. Se só um colega sabe como resolver aquele chamado específico e ele está de férias ou doente, o tempo de resolução dobra ou triplica. Documentação compartilhada e cross-training são obrigações, não luxos. Eu fiz uma política onde qualquer chiamata de deus deve ter pelo menos dois membros da equipe capazes de executá-lo, e isso reduziu meu MTTR em cerca de sessenta por cento ao longo de doze meses.
A armadilha número três é ignorar chamados de deus menores. Um chamado que parece pequeno pode ser o sintoma de algo maior. Eu já ignorei três chamados consecutivos de lentidão em um serviço específico e, na quarta vez, o sistema caiu completamente. Padrões repetidos são sinais, não ruído.
Limitações reais que ninguém admite
Chamados de deus, por definição, têm alto imprevisibilidade. Nenhuma ferramenta, por mais cara que seja, consegue prever todos os cenários. Ferramentas de monitoring reduzem o tempo de detecção, mas não eliminam a ocorrência. Playbooks reduzem o tempo de resposta, mas não evitam falhas humanas sob pressão. A redução média que eu vejo no mercado com boas práticas é de quarenta a cinquenta por cento no MTTR, o que é significativo, mas longe de perfeito. Se o seu ambiente não tem mínima maturidade de processos, implementar gestão de chamados de deus pode gerar mais atrito do que benefício nos primeiros três meses. A curva de aprendizado é real e a resistência da equipe também. Nesses casos, eu recomendo começar com treinamento básico e um único playbook bem feito antes de escalar para Anything mais complexo. Começar por tudo ao mesmo tempo geralmente resulta em nada funcionando.
Recursos práticos
Para quem quer montar uma estrutura funcional, o caminho mais direto é começar com templates de checklist e plantillas de documentação. Eu organizo os meus em repositórios internos versionados, atualizados a cada incidente relevante. Se você não tem acesso a ferramentas pagas de incident management, o Google Sheets ou Planilhas do Google funcionam perfeitamente para versionamento simples de playbooks e registro de chamados de deus com campos padrão: tipo, horário de abertura, responsável principal, ações tomadas, tempo de resolução e lições aprendidas. O essencial é tratar cada chamado de deus como oportunidade de melhoria, não como fracasso. A diferença entre uma equipe que resolve crises e uma que apenas sobrevivem a elas é a capacidade de aprender com cada evento e ajustar os processos de forma contínua.
