Esse artigo foi escrito em 2017 e adaptado em julho de 2024.
A aí pessoal, tudo tranquilo e sereno?
Esse é o segundo passo de uma série de 3 cujo objetivo é apresentar perguntas e dicas e descrever algumas técnicas utilizadas no dia a dia de trabalho de um troubleshooter.
Na publicação anterior, introduzimos um cenário base que é bem familiar aos profissionais diretamente relacionados com troubleshootings em ambientes computacionais complexos e falei um pouco da postura que EU (aqui a caixa alta é necessária) particularmente acredito ser mais adequada a situação.
Pra resumir, o cenário trata-se de um problema X acontecendo num ambiente crítico, com vários profissionais estão há Y horas fazendo análises, coletando logs, lendo traces e ainda assim muito longe de uma solução. Antes de uma reação mais drástica, mais um profissional é escalado para entrar no circuito com o objetivo de lançar alguma luz sobre a problema: O troubleshooter.
Supondo que você é o profissional recém escalado (troubleshooter), que agora tem o apoio dos seus colegas e foi dado a você a palavra pra levantar hipóteses sobre as possíveis soluções para o problema, qual seria o segundo passo?
Troubleshooting – O segundo passo – Perguntas
Bem, você já sabe que o problema não é usual, pois se fosse, talvez nem tivesse chegado até você.
Portanto, quais as perguntas chave que precisarão sei feitas agora e como usar essas informações pra traçar um linha de investigação?
- Você precisa de um breve histórico do problema. Peça ao organizador da frente de investigação – sempre há um – pra ajudar nesse ponto. Aqui, ser breve é importante para ganhar tempo.
- Tente anotar tudo que for importante para determinar uma linha de investigação. Por exemplo: Data de Releases ou instalações de patch; Se houve mudanças programadas no ambiente; Quando foram documentadas as primeiras notícias do problema; Características básicas do funcionamento dos produtos relacionados ao problema, caso você não seja especialista no produto. Esses marcos temporais, ajudam e muito a identificar o período no tempo onde devemos focar nossa atenção.
- Puxe pela memória, pois sempre existe uma pequena chance do mesmo problema já ter acontecido em algum outro cliente ou, no mesmo cliente mas há muito tempo atrás.
- É importante saber onde o problema “explode” e como ele foi percebido. Ex.: Um erro na tela de uma aplicação? Um componente batch crashando? Erro de dados causando inconsistências na base?
De posse dessas informações, já é possível fazer um recorte e, num primeiro momento, reduzir as possibilidades pro início dos trabalhos. Vejamos um exemplo fictício:
“O problema começou, com pouco recorrência e escala, logo após uma mudança programada no SOA que ocorreu na última madrugada quando os usuários da aplicação XPTO não conseguiam efetuar uma operação dentro de um fluxo de negócio que acessa a aplicação YXZ via SOA. Como o problema não afetava a operação de forma generalizada, optou-se por investigar o cenário com mais calma e corrigir o problema numa futura mudança.
Entretanto, foi percebido uma intensidade maior de erros, inviabilizando a execução dessa funcionalidade logo após as 11 horas da manhã do dia seguinte a mudança.
O que se sabe sobre a mudança é que, além de mudança no serviço do SOA, foram feitas adaptações nos serviços de saída da aplicação XPTO e entrada da aplicação YXZ.
Apesar do erro na aplicação XPTO aparentar ser decorrente do processo de integração, a equipe do SOA não localizou erros nos logs das integrações dos serviços feitos e a aplicação YXZ também não aparenta nenhum erro.
Por volta das 13 horas, o time de TI decidiu pelo rollback da mudança, pois seria necessário apenas limpar os caches das aplicações (XPTO, XYZ e SOA) não sendo exigido restart de serviços, ou seja, risco baixo sem indisponibilidade.
O problema é que, mesmo após o rollback das mudanças feitas na madrugada, o erro continuou explodindo na tela mas apenas em cerca de 20% das operações e de forma aparentemente intermitente.
O próximo passo do time de TI é baixar os serviços causando indisponibilidade e consequente perda de receitas a companhia, além de afetar os indicadores de qualidade dos ambientes. Precisariam ser baixados 5 servidores de aplicação da aplicação XPTO, 3 servidores da aplicação YXZ e 3 servidores do SOA.”
Como exercício, deixo aqui a seguinte pergunta no ar:
Onde provavelmente está o problema e qual seria o próximo passo pra testar se seu palpite está certo?
Dicas
O objetivo é identificar e resolver o problema com o menor impacto possível.
Por que entre a madrugada e as 11 horas da manhã o erro acontecia em menor escala? Seria a carga de trabalho um influenciador do problema? Alguma engine relacionada ao fluxo estava sendo alimentada, como um cache, por exemplo? Ambas as possibilidades?
Por que após o rollback das customizações o erro continuou acontecendo de forma intermitente? (Obs.: Não existe erro intermitente, você apenas não descobriu o padrão!)
Porque cerca de 20% das transações continuam apresentando erro mesmo após o rollback?
Aguardo os comentários e dou minhas impressões – viciadas, claro, pois fui eu quem inventou o cenário base – no último artigo dessa série de 3.
Abraço