CWAP - Capítulo 1 - Processos de Troubleshooting

É fundamental seguir um plano ou um método para resolver problemas de rede da maneira mais rápida e eficaz. Poupamos horas e horas de trabalho, agilizamos a aplicação da solução com o menor impacto possível na rede e nos serviços.

Alguns fabricantes até disponibilizam documentação sobre qual a metodologia de troubleshooting a seguir. Basta fazer uma procura por <fabricante> troubleshooting methodology que aparecem logo várias páginas. Por exemplo, a Cisco disponibiliza o seguinte documento:

Cisco - Troubleshooting Overview

Mas todas a metodologias são muito semelhantes e não se afastam muito da seguinte metodologia:

1- Identificar o problema

2- Descobrir a escala do problema

3- Definir as possíveis causas do problema

4- Identificar a causa mais provável do problema

5- Criar um plano de ação ou escalar o problema

6- Aplicar as ações corretivas

7- Verificar a solução

8- Documentar os resultados

Veremos agora cada passo em mais detalhe.

1- Identificar o problema

Um dos erros mais comuns é se assumir um problema sem verificar as suas causas ou tirar conclusões com base nas informações dadas pelos utilizadores. Qualquer especialista em redes wifi tem dezenas e dezenas de histórias em que foi chamado para resolver problemas na rede wifi, que mais tarde se vem a descobrir que não havia qualquer problema com a rede.

“Não assumir nada e verificar tudo” de modo a evitar horas de troubleshooting desnecessárias. Por isso, antes de abrir a sessão de CLI ou olhar para os gráficos do GUI, devemos começar por fazer as perguntas certas. Como por exemplo:

   - Há alguma mensagem de erro?

   - O que leva a pensar que a rede está em baixo?

   - Já alguma vez tiveram este problema? Se sim, é recorrente? E com que periodicidade?

   - Onde está a tentar a aceder à rede?

   - Continua no mesmo local onde se autenticou na rede ou deslocou-se para outro lugar?

   - Que tipo de equipamento está a usar?

   - Que software está a usar?

   - Há algum outro tipo de equipamento ou software que está com o mesmo problema?

   - O problema ocorre a uma hora específica do dia?

Estas perguntas e outras semelhantes, irão ajudar a melhor identificar o problema.

2- Descobrir a escala do problema

Descobrir qual o impacto e a verdadeira dimensão do problema na rede.

   - Acontece a um único utilizador ou a vários?

   - Acontece numa zona específica ou acontece por toda a rede?

   - Acontece a uma hora específica ou a qualquer hora?

   - Quantos utilizadores estão na zona quando acontece o problema?

3- Definir as possíveis causas do problema

Um único problema pode ter várias causas. Por exemplo, um cliente que reporta que está com problema de wifi porque não consegue aceder às aplicações que estão a correr num servidor remoto. Isso pode ser porque:

   - O equipamento do cliente está mal configurado

   - A cablagem está com problemas

   - O AP está em baixo

   - O controlador está em baixo

   - A pool de DHCP está cheia

   - O servidor de DHCP está em baixo ou incontactável

   - O servidor de DNS está em baixo ou incontactável

   - O switch ou o router estão com problemas

   - A ligação da internet está em baixo

   - O servidor está em baixo ou sobrelotado

   - O hardware do cliente está com falhas

Nestes 3 primeiros passos também será utilizado um método tecnológico como por exemplo o Método do Modelo OSI. Este método não é mais que fazer a resolução do problema de acordo com as tecnologias e protocolos de cada camada do modelo OSI. Muito importante quando se aplica este método é começar sempre pelo Layer 1 ou camada Física, seguindo depois para as outras camadas.

4- Identificar a causa mais provável do problema

Cumpridos os primeiros 3 passos já ficamos com uma boa ideia sobre o problema e a sua mais que provável solução. Podemos fundamentar as nossas suspeitas sobre o que está a acontecer e o que deve ser feito para o solucionar.

5- Criar um plano de acção ou escalar o problema

Não podemos simplesmente avançar com uma solução e correr o risco de provocar uma quebra de serviço durante o horário de expediente. Antes de se avançar com qualquer ação, é necessário confirmar o impacto que terá na rede e ponderar os riscos versus os benefícios.

Por exemplo, um problema que se venha a descobrir que é solucionado fazendo um upgrade ao controlador. Antes de avançar com o upgrade é importante estabelecer um plano de acção e colocar todas as partes interessadas de quais os impactos que vamos ter na rede porque um upgrade de um controlador Cisco, mesmo fazendo o predownload das imagens no controlador e nos APs, implica que a rede de wifi esteja em baixo durante 5 a 10 minutos.

É necessário:

  - Assegurar que temos um backup atualizado das configurações de todos os equipamentos que serão intervencionados. Por exemplo, com controladores Cisco, usar o WLCCA ( WLCCA Forum )

  - Assegurar que temos um diagrama de rede atualizado.

  - Assegurar que temos um registo do estado da rede antes de aplicar as alterações. Por exemplo:

         - Qual o estado das portas dos equipamentos?

         - Qual o estado das configurações?

         - Quantos APs estão em produção?

         - Quais os estados das WLANs?

  - Analisar as Release Notes da nova versão e confirmar qual o processo de upgrade aconselhado e qual a compatibilidade com os equipamentos em produção.

  - Assegurar que sabemos o que é necessário fazer caso seja necessário desfazer as alterações aplicadas.

Nem sempre é possível documentar o plano de ação mas é fundamental ter um plano de contingência caso o upgrade não corra conforme planeado ou mesmo que resolva o problema mas que provoque um algo mais grave na rede.

6- Aplicar as ações corretivas

Chegados a este ponto já temos uma boa ideia do problema, da solução, do plano de ação e do que fazer caso seja necessário voltar atrás.

Também é importante que todos os intervenientes estejam a par do plano de trabalhos.

7- Verificar a solução

Verificar que o problema ficou resolvido mas ainda mais importante, verificar que o comportamento da rede não se degradou com as novas alterações. Por vezes, existem situações em que não é possível confirmar a solução na altura da intervenção (ex: trabalhos fora da hora de expediente, poucos utilizadores/carga na rede) pelo que mesmo que após os trabalhos pareça que está tudo operacional, convém reverificar tudo.

É possível que chegados a este ponto verifiquemos que o problema não ficou resolvido e necessitemos de repetir todo a metodologia. As vezes que forem precisas até o problema ficar resolvido.

8- Documentar os resultados

Este ponto costuma ser negligenciado mas não deixa de ser importante. Ajuda a cimentar o conhecimento do problema e a solução.

Ajuda que em futuras ocorrências de problemas idênticos ou semelhantes, sejam resolvidas mais rapidamente.
Ajuda a passar a informação a outros colegas que se deparem com o mesmo problema.

Links para apresentações sobre o assunto:

Magic Analysis - Peter Mackenzie - wlpc phoenix 2017

BRKEWN-3011 - Advanced Troubleshooting of Wireless LANs (2017 Berlin)   *nota: necessita de acesso a apresentações CiscoLive