Sostantivi

Nesta etapa, a equipe de gerência é notificada de que algo estranho está ocorrendo na rede. A notificação pode ser feita de duas formas distintas:

1. os usuários ligam para o help desk e reportam sintomas de um problema; 2. o operador da rede percebe a existência de dispositivos ou interfaces não

operacionais, limiares sendo excedidos ou padrões de tráfego estranhos. Estas situações podem gerar alarmes na estação de gerência. Quando o estado operacional de um equipamento crítico da rede muda para não operacional, o equipamento em questão pode mudar de cor no mapa da rede – ficar vermelho, por exemplo – ou um e-mail pode ser enviado ao operador do sistema.

Uma vez notificado sobre um problema, inicie imediatamente a fase de coleta de informações.

Não é interessante que problemas graves, que levem grande parte da rede a não funcionar, sejam descobertos através dos usuários. Uma das seguintes situações pode estar ocorrendo:

_{não existe uma estação de gerência ou qualquer outra ferramenta de} monitoração dos enlaces e equipamentos mais críticos da rede;

_{existem ferramentas, mas muitos enlaces importantes não estão sendo} monitorados, ou as ferramentas estão sendo utilizadas de forma errada;
_{a ferramenta de gerência é maravilhosa, todos os enlaces e equipamentos}

críticos estão sendo monitorados, mas a equipe de gerência não analisa com bastante freqüência os dados apresentados por esta ferramenta. Seja qual for a razão pela qual problemas graves estão sendo descobertos através de usuários, algo deve ser feito para reverter esta situação. O ideal é que somente problemas que envolvam um único usuário ou no máximo alguns usuários ligados a um mesmo repetidor/comutador sejam descobertos através deles.

4.2Busque informações

Uma vez notificado sobre a existência de um problema, a primeira ação é buscar informações relevantes que possam ajudar a definir que problema está ocorrendo e onde ele está localizado.

Tente responder – seja com a ajuda dos usuários reclamantes, seja observando estatísticas e alarmes da estação de gerência – as seguintes questões:

1. Quem está sendo afetado pelo problema? Apenas um usuário? Todos os usuários? Alguns usuários que fazem parte de uma mesma sub-rede? 2. Quando o problema começou a ser percebido?

















3. Desde então, o problema ocorre sempre, ou apenas em certos horários? Neste caso, em que horários?

4. O problema se manifesta sempre ou apenas quando alguma aplicação e/ou serviço específicos são usados? Neste caso, que aplicações e/ou serviços? 5. Alguma mensagem de erro está sendo gerada? Qual?

6. O problema é intermitente? Por exemplo, o usuário consegue enviar e-mails em certos momentos, mas em outros recebe mensagens de erro.

As informações obtidas sobre os problemas são passados para a equipe de suporte técnico através do help desk10 ou através do operador da rede, quando estes não são

capazes de resolver o problema em curto espaço de tempo.

Com base nestas informações, você pode iniciar a busca por outros sinais na estação de gerência ou usando outras ferramentas de gerência. É interessante que você obtenha o estado operacional dos equipamentos e interfaces envolvidas, taxa de erros e utilização de entrada e saída destas interfaces. Use a estação de gerência para obter o máximo de informações possível.

Se você não sabe como obter um sinal, procure ajuda nos PROCEDIMENTOS. Eles

ensinam como obter – considerando vários tipos de instrumentação – e interpretar informações de gerência. Se você não possui uma estação de gerência monitorando os elementos críticos da rede e não tem ainda idéia de onde o problema possa estar ocorrendo, o procedimento apresentado na Seção 10.3 pode lhe ajudar.

Outras ferramentas de gerência úteis nesta fase são analisadores de protocolos, ping e traceroute. Em muitos casos, o problema pode envolver equipamentos ou serviços que não estão sendo monitorados pela estação de gerência. Outra possibilidade ocorre quando a quantidade de informação coletada não é suficiente para diagnosticar o problema. Além disso, no nível de gerência do qual estamos falando, não somos capazes de descobrir, através da estação de gerência, que um serviço está com problemas enquanto a infra-estrutura de rede sob a qual ele se apóia não está. Nestes casos, o auxílio de analisadores de protocolos e de outras ferramentas auxiliares é imprescindível.

Se o problema envolver um pequeno grupo de usuários, verifique a configuração de rede das máquinas de alguns deles. Elas podem revelar informações importantes. As informações obtidas nesta etapa da metodologia nos deixam mais próximos do problema, levando-nos a focar a atenção onde o problema realmente está ocorrendo.

4.3Recorrência de problema? Mudanças na rede?

Muitas perguntas já foram respondidas no passo anterior, mas deixamos duas, em especial, para ser respondidas nesta etapa:

10 _{Quando esta equipe existir e considerar que realmente existe um problema e não for capaz de}

_{este problema ocorreu nos últimos 30 ou 60 dias?}

o se a resposta for “sim”, grandes chances existem de o problema ter voltado a ocorrer;

_{houve alguma modificação recentemente na rede que possa ter causado os} sinais e sintomas verificados no passo anterior?

o se a resposta for “sim”, é muito provável que esta modificação tenha originado o problema reportado.

Respondendo positivamente a uma destas perguntas, vá direto ao ponto. Não perca tempo. Você muito provavelmente já localizou o problema, ou pelo menos já identificou que ele envolve um determinado serviço ou elemento da rede.

Suponha que você já descobriu que o problema envolve um certo serviço que foi instalado ontem. Você vai então criar uma lista de hipóteses, mas esta não levará em consideração hipóteses não relacionadas a este serviço. No fluxograma apresentado na Figura 4-1, dizemos que você deverá criar uma lista de hipóteses específicas.

Você já coletou informações sobre o problema, mas não criou uma lista genérica de hipóteses. Caso os testes que vêm a seguir não revelem que o problema era o imaginado, desenvolva hipóteses genéricas com base nos sintomas e sinais já reunidos.

Nesta etapa da metodologia, a documentação dos problemas já enfrentados poderá ser de grande auxílio (ver Seção 4.9).

4.4Desenvolva hipóteses

Neste momento nós já temos informações suficientes sobre o problema para começar a desenvolver hipóteses. Até agora um problema foi apenas detectado, isto é, sabe-se de sua existência. Já temos também uma boa idéia de como a rede está reagindo ao problema (sintomas e sinais reunidos) e que partes da rede estão sendo afetadas. Com base em todas estas informações, podemos criar hipóteses sobre que problema pode estar ocorrendo. A pergunta básica a ser respondida neste momento é: que problemas podem causar os sintomas e sinais percebidos? A

criação da lista de hipóteses é o primeiro passo para localizar especificamente o problema.

É importante ressaltar que, para conseguir criar a lista de hipóteses é necessário que tenhamos um bom conhecimento sobre como as redes e os serviços oferecidos por elas funcionam. É preciso saber como as coisas deveriam estar funcionando se nenhum problema estivesse ocorrendo, comparar com o que está ocorrendo e perceber o que pode estar causando o comportamento atípico. Se você desconhece como o serviço DHCP funciona, não poderá jamais desvendar problemas que envolvam este serviço.

Além disso, precisamos também conhecer a rede que está sendo gerenciada. Onde estão os serviços, como deve ser o roteamento, como se dá a interconexão dos

equipamentos e onde estão implantados firewalls, são exemplos de informações que devemos conhecer previamente.

Vamos voltar a nossa analogia com a Medicina. Para que um médico consiga, a partir de sintomas e sinais, suspeitar de certas doenças, ele precisa conhecer a anatomia e o funcionamento do corpo humano. Caso contrário, ele não conseguiria chegar ao diagnóstico diferencial.

Nesta etapa da metodologia os ÍNDICES INVERTIDOS podem auxiliar. Veja nos índices invertidos que problemas podem causar os sintomas e sinais observados. Desta forma, você obterá facilmente uma lista de hipóteses inicial.

Chegou o momento de exemplificarmos a metodologia sendo apresentada. Suponha que você tenha as seguintes informações:

_{alguns usuários do Setor de Marketing ligaram para o help desk reclamando} que a rede não está funcionando há 15 minutos. Nem logon na rede eles conseguem fazer;

o estas foram as informações repassadas pela equipe de help desk;
_{todos os equipamentos e interfaces monitorados pela estação de gerência}

estão operacionais e não apresentam limiares excedidos. Mas, existem repetidores que ligam máquinas clientes do Setor de Marketing à rede que não estão sendo monitorados;

Baseados nestas informações, consultamos o índice invertido de sintomas e sinais e desenvolvemos as seguintes hipóteses:

_{cabo rompido ou danificado entre repetidores localizados no Setor de} Marketing;

_{conector defeituoso ou mal instalado entre repetidores localizados no Setor} de Marketing;

_{um ou mais repetidores defeituosos no Setor de Marketing;
problema com o serviço DHCP do Setor de Marketing;
problema com o serviço de nomes do Setor de Marketing;}

Não se preocupe neste momento em identificar claramente o problema. O que você e sua equipe irão fazer nesta etapa é um brain storm. Irão levantar todas as possibilidades que vierem em mente. Se, no entanto, você estiver criando uma lista de hipóteses específica, leve em consideração apenas o elemento da rede ou serviço que já estiver sob suspeita.