Identificando e Definindo o Problema

Identificar o problema é a primeira etapa e, sem dúvida, uma das mais importantes. Um problema identificado incorretamente direciona todas as etapas seguintes para o caminho errado. O objetivo aqui é obter uma descrição do problema clara, específica e verificada. O tempo dedicado a compreender precisamente o problema raramente é desperdiçado, pois concentra todo o esforço posterior no sintoma real, e não em uma suposição.

Comece coletando fatos. Converse com os usuários afetados, verifique os painéis de monitoramento e os registros, e faça testes rápidos por conta própria. Procure descobrir o escopo (um usuário, um andar ou o site inteiro), o momento (quando começou) e os sintomas (lentidão, falhas intermitentes ou indisponibilidade total). Quanto mais concretas forem as informações, mais precisa será sua teoria.

Uma pergunta poderosa é "o que mudou?" A maioria dos problemas começa logo após uma mudança: um novo equipamento, uma edição de configuração, uma atualização de software ou um evento relacionado à energia. Pergunte aos usuários e verifique os registros de mudanças. Se um serviço funcionava ontem e falha hoje, algo está diferente, e encontrar essa diferença frequentemente leva diretamente à causa. Mudanças recentes são as principais suspeitas.

Os usuários descrevem os sintomas com suas próprias palavras, portanto entreviste-os com atenção e gentileza. Faça perguntas abertas: "O que você estava fazendo quando falhou?" e "Mais alguma coisa mudou?" Evite perguntas tendenciosas que induzam uma resposta falsa. Tenha em mente que os usuários podem omitir detalhes ou descrever efeitos em vez de causas. Paciência e boas perguntas transformam uma reclamação vaga em dados úteis.

Determinar o escopo reduz drasticamente a área de busca. Se apenas um PC for afetado, examine esse dispositivo ou seu cabo. Se uma VLAN inteira estiver indisponível, suspeite de um comutador ou do gateway. Se o site inteiro estiver sem internet, concentre-se no enlace WAN ou no ISP. Relacionar o tamanho do problema ao tamanho da provável causa economiza muito tempo.

Quando possível, reproduza o problema por conta própria. Reproduzir a falha confirma que ela é real, revela as condições exatas e fornece um teste que você pode repetir depois da correção. Se um site falhar para o usuário, tente acessá-lo do seu próprio computador na mesma rede. Problemas intermitentes são mais difíceis de reproduzir, mas fazer isso é extremamente útil para confirmar a solução.

A CompTIA afirma explicitamente que é preciso questionar o óbvio. Muitas interrupções têm causas banais: um cabo desconectado, um dispositivo desligado, uma senha expirada ou o caps lock ativado durante o início da sessão. Verificar esses itens primeiro leva segundos e frequentemente resolve o problema. Ignorar as verificações simples porque "não poderia ser isso" é uma maneira clássica de desperdiçar horas com uma falha trivial.

Os dispositivos frequentemente anunciam seus próprios problemas. Leia os registros em busca de mensagens de erro, observe as luzes de enlace das interfaces e analise os alertas de monitoramento. Uma luz vermelha em uma porta do comutador, um evento registrado de "interface inativa" ou uma mensagem de erro do DHCP podem apontar diretamente para a falha. Deixar que o equipamento informe o que está detectando complementa o relato do usuário.

Considere se você está diante de um problema ou de vários. Às vezes, duas falhas não relacionadas aparecem ao mesmo tempo e parecem um único sintoma estranho. Se as pistas não se encaixarem em uma única causa, pergunte se dois problemas estão ocorrendo simultaneamente. Separar problemas emaranhados evita a confusão de tentar explicar tudo com uma única teoria forçada.

Reúna suas descobertas em uma descrição do problema precisa: quem é afetado, o que falha, quando começou e qual é o padrão observado. "Desde a reinicialização do comutador às 9h, todos os telefones da VLAN 20 não conseguem se registrar" é muito mais útil do que "os telefones estão quebrados". Uma boa descrição é a base sobre a qual o restante da metodologia é construído.

Uma definição sólida do problema naturalmente aponta para teorias sobre a causa. Se o problema começou após uma mudança de configuração em um comutador e afeta apenas os usuários desse comutador, sua primeira teoria praticamente se formula sozinha. Dedicar um esforço real à identificação torna a formulação de teorias, os testes e a correção muito mais rápidos e precisos. Defina bem o problema, e o restante da solução de problemas fluirá.

Teste sua compreensão da identificação de problemas.

Você aprendeu a identificar e definir problemas. Pontos principais:

• Obtenha o escopo, o momento e os sintomas com usuários, registros e testes.
• Sempre pergunte "o que mudou?"
• Determine o escopo para dimensionar a provável causa; reproduza o problema quando possível.
• Questione o óbvio primeiro.
• Escreva uma descrição precisa do problema que oriente todas as etapas seguintes.