Esse artigo foi escrito em 2017 e adaptado em julho de 2024.
A aí pessoal, tudo tranquilo e sereno?
Esse é o terceiro e último artigo de uma série de 3 cujo objetivo é descrever algumas técnicas utilizadas para troubleshooting. Aqui falo sobre minhas impressões sobre o problema narrado no primeiro artigo dessa série.
Já no segundo artigo dessa série, inventei um cenário hipotéticoe, apesar da nossa vida profissional já nos exigir tanto, deixei para uma pergunta no ar:
Onde provavelmente está o problema e qual seria o próximo passo pra testar se seu palpite está certo?
Troubleshooting – Impressões sobre o Problema
Um problema que começa em pequena escala e vai crescendo ao longo do tempo, como um vilão de filme de terror que primeiro só faz barulhinhos na casa e depois aparece com uma serra elétrica, geralmente está relacionado a dois grandes suspeitos: a carga do ambiente (CPU, memória, I/O, sessões concorrentes, etc.) ou alguma característica específica do produto, como um cache que resolveu “guardar rancor”.
No nosso caso, como os padrões anormais de consumo de recursos são relativamente fáceis de identificar (basta olhar os gráficos de monitoramento e ver se algo está gritando “SOCORRO” em vermelho) e não foram mencionados, podemos descartar essa hipótese por enquanto. Então, o que sobra? Provavelmente, o erro original estava acontecendo com mais frequência à medida que alguma informação decorrente da customização problemática “subia” pro cache da aplicação XPTO. É como se o cache estivesse dizendo: “Tá bom, vou guardar isso aqui, mas não garanto que vou devolver bonitinho depois”.
Após o rollback das customizações e a limpeza dos caches das aplicações (um clássico “limpa tudo e reza”), apenas 20% das transações continuaram apresentando erro. Isso já é um baita progresso, mas ainda tem um resquício de problema rondando o ambiente, como aquele restinho de café que fica na xícara e você só percebe quando vai lavar.
Agora, vamos pensar juntos: a aplicação XPTO possui 5 servidores. Se um deles não tivesse tido o cache limpo corretamente (ou se o cara que fez o procedimento deu um “Ctrl+C, Ctrl+V” no comando errado), teríamos exatos 20% de chances de problemas. Coincidência? Eu acho que não. Isso é praticamente um recado do universo dizendo: “Ei, olha esse servidor aqui, ele tá de birra!”.
Portanto, conforme prometido no segundo artigo dessa série, minha primeira impressão seria que um dos servidores da aplicação XPTO ficou com o cache “zicado” após o rollback da release problemática. Ao invés de reiniciar todos os servidores de todas as 3 aplicações (o que seria como usar uma bazuca pra matar uma formiga), um restart apenas no servidor que está gerando o erro seria meu palpite pra resolver o problema residual do ambiente. Afinal, troubleshooting é como ser detetive: você não precisa revistar a cidade inteira, só o suspeito mais provável.
Troubleshooting Indo Além: Como Confirmar o Suspeito?
Mas, como todo bom detetive, a gente não pode sair acusando sem provas. Então, como confirmar que o problema está mesmo em um servidor específico? Aqui vão algumas dicas práticas pra colocar no seu kit de investigação para troubleshootings:
Logs, logs e mais logs: Dê uma olhada nos logs de cada servidor da aplicação XPTO. Procure por mensagens de erro ou warnings que indiquem problemas de cache ou falhas na sincronização pós-rollback. Se um servidor estiver com o cache “preso no passado”, os logs vão gritar isso.
Monitoramento de Transações: Use uma ferramenta de APM (Application Performance Monitoring) ou até mesmo um script caseiro pra identificar qual servidor está processando as transações com erro. Se 20% das transações falham e todas passam pelo mesmo servidor, bingo! Achamos o culpado.
Teste de Carga Isolado: Que tal direcionar um pequeno volume de transações só pro servidor suspeito e ver se o erro se reproduz? É como fazer um teste de DNA no suspeito: se der match, não tem como negar.
Validação do Cache: Se a aplicação XPTO tem um mecanismo pra verificar o estado do cache (muitas têm um endpoint ou comando pra isso), use-o pra comparar os servidores. Um cache “zicado” geralmente tem dados inconsistentes ou desatualizados. É tipo comparar um caderno de anotações organizado com um que foi rabiscado por uma criança de 3 anos.
Prevenção: Porque Prevenir é Melhor que Remediar
Depois de resolver o problema, que tal evitar que ele volte a acontecer? Aqui vão algumas ideias pra blindar seu ambiente contra caches rebeldes e rollbacks mal-sucedidos:
Automatize a Limpeza de Cache: Crie scripts ou use ferramentas de automação pra garantir que todos os servidores tenham o cache limpo de forma consistente. Nada de contar com o “eu acho que cliquei em todos” do estagiário.
Documente os Procedimentos de Rollback: Um checklist claro e revisado por mais de uma pessoa pode evitar que um passo seja esquecido. É tipo receita de bolo: se pular a parte de “pré-aquecer o forno”, o bolo não cresce.
Monitoramento Proativo: Configure alertas pra identificar problemas de cache ou desempenho antes que eles virem um tsunami. Um alerta na hora certa pode salvar sua noite de sono (e seu plantão de fim de semana).
O Mistério do Cache Zicado – Minhas Impressões sobre o Problema
No fim das contas, troubleshooting é uma mistura de ciência, arte e um pouquinho de sorte. No caso da aplicação XPTO, tudo aponta pro cache de um dos servidores que resolveu fazer birra pós-rollback. Com um restart estratégico e uma boa dose de investigação, acredito que os 20% de erros vão virar história pra contar no happy hour da TI: “Lembra daquela vez que um servidor quase acabou com a gente por causa de um cache teimoso?”.
Se você tiver mais dúvidas ou quiser aprofundar em algum ponto (tipo como configurar um monitoramento de cache ou exemplos de ferramentas de APM), é só pedir. Tô aqui pra ajudar!
Abraço e boa caçada aos bugs!
