Depuração de código com abordagem forense
Quando o sistema entra em colapso sem mensagem de erro clara, o que importa não é adivinhação. É reconstrução. Eu chamo isso de code murder mystery porque funciona assim: o código foi executado, algo morreu no meio do caminho, e cabe a você descobrir o quê, onde e por quê. A diferença entre resolver e ficar rodando em círculos está em como você coleta evidências. Comecei a fazer isso na prática depois de gastar três diasando um deadlock que só aparecia em produção, sob carga específica, e nunca em qualquer ambiente de teste. O problema era que o comportamento só se manifestava quando dois workers processavam certos arquivos simultaneamente, e o log padrão não registrava o estado dos locks. Eu precisava de visibilidade real do que acontecia nos momentos críticos.
Entendendo o code murder mystery na prática
O conceito não tem nada a ver com programação criminosa. Refere-se a uma metodologia estruturada de investigação de bugs que surgem sem aviso prévio. Você trata o sistema como uma cena de crime: há rastros, há testemunhas (logs, métricas, traces), e há um culpado (código, configuração, concorrência). O trabalho é coletar provas antes que elas sejam sobrescritas. A parte mais importante que ninguém menciona é o timestamp. Logs sem fuso horário consistente são inúteis para investigação. Eu passei duas semanas lidando com um problema que parecia aleatório até perceber que os timestamps estavam em três fusos diferentes. O bug só ocorria numa janela de 47 segundos que cruzava fusos. Depois de normalizar tudo para UTC, a reproducible path ficou óbvia em 20 minutos.
Método de investigação passo a passo
O primeiro passo é isolar o que você tem. Logs brutos, stack traces, dumps de memória, métricas de performance, estado do banco, requisições pendentes. Colete tudo antes de qualquer tentativa de reparo. Eu já vi desenvolvedores aplicarem hotfixes antes de terminar a coleta, e ai as evidências somem para sempre. Segundo, documente o estado conhecido. Anote o que funcionava antes e o que parou de funcionar. Qual foi a última mudança no deploy? Qual versão do runtime estava rodando? Isso elimina variáveis desnecessárias. Na maioria das vezes, a resposta já está aí, mas ninguém anota.
Terceiro, reproduza com consciência. Não tente reproduzir apenas para confirmar que o bug existe. Reproduza medindo. Quanto tempo dura o erro? Quantos usuários são afetados? Qual a frequência? Essas métricas definem a severidade e guiam a priorização. Um bug que mata 2% das requisições e demora 3 segundos para manifestar é diferente de um que crasha o processo inteiro em 10 minutos.
Vieses comuns que atrapalham a investigação
O viés de confirmação é o maior inimigo. Quando você acha que encontrou o culpado, tende a ignorar evidências que contradizem essa teoria. Eu caí nessa armadilha durante seis horas investigando um problema de memória. Eu tinha certeza que era vazamento de heap. Todo log parecia confirmar. Só quando alguém apontou que o garbage collector estava coletando normalmente que eu percebi: o problema era fragmentação de paginação, não volume de alocação. O outro viés é o da mudança recente. Desenvolvedores tendem a culpar o último commit automaticamente. Às vezes é legítimo, às vezes não. Eu encontrei um bug que apareceu semanas depois de uma atualização de biblioteca. O problema não estava no código novo, mas num behavior regressivo de uma dependência transitiva que ninguém mais observava. A "mudança recente" era apenas o gatilho, não a causa raiz.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Ferramentas que fazem diferença
Para investigação em tempo real, strace e wireshark continuam sendo indispensáveis. Eu uso strace para rastrear system calls de processos problemáticos e wireshark para capturar tráfego de rede que pode revelar timeouts ou respostas malformadas. Juntos, eles cobrem os dois lados mais importantes: o que o processo faz e o que ele recebe. Dumps de memória com gdb ou jmap (dependendo da linguagem) dão visibilidade do estado exato do runtime no momento do crash. Eu já resolvi problemas que pareciam impossíveis apenas analisando o stack trace de um dump. O processo estava rodando há 47 horas, com pilhas de execução acumuladas de requisições antigas que nunca eram finalizadas.
Para monitoramento contínuo, Prometheus com alertas bem calibrados evita que você descubra problemas apenas quando o usuário reclamou. Métricas de latência p99, taxa de erro, throughput, e resource usage devem ser observáveis em dashboards que você consulta rotineiramente, não apenas quando surge emergência.
Limitações que precisam ser aceitas
Code murder mystery não resolve tudo. Em sistemas distribuídos, às vezes a causa raiz está em múltiplos nós, e isolar cada um leva tempo que o negócio não tem. Você precisa aceitar que nem todo bug tem solução rápida, e que às vezes a resposta correta é conter o dano e investigar depois. O método também depende da qualidade dos logs. Se o sistema não gera logs estruturados com contexto suficiente (request id, trace id, timestamps consistentes), a investigação fica muito mais difícil. Eu já vi equipes tentarem investigar problemas em sistemas com logs que não continham nem o método HTTP da requisição. Isso é inaceitável e precisa ser corrigido antes de qualquer investigação séria.
Outra limitação é a perda de evidências com restart. Se o processo morre e restarta automaticamente, o estado anterior some. Soluções como crash dumps persistentes e core dump em disco ajudam, mas nem sempre estão configurados. Verifique se seu ambiente preserva evidências antes de precisar delas.
Quando desistir e chamar suporte
Existem cenários onde a investigação interna não vale o custo. Se o problema envolve infraestrutura de terceiros (CDNs, provedores de banco, APIs externas), e você já coletou todas as evidências relevantes, documente tudo e abra ticket. Tempo gasto tentando debugar problema de DNS externo é tempo desperdiçado. Também considere escalar quando o bug afeta mais de 30% dos usuários e o impacto no negócio é imediato. Nesses casos, rollback e monitoramento ativo são mais válidos que investigação profunda em tempo real. Você pode voltar ao problema depois, com dados coletados durante o incidente.
A regra prática que eu sigo é: investigue até o ponto em que novas evidências não mudam a probabilidade da hipótese atual. Se você já rodou três ciclos completos de coleta-análise-teoria-teste e todas apontam para a mesma direção, pare e decida. Mais investigação só gera paralisia por análise.
