O dia a dia de um profissional de TI na área de Sysadmin, DevOps, SRE ou em times de engenharia como são chamados os técnicos, todos tem uma função, resolver problemas. Alguns problemas são simples, outros complexos, uns pequenos e outros grandes e outros beeeeem grandes, alguns vão vir do além, mas independente do tamanho, origem e complexidade o seu trabalho será resolver problemas.

Calma, calma, calma, jovem!! Não se assuste e nem desista sem ouvir e tentar algumas dicas que podem tornar a sua vida mais fácil.. menos difícil eu diria 😜. Você precisa saber que existem técnicas para resolução de problemas. Você vai precisar estudar e aprender como algumas coisas funcionam de forma simples, básica, avançada e super avançada.

Você vai precisar conhecer os comandos de Linux/Unix para fazer “perguntas” ao sistema operacional e entender as respostas. Você vai precisar saber filtrar, ordenar, organizar em colunas, saber buscar palavras ou trechos de texto dentro arquivos de logs armazenados ou streaming de logs.

O modelo de pensamento de um Sysadmin

Para mim, essa imagem traduz de forma cristalina o pensamento de um sysadmin na hora de resolver problemas. Quando me deparo com um problema minha inteligência racional cria esse fluxo dentro da minha cabeça. Dependendo da resposta eu saco da minha caixa de ferramenta o WD-40 ou um rolo de Silver tape.

A imagem começa com uma pergunta. “Does it move?” as respostas possíveis são “Yes” ou “No”. Com isso você tem 50% de chances de ir para um lado e 50% de chances de ir para o outro. Ao fazer uma escolha você já eliminou metade das possibilidades, agora você está lidando com metade das possibilidades.

Uma segunda pergunta é feita “Should it?”, mais uma vez, as respostas possíveis são “Yes” ou “No”. Ao dar mais uma resposta, neste momento você acaba de eliminar 75% das probabilidades de soluções e agora você está trabalhando com apenas 25% das possibilidades do seu universo iniciali, não é d+?!?!.

Meu jovem, não vai pensando que eu realmente tenho uma lata de WD-40 e um rolo de Silver tape debaixo da minha mesa, por que eu não tenho 🙂, a imagem é apenas uma alegoria para ilustrar como mentalmente usamos um algoritmo chamado de busca binária na resolução de problemas e sem se dar conta que estamos aplicando uma das melhores técnicas de troubleshooting para encontrar e delimitar o problema, mas isso não é tudo, tem mais..

Técnicas de troubleshooting

Já que o problema está delimitado agora é hora de resolve-lo. Uma vez o Secretário de Defesa dos EUA Donald Rumsfeld disse numa entrevista há “…relatórios que dizem que algo não aconteceu são sempre interessantes para mim, porque, como sabemos, existem informações conhecidas; Há coisas que sabemos que sabemos. Também sabemos que existem incógnitas conhecidas; isto é, sabemos que há algumas coisas que não sabemos. Mas também existem incógnitas desconhecidas - aquelas que não sabemos que não sabemos…” páááaaHH!! Agora pense aeee por alguns segundos meu jovem!!!

Num processo de “troubleshooting” você vai lidar exatamente com isso, algumas coisas você sabe, outras você acha que sabe outras tantas você descobre que nem sabia que não sabia. Felizmente existem fórmulas que muitas vezes ajuda a resolver o problemas, são métodos que envolvem algumas etapas, incluindo a formulação de algumas hipóteses e a realização de testes, muitos testes para confirmar ou refutar essas hipóteses, vejam como funciona alguns deles:

Testando um Hipóteses

Essa é uma técnica usada quando você não sabe o porque algo não funciona, ou o porque algo não funciona da forma que se espera e se tem poucos ou nenhum elemento que faça sentido, vejamos:

1. Identificação do Problema: O primeiro passo no processo de “troubleshooting” é identificar claramente qual é o problema. Isso envolve coletar informações detalhadas sobre os sintomas, erros ou comportamentos anormais que estão ocorrendo.

2. Análise e Investigação: Uma vez que o problema tenha sido identificado, começa a análise e investigação. Isso pode incluir examinar registros, logs, mensagens de erro, configurações e outras fontes de informações relevantes para entender melhor a situação.

3. Formulação de Hipóteses: Com base nas informações coletadas na etapa de análise, você pode começar a formular hipóteses sobre as possíveis causas do problema. As hipóteses são suposições as vezes realísticas as vezes não 🙂 sobre o que poderia estar causando o problema. Por exemplo, se um site não estiver carregando, uma hipótese poderia ser que há um problema com o servidor web mas pode ser também o DNS ou o firewall ou a conta da API que não foi paga.

4. Priorização de Hipóteses: Nem todas as hipóteses são igualmente prováveis. Você deve priorizar as hipóteses com base em sua experiência, probabilidade e na informação disponível. Comece pelas hipóteses mais plausíveis ou mais fáceis de testar e coloque numa tabela simples com três colunas: Hipóteses, Teste e Resultado.

5. Testes e Experimentação: A próxima etapa envolve projetar e realizar testes para confirmar ou refutar cada uma das hipóteses prioritárias. Isso pode incluir a realização de ações específicas, como ajustar configurações, reiniciar sistemas, aplicar patches, entre outras, dependendo da hipótese.

6. Coleta de Dados: Enquanto realiza os testes, é importante coletar dados e informações relevantes. Lembra da tabela do passo 4? É lá que você vai guardar essas informações. Isso pode incluir registros, métricas de desempenho, resultados de testes e qualquer outra informação que possa ser útil para avaliar o impacto das ações realizadas.

7. Análise dos Resultados: Após realizar os testes, compare os resultados obtidos com as hipóteses formuladas. Isso ajudará a determinar se uma hipótese específica é verdadeira ou falsa. Se uma hipótese for confirmada, você estará mais próximo de resolver o problema. Se for refutada, você pode descartar essa possibilidade e se concentrar em outras hipóteses.

8. Iteração e Refinamento: O processo de “troubleshooting” muitas vezes requer iterações. Se uma hipótese não for confirmada, volte para a etapa de formulação de hipóteses e repense as possíveis causas do problema com base nos resultados dos testes anteriores.

9. Resolução e Documentação: Uma vez que uma hipótese seja confirmada e o problema seja resolvido, documente os passos que você tomou para resolver o problema. Isso pode ser útil para referência futura e também para compartilhar conhecimento com outras pessoas que possam enfrentar problemas semelhantes. No ITIL o local para isso é o ticket de problema, mas você pode e deve também compartilhar isso com as pessoas do seu time numa reunião semanal.

10. Não esquecer de fazer: Uma vez solucionado você deve aplicar a solução na sua ferramenta de infra-as-code e replicar a solução EM TODOS os seus ambientes de teste 😘 #ficadica

Lembre-se de que o troubleshooting é um processo sistemático e requer paciência e diligência. Nem sempre a primeira hipótese é a correta, portanto, estar disposto a explorar várias possibilidades é essencial para resolver problemas não desanime se as primeiras tentativas não resultarem em nada, siga firme testando outras hipótese 😘.

Top down

Essa é uma técnica que eu uso quando eu já tenho uma certa familiaridade com os componentes do projeto e com certos fluxos da arquitetura. Eu sigo o fluxo de um request como se fosse uma requisição de um usuário qualquer solicitando alguma coisa à plataforma. Veja como seria isso num desenho de arquitetura web super clássico.

Bottom up

Essa é uma técnica que eu uso quando estou perto de finalizar algum projeto e coisas não funcionam de forma correta. Eu sigo o fluxo como se fosse uma construção de um prédio, e vou testando tijolo por tijolo. As informações precisam vir de algum lugar, em geral é uma fonte de dados. Você precisar pedir esse dado na fonte e acompanhar suas tranformações em cada camada da aplicação.

Top down & Bottom up

Vão existir momentos que você vai saber que esse tipo de problema só pode existir entre os componentes X e Y ou entre os componentes XPTO e XPTY, para esses momentos você deve combinar as técnicas Top down e Bottom up com a busca binária. Ache um ponto de corte, exclua as coisas que você que já sabe funcionam e siga para onde você acredita que de ser o problema.

Técnicas de troubleshooting na prática

O que vimos até agora foram algumas estratégias de como abordar os problemas mas e na prática como funciona? Na prática a primeira coisa que eu te recomendo é “use Linux” e qual versão? Use a versão mais nova da distribuição que você mais gostar.

Minha segunda recomendação sempre use o modo texto, aprenda a usar bem, bem, bem, bem mesmo!!! É no modo texto onde estão as melhores ferramentas e comandos de teste, validação, comparação, filtro de texto, soma de números, programação está tudo lá!!!

Em modo texto

O modo texto não é só para os hackers de Hollywood não, é uma ferramenta de trabalho para você, portanto aqui vai uma mais uma dica, estude, treine, estude, treine, treine para se sentir confortável para fazer as seguintes coisas: Ler logs e streaming de logs com cat, zcat; Aprenda filtrar logs com grep , egrep ou egrep -v; Aprenda a comparar arquivos com 5 mil linhas em modo texto com o diff ou vimdiff. Você vai precisar saber testar conectividades entre pontos A e B com ping, telnet, nc e curl. Você vai precisar organizar e filtrar dados em colunas com awk ou com sort, sort -u ou sort -r.

Imagine que você tem duas máquinas e precisa ter certeza que dois arquivos de texto com 1GB de tamanho cada são idênticos, como fazer isso? Você poderia ler linha por linha? Claro que pode. Você vai abrir o Word e comparar linha por linha? Se for possível abrir um Word no servidor claro que pode também (gentyy!! Por favor, não é pra ter Word no servidor, é sério!!). Mas você vai gastar umas boas horas nisso. Lembre-se jovem, você quer saber se os arquivos são idênticos e não achar a diferença. Uma alternativa beeeeem mais rápida é verificar a assinatura md5sum dos arquivos. Se o resultado bater você pode falar com toda certeza, “os arquivos são iguais”!!

Esses são alguns um dos vários macetes que você precisa ter em seu cinto de utilidades. E como eu aprendo esse tal de modo texto? Bem… estudando, faça alguns cursos de shell e depois conheça cada comando da Imagem 06, isso já será um bom início. Se envolva com as resoluções de problemas com as pessoas mais experientes do seu time, faça perguntas, esse é o caminho para aprender.

Resumo

Fazer troubleshooting é uma técnica que pode ser aprendida, não existe um curso específico para isso, mas você vai aprendendo com os problemas do dia a dia. Como aprender então? É necessário perguntar. É necessário trabalhar em conjunto com as pessoas que estão há mais tempo na área. Precisa estudar e aprender como as coisas funcionam.

Precisa saber testar as coisas conforme diz o manual e de formas que não está dito no manual. Precisa testar para ver que às vezes algumas coisas não funcionam conforme o manual e saber que a documentação de um software pode estar incompleta ou errada. O caminho é longo jovem, mas te granto que é gratificante.

Nesses caminhos profissionais que eu tenho percorrido eu diria que conheci umas cinco ou seis pessoas que realmente estavam bem acima de qualquer média nessas habilidades, eles realmente desafiavam a gravidade em termos de conhecimentos Linux, Unix, redes e em técnicas de troubleshooting. O que elas tinham de tão especial? As características mais marcante dentre elas era a humildade em compartilhar seus conhecimentos e o desejo genuíno de conversar sobre um problema e suas possibilidades de solução. Eu também diria que eram pessoas extremamente curiosas e estudiosas, interessadas em saber como as coisas funcionam.

Por fim, quando eu digo que um Especialista tem que resolver problemas do além não é exagero da minha parte!! Faço uma homenagem ao maior troubleshooter de todos os tempos!! Vejam como se resolve um problema. Percebam a abordagem ao problema. Percebam a árvore binária sendo construída e sendo explorada. Percebam o fluxo da criação das hipóteses, teste de cada hipótese e validação do resultado. Ao final chega-se a solução do problema!!! ❤️ 😎

Abraços!

Vida longa e próspera a todos!!

DICA RÁPIDA DE LIVRO

Estou lendo atualmente o livro Flow: A psicologia do alto desempenho e da felicidade

Referências

• https://www.brendangregg.com
• Donald Rumsfeld https://www.youtube.com/watch?v=GiPe1OiKQuk
• Systems Performance: Enterprise and the Cloud
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/pdf/system_administrators_guide/red_hat_enterprise_linux-7-system_administrators_guide-en-us.pdf
• https://www.ibm.com/docs/en/linux-on-z?topic=guide-current-version
• Dica de livro Flow: A psicologia do alto desempenho e da felicidade

MENTORIA

Curtiu o blog? Quer trocar uma ideia comigo sobre algum post?

Marca Aqui! É um papo gratuito oferecido para quem é leitor do blog, podemos falar de temas como: DevOps, SRE e carreira em TI.

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- --- As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.