Analisando o que pode ter acontecido em incidentes de sistema
A gente finalmente para pra investigar um problema quando ele já virou crise. O momento certo seria antes, é claro, mas raramente é assim na prática. Quando o serviço cai ou um dado importante some, a primeira reação costuma ser culpar a rede, o banco, o deploy mais recente. A verdade é que quase nenhuma dessas suposições resiste a uma análise minimamente rigorosa.
O que pode ter acontecido: o primeiro passo que ninguém gosta de dar
A expressão soa vaga de propósito. "O que pode ter acontecido" é basicamente o ponto de partida de qualquer investigação séria. Antes de gastar horas caçando logs em horários errados, você precisa mapear o território. Anote o que mudou nos últimos 48 horas — e "mudou" aqui inclui atualizações de dependência, rodízio de credenciais, alteração de firewall, migração de DNS, qualquer coisa que um desenvolvedor fez sem avisar o time de infraestrutura. Eu vi um caso reciente em que um timer CRON tinha sido movido de um container para uma VM nova durante um trabalho de limpeza que o pessoal chamava de "otimização". O job rodava, mas escrevia em um path que não existia mais. Perdi duas horas seguindo trilhas erradas antes de perceber que o log de alterações de configuração estava em um diretório esquecido. O sintoma era falha intermitente; a causa real era um path quebrado que só falhava quando o arquivo gerado tinha mais de 50MB.
O que você precisa fazer antes de abrir qualquer ferramenta de monitoramento: escrever em um pedaço de papel (ou num doc simples) os pontos de interrogação. Lista de três a cinco perguntas que precisam ser respondidas. Se você não consegue formular a pergunta, não sabe exatamente o que está procurando, e vai perder tempo navegando por dashboards que não ajudam em nada. Existem padrões recorrentes que parecem óbvios quando aparecem. Deploy com variável de ambiente faltando. Rotação de certificados sem renovação. Configuração de timezone divergente entre app e banco. Conexão de rede sendo cortada por regra de segurança atualizada sem documentação. Todo esses sintomas começam como "algo estranho tá acontecendo" e só se tornam investigáveis quando você para de chutar e começa a registrar.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Uma coisa que iniciantes sempre esquecem: o problema raramente é o que você vê primeiro. O serviço que falha geralmente é a vítima, não a causa. Um erro de timeout no frontend pode ser causador por um pool de conexões esgotado no backend, que por sua vez pode ser resultado de uma query mal formada que começou a rodar depois de uma migração de esquema. Seguir a cadeia de dependência até a raiz é chato e demorado. É o que separa um diagnóstico rápido de uma madrugada inteira sem solução. Uma limitação importante dessa abordagem: ela depende de logs que realmente existem. Muitos times operam com instrumentação rasa, sem trace ID, sem correlação entre serviços, sem retenção adequada. Nesse cenário, a investigação vira caça ao tesouro e o mais provável é que a causa raiz se perca com o tempo de retenção dos logs. A solução não é mágica — é implementar pelo menos logging estruturado com campos mínimos de correlação antes do próximo incidente. Mas todo mundo sabe que isso só é prioridade depois que algo quebra feio.
Quando consigo rastrear o que pode ter acontecido até um ponto concreto, o próximo passo é sempre a validação. Reproduzir em ambiente isolado, mesmo que de forma simplificada. Se você não consegue reproduzir, não tem certeza de que encontrou a causa real. Pode ser que o problema seja estatístico, pode depender de uma condição de corrida específica, pode ser triggered por carga que você não mediu. Reproduzir força você a confirmar que a causa identificada é de fato a causa, e não apenas um fator presente no momento da falha. O método que funciona na prática é simples e quase ninguém aplica com disciplina: registrar tudo enquanto investiga, atualizar a lista de hipóteses a cada nova descoberta, descartar explicitamente o que foi testado e reprovado. O erro mais comum é voltar pra mesma verificação três vezes porque não foi anotado que já tinha sido checada. Isso acontece muito em equipes grandes onde várias pessoas entram no chamado simultaneamente.
Se você tá começando a investigar algo agora, abra um documento, cole a linha do tempo dos eventos, liste as hipóteses com grau de confiança, e anote o que cada teste mostrou. Daqui a duas horas, quando a cabeça estiver pesada, você vai agradecer por não precisar reconstruir tudo da memória. O que pode ter acontecido fica mais claro conforme os dados se acumulam, não quando você passa mais tempo olhando fixo pra tela.
