Se você não sabe para onde ir, qualquer caminho serve.
Lewis Carroll
O que a frase eternizada por Lewis Carroll tem em comum quando falamos de troubleshooting? Simples, se você não consegue entender a possível causa do problema, então, qualquer método para tentar soluciona-lo serve. Mas então, como elaborar um plano de ação que efetivamente funcione? É o que vamos discutir neste artigo.
Introdução
Antes de iniciarmos é importante frisar que não há um caminho certo ou errado para fazer troubleshooting, mas existe uma maneira mais eficiente e efetiva de condução que poderá lhe auxiliar durante o processo.
Durante nossa caminhada profissional vamos sempre aprendendo e desenvolvendo novas habilidades. Troubleshooting é uma delas, ao longo do tempo e com vivência em diversas situações, você irá lapidando essa importante habilidade, quanto mais situações desafiadoras você for encontrando, mais você elevará essa habilidade e como consequência sua confiança.
Forma estruturada de troubleshooting
Os problemas podem acontecer de diferentes formas, erros de configuração, atualizações de softwares, falha do hardware e etc. Independentemente do motivo da falha, podemos abordar o problema o dividindo em três simples passos.
- Problema reportado: O processo tem o início quando alguém reporta o problema, informando que algo em seu ambiente não esta funcionando como esperado.
- Diagnóstico: Essa é uma das fases mais importante, pois é aqui que você irá coletar as informações necessárias para tentar encontrar a causa do problema. Nessa etapa, podemos dividi-la em alguns passos adicionais:
- Coleta de Informações: Aqui são coletadas informações adicionais sobre o problema. Em muitas situações temos o usuário que simplesmente diz que algo não esta funcionando e não sabe repassar as informações de maneira mais precisa. Neste caso, conversar com outros usuários que estejam passando pelo mesmo problema pode ajudar a compreender um pouco mais do problema.
- Examinar as informações coletadas: De posse das informações coletadas é possível examinar o que esta ocorrendo no ambiente.
- Eliminar possíveis causas do problema: Baseado no conhecimento do ambiente e juntamente com as informações coletadas anteriormente é possível eliminar possíveis causas do problema. Aqui de fato começamos a “fazer um filtro” de onde esta a causa raiz do problema.
- Hipótese: Após eliminadas possíveis causas do problema, começamos a nos direcionar para o que consideramos ser o real motivo da falha.
- Verificar hipótese: Essa fase consiste em verificar as hipóteses levantadas no passo anterior a fim de validar se elas estão corretas ou não. Em caso negativo, voltamos à fase das hipóteses novamente.
A vantagem de se trabalhar de uma forma estruturada é que você não fica “testando as possibilidades” até encontrar o erro de forma aleatória, isso acabará por deixa-lo confuso e irá fazer com que você perca o foco no que realmente é o problema.
Lembre-se, na resolução de problemas você precisa ser eficiente, ser rápido é algo que virá com o tempo e experiência.
O diagrama abaixo apresenta de forma visual os passos descritos anteriormente, esse diagrama mostra a forma estruturada de troubleshooting que descrevemos até aqui.
Essa metodologia estruturada é ótima para quem ainda não possuí tanta experiência em troubleshooting, sendo um ponto de apoio a quem esta começando, ajudando a manter uma linha de raciocínio lógica durante todo o processo de análise e resolução do problema.
Com o passar do tempo, você se torna mais familiar com os cenários com os quais passa a trabalhar, adquire experiência e passa a observar que alguns problemas apresentam semelhanças na forma como originam e são solucionados, desta forma, aplicar a metodologia estruturada de troubleshooting passa a ser algo que pode lhe consumir bastante tempo, assim sendo, você pode adiantar algumas dessas etapas saindo a fase de diagnóstico e indo para a fase de hipóteses, como apresentado no diagrama abaixo.
Obs: Procure sempre documentar tudo o que ocorreu durante a análise e resolução dos problemas, informações relatadas pelos usuários, falhas que ocorreram no ambiente e principalmente, documente o que foi feito para sanar o problema, ao longo do tempo você terá criado uma base de conhecimento que servirá de apoio análises futuras.
Métodos populares de troubleshooting
Uma das fases mais importantes do método estruturado é a fase de eliminar as possíveis causas do problema e para isso existem algumas formas de abordagem que podem ser utilizadas, vamos conhece-las:
- Método Top-down
- Método botton-up
- Método dividir para conquistar
- Seguir o caminho do tráfego
- Comparar configurações
- Troca de componentes
Vamos ver como utilizar cada uma dessas abordagens.
Tenha em mente que não existe o melhor método a se aplicar, dependendo da situação que você esteja analisando, você poderá utilizar um ou vários métodos.
Neste ponto espero que você esteja bem familiarizado com o modelo OSI de 7 camadas, pois é a partir dele que iremos descrever alguns métodos.
Método Top-down
O método top-down começa a partir do topo da camada do modelo OSI, ou seja, partimos da camada 7 (camada de aplicação) e vamos descendo.
Esse método checa se a aplicação na qual você esta efetuando o troubleshooting esta funcionando, assumindo que, se a aplicação esta funcionando, todas as demais camadas abaixo dela também estão. Se você efetua um teste de ping (ICMP) entre uma máquina e o local aonde sua aplicação esta armazenada, você esta testando as camadas 1,2 e 3. Uma desvantagem deste método é que para efetuar os testes na camada de aplicação, você precisa efetivamente acessar a aplicação específica que esta passando por problemas para testar a camada 7.
Método Botton-up
O oposto do método top-down. Neste método iniciamos nossa análise a partir da camada 1 do modelo OSI e vamos subindo. Aqui testamos o cabeamento, conectores, se a porta ethernet no switch ou no computador esta funcionando, se temos algum problema de spanning-tree, se as vlans estão corretamente configuradas e aplicadas nas portas, features como port-security e etc. Vamos seguindo e subindo o modelo até chegarmos a camada de rede (layer 3) e testamos a conectividade IP, access-list, protocolos de roteamento e assim por diante.
Método dividir para conquistar
Se você não esta certo por onde começar sua análise, esse pode ser um bom ponto de partida.
Como o próprio nome sugere, aqui dividimos o ponto de partida de nossa análise, começamos da camada 3 e com um simples teste de conectividade IP podemos rapidamente identificar o método que iremos utilizar para análise. Se você efetua um teste de ping (ICMP) e o resultado falha, então você tem uma sinalização que algo entre as camadas de 1 a 3 não esta funcionando corretamente e o método botton-up pode ser aplicado a partir deste momento.
Seguir o caminho do tráfego
Um método muito útil, aqui você de fato irá seguir o caminho do tráfego da origem até o destino final. Se um usuário informa que não consegue acessar um determinado servidor ou uma aplicação, primeiro você passa a analisar a conectividade entre o computador do cliente com o switch de rede, se tudo estiver ok, você segue para o próximo passo que é testar a conectividade do switch com o roteador ou o firewall do ambiente e assim por diante até encontrar aonde o tráfego esta parando.
Comparar configurações
Imagine que você possua um ambiente com vários switches de rede espalhados pela empresa. Você observa que apenas um desses switches não esta operando corretamente como os demais, como esses switches compartilham de muitas configurações em comum, você decide comparar as configurações aplicadas em ambos os equipamentos a fim de identificar a possível causa do problema (a falta de alguma configuração, como uma VLAN, ACL e etc).
Aqui fica a observação que se você não sabe exatamente o que esta procurando, você pode acabar adicionando novos problemas ao ambiente por simplesmente copiar uma configuração de um equipamento em outro.
Troca de componentes
Esse método é quando você suspeita que há algo errado com o hardware em si e resolve efetuar uma troca dos componentes físicos e efetuar novos testes, como por exemplo, a troca de um cabo de rede ou até mesmo um switch, se após efetuar a troca você observar que o problema não mais existe, você pode concluir que o problema estava no componente em si.
Conclusões
Muito pode ser dito sobre troubleshooting. Conversar com outras pessoas e entender como cada um traça um plano de ação sempre que esta efetuando um troubleshooting pode lhe ajudar e criar suas próprias estratégias. Aqui procurei demonstrar a teoria por trás desse conceito. Agora cabe a você utiliza-lo da melhor forma possível em seu dia a dia.
Lembre-se, a experiência virá com o tempo então seja paciente pois a caminhada é longa. Procure ganhar experiência praticando em laboratórios replicando sempre que possível alguns cenários desafiadores. Entender a teoria de como as coisas funcionam é essencial, com isso em mente, procure estudar e entender como cada tecnologia funciona, como por exemplo, como o OSPF o EIGRP, o STP e tudo mais que esteja operando no ambiente deveria funcionar?
Ao final do dia de nada adianta a teoria sem a aplicação da prática, então procure praticar sempre que possível.
Com isso encerro mais esse artigo, até a próxima e bons estudos.
Layer 3 Tecno 