O que 4 anos configurando redes na Oi me ensinou sobre debug
Debug de software e debug de rede são a mesma coisa. Aprendi isso antes de saber programar, e isso me deu uma vantagem que levei anos para nomear.
Eu tinha um método para consertar rede que aprendi na Oi Telecomunicações.
Não aprendi em curso. Aprendi errando, na frente do cliente, com prazo de 2 horas e nenhuma documentação disponível.
O método era simples: não acredite no sintoma. Vá na causa.
Parece óbvio. Não é. A maioria das pessoas — eu incluído no começo — vai direto para o lugar mais óbvio. Cabo solto? Testa o cabo. Router travado? Reinicia o router. Funciona às vezes. Mascara o problema nas outras.
Recebi chamado de um cliente: "internet cai toda segunda-feira de manhã, sem exceção."
Primeira hipótese: problema no provedor. Liguei pro suporte da Oi. Nada registrado. Segunda: problema no roteador. Reinicia o roteador na segunda de manhã. Na semana seguinte, caiu de novo.
Terceira hipótese: algo diferente acontece nas segundas de manhã. Fui até o escritório, fiquei lá na segunda. Observei. Às 8h30, o backup automático dos computadores rodava. Todos ao mesmo tempo. Saturava o link. Não era problema de rede. Era problema de configuração de agendamento de backup.
O sintoma era "internet lenta". A causa estava a 3 camadas de distância do sintoma.
Quando seu sistema retorna 500, o problema raramente está onde o erro aparece. O erro aparece no controller. O problema pode estar no banco de dados, na conexão com serviço externo, numa race condition, numa variável de ambiente que sumiu no deploy.
O método de debugging que uso hoje é o mesmo que aprendi com rede: primeiro, reproduza o problema de forma consistente — se você não consegue reproduzir, você não entende o problema ainda. Depois, isole o escopo — qual é a menor coisa que precisa acontecer para o bug aparecer? Remove tudo que não é necessário. Terceiro, questione suas suposições — "a função X sempre retorna lista não-vazia": você tem certeza? Testou em todos os casos? E por último, camada por camada — divide o fluxo, encontra a fronteira entre "funciona" e "não funciona". O bug mora nessa fronteira.
Quando você debugga rede, você tem ferramentas que mostram exatamente o que está passando: ping, traceroute, tcpdump, netstat. Tudo observável. O pacote saiu? Chegou? Em quanto tempo? Por qual caminho?
Software tem equivalentes: logs, traces, métricas, breakpoints. O problema é que a maioria dos devs não usa essas ferramentas com a mesma sistematicidade que um engenheiro de redes usa as dele. Quando um engenheiro de redes vê problema, a primeira coisa que faz é observar, não tentar corrigir. Captura tráfego. Lê os logs do roteador. Entende o que está acontecendo antes de mexer em qualquer coisa.
Software é igual. Antes de mudar código, entenda o que está acontecendo.
Depois de resolver centenas de problemas, você desenvolve intuição sobre onde os problemas moram. Em rede, eu sabia que problemas intermitentes geralmente eram hardware, não configuração. Em software, você começa a desenvolver padrões parecidos: performance lenta depois de deploy provavelmente é query sem índice, erro 503 esporádico provavelmente é timeout com serviço downstream, memory leak gradual provavelmente é algo não sendo liberado num loop.
Essa intuição vem de acumular casos resolvidos. Não tem atalho. Mas você pode acelerar sendo intencional: quando você resolve um bug, documenta o que foi, o que levou a encontrar, e o que você teria feito diferente. Esse hábito compõe.
Essa semana: na próxima vez que você encontrar um bug, antes de mexer em qualquer coisa, escreve numa linha o que você acha que é o problema. Depois investiga. Depois compara o que você achou com o que era. A diferença entre esses dois é onde seu modelo mental do sistema precisa melhorar.