Suas regras de solução de problemas, abordagem para solução de problemas? [fechadas]

Question

Você tem alguma regra geral à qual você recorre quando soluciona um problema difícil de rede / hardware / software?

Por exemplo: "Eu isolo a fonte do problema testando um periférico com um segundo computador" ou "Eu removo o máximo de hardware possível para ligar o dispositivo e, em seguida, adiciono os componentes um por um até Posso reproduzir o problema ", etc.

    

Answer 1

Apenas uma lista de pontos que escrevi para mim mesmo depois de lutar com um problema por um tempo:

1. Qual é o seu objetivo principal ? Deve ser indicado claramente e como conciso. O objetivo deve ser muito especial. Não deveria ser geral. De preferência, um sentença .
   
2. Qual é o seu problema?
   
3. Existe apenas um problema ou muitos ? Se houver muitos, resolva um de cada vez.
   
4. Tente reproduzir o problema com condições diferentes . Pode ser reproduzido em todos os possíveis condições ou não? Diz qualquer coisa sobre a natureza do problema?
   
5. Se é um problema urgente existe uma solução alternativa ? Tente encontrar como muitas soluções alternativas possíveis.
   
6. Tente fazer muitos palpites como possível sobre o que é a causa de seu problema.
   
7. Tente provar suas suposições experimentar com o sistema.
   
8. Seja consistente no que você está tentando façam. Faça uma coisa de cada vez.
   
9. Acompanhe o que você está fazendo e o que você já tentou.
   
10. O não se desvia do seu  objetivo principal. Verificar constantemente se  você ainda está resolvendo seu principal  problema, não um differenet.
    
11. Também não fixe .

Também havia uma ótima lista de regras de depuração, que estava em um formulário PDF com exemplos e explicações para cada uma das regras. Não consegui encontrar rapidamente o PDF, mas acho que este é um cartaz da lista:

    

Answer 2

• Se o problema estiver relacionado à Internet, provavelmente é o DNS.

• Se o problema é difícil de diagnosticar, provavelmente é a RAM.

• Se o problema for com uma estação de trabalho do Windows, provavelmente é mais rápido recriar a imagem dele.

• Se o problema for numa sexta-feira, provavelmente é algo sério.

Answer 3

Eu gosto de voltar para o método científico .

De ( link )

1. Define the question
2. Gather information and resources (observe)
3. Form hypothesis
4. Perform experiment and collect data
5. Analyze data
6. Interpret data and draw conclusions that serve as a starting point for new hypothesis
7. Document Results

Como regra geral, eu sempre gosto de checar minhas suposições básicas. Tem energia, está conectada, a fiação é boa. É muito chato passar horas tentando ver um problema de software quando você tem um cabo solto.

Acho muito importante, durante a fase de criação de hipóteses, chegar a tantas possíveis causas do problema quanto possível. Então eu tento escolher ideias para testar primeiro, com base em quão fácil é testar, e quão provável é a idéia.

Também é importante obter ajuda. Consulte seus colegas de trabalho, fornecedor ou quem quer que seja o mais bem informado sobre os sistemas em questão, se puder. Não gaste muito tempo girando suas rodas em um problema se houver alguém disponível que possa ajudá-lo a resolver o problema.

O'Reilly tem um bom livro Ferramentas de solução de problemas de rede que tem um bom conjunto de etapas a seguir que é muito semelhante ao método científico. Eu achei o livro muito útil e recomendo strongmente. O livro entra em muito mais detalhes e sugere muitas ferramentas úteis.

De Ferramentas de solução de problemas de rede

1. State your goal
2. Define the system
3. Identify possible outcomes
4. Identify and select what you will measure
5. If appropriate identify test paramaters and factors
6. Select tools
7. Establish measurement constraints
8. Review experimental design
9. Collect data
10. Analyze data

Veja também:

• A 3COM tem um guia de solução de problemas
• A lei de Murphy - Qualquer coisa que possa dar errado, faz.
• Occam's_razor - Todas as outras coisas sendo iguais, a solução mais simples é a melhor.

Answer 4

(Esses destaques são parafraseados do capítulo "Depuração" de "A prática da administração de sistemas e de rede" )

Duas coisas para saber:

1. Saiba como é a versão "fixa". De preferência, é possível executar um comando que forneça uma determinada saída quando as coisas funcionarem. Por exemplo: estou tentando descobrir por que o SSH pede uma senha quando configuro as chaves corretamente (ou assim pensei). Então meu teste é: "ssh servername uptime" e deve funcionar sem pedir uma senha.

2. Descreva o problema no nível certo. Um usuário reclamando que não pode fazer ping em um servidor não deve enviar você para executar e corrigir o servidor. O trabalho da pessoa não é ficar sentado e pingar uma máquina o dia todo. Eles querem fazer algum tipo de tarefa, como usar a máquina como seu servidor DNS. Exemplo: Uma vez que um usuário reclamou que não conseguia fazer o ping de uma máquina pelo mundo. Passei o dia rastreando administradores de sistemas naquela parte da empresa para descobrir o que havia de errado com aquela máquina. Ele foi desativado e eles entraram em pânico porque pensaram que talvez tivessem desligado a máquina errada. Entrei em contato com o usuário e disse "além de precisar fazer o ping nessa máquina, o que você gostaria de fazer com ela?". Descobriu-se que ele queria executar um determinado trabalho e se ele estivesse seguindo o procedimento adequado, suas tarefas teriam sido redirecionadas automaticamente para a máquina substituta. Eu tinha desperdiçado meu dia inteiro e o tempo dos administradores locais. Outro motivo "não consigo pingar" não é a coisa certa a ser testada: frequentemente, os firewalls são configurados para descartar pacotes de ping, mas permitem a passagem de outros pacotes. Teste o que você quer passar.

Duas estratégias:

1. Aditivo: Continue adicionando componentes até o problema começar. A última coisa que você adicionou é o problema. Exemplo: Navegadores da Web não podem falar com um servidor. Entre o servidor e o usuário, há um balanceador de carga, um firewall, um cache e o proxy da Web local do usuário. Primeiro tente enviar consultas diretamente para o servidor, depois através do LB para o servidor, depois através do firewall para o LB para o servidor, etc. etc., cada vez adicionando um componente.

2. Subtractive: Continue removendo componentes até que o problema desapareça. A última coisa que você removeu foi o problema: Exemplo: Uma máquina com dezenas de cartões não inicializa. Continue removendo os cartões até que a máquina inicialize.

Dois bits de sorte:

1. Esqueça tudo o que eu disse. O problema está sendo causado pela última alteração feita no sistema. (isso funciona 99% do tempo ... o problema é que 99% do tempo você não sabe qual foi a última alteração na verdade foi)

2. Quando tudo mais falhar, verifique se há coisas estúpidas. link Exemplo: Um problema maluco simplesmente não poderia ser explicado. Em seguida, verificamos o arquivo de configuração: um usuário o editou copiando-o para uma caixa do Windows, editando-o e copiando-o de volta. Agora tinha um ^ M no final de cada linha. Nós nunca notamos porque o nosso editor de texto silenciosamente escondeu esse fato. Infelizmente, o software que leu o arquivo de configuração transformou esses \ Ms em um espaço sem quebra que atrapalhou muitos outros procedimentos.

Answer 5

Práticas gerais de que me lembro durante todo o processo:

1. Escreva tudo o que faço.
2. Faça apenas uma alteração por vez.
3. Se possível, inverta a alteração antes de tentar outra, a menos que progresso definitivo esteja sendo feito.

Durante a resolução de problemas, aqui define minha metodologia básica:

• Quando o sistema está funcionando bem, antes que haja um problema, tento aprender a ver o que ele está fazendo. Joe Richards explica porque muito melhor do que eu poderia neste espaço curto .
• Eu começo com a solução mais simples. Por exemplo, sem conectividade de rede? Verifique a camada física. Não posso dizer quantas vezes problemas intermitentes de conexão não foram um problema no servidor, mas um cabo de rede que estava na metade ou que estava mal.
• Tento capturar todos os sintomas que posso ver de todas as fontes prováveis antes de começar a fazer alterações.
• Eu corro testes diagnósticos preliminares. Por exemplo, quando sou informado de que um servidor está inativo, a primeira coisa que faço é usar ping e nbtstat (Windows) para verificar isso. O problema pode estar no extremo distante (para pedir emprestado um antigo controle técnico da Força Aérea).
• Eu não tenho medo de fazer a pesquisa. Google, support.microsoft.com, eventid.net e sites como esse são seus amigos.
• Não tenho medo de pedir ajuda da comunidade. Não apenas sites como serverfault.com, mas eu tenho uma boa variedade de pessoas em quem confio e respeito no Twitter com quem mantenho contato.
• Eu avalio as respostas que estou encontrando com o que estou vendo. Eu não assumo que qualquer solução seja a correta até que eu possa fazer considerações suficientes sobre as evidências que estou vendo com o que está relatado na solução.

Answer 6

Atitudes que tento manter:

• Confiança absoluta que causa e efeito funciona e nada é mágico. Nada está acontecendo que é realmente estranho, apenas coisas que eu não entendo.
• Confiança absoluta de que, se eu continuar insistindo, resolverá (isso pode envolver levá-lo a alguém mais qualificado, aprendendo, pedindo ajuda, muito trabalho, etc.).
• Resmungando sobre como uma configuração, programa ou cenário é mal projetado ou realmente estúpido simplesmente não ajuda, então não faça isso. (Eu acho isso difícil, resmungando é divertido).

Estas são atitudes que são úteis para eu segurar - elas me impedem de jogar meus braços para o alto, declarando algo "bizarro" e depois desistindo, ou ficando infeliz porque parece "insolúvel".

Maneiras de solucionar problemas:

• Os sistemas têm muitas partes, se eles estiverem conectados juntos ou configurados aleatoriamente, eles não funcionarão como desejado. Há uma ou duas configurações muito específicas que funcionarão - de todas as maneiras de empilhar tijolos e metal, apenas algumas são pontes e apenas uma ou duas pontes são boas o suficiente. A causa pode ser um caractere em um arquivo de texto ou em um servidor com falha, mas cada parte precisa estar certa para que a coisa toda esteja certa. Eu preciso estar disposto a ser minucioso e meticuloso, se necessário. Sistemas não podem fazer "o show deve continuar".
• Você começa com um sistema inteiro como um mapa, imagina uma nuvem de probabilidade flutuando sobre o mapa representando "onde está o problema" e seu trabalho é usar a experiência e encontrar testes para afastar a probabilidade de algumas áreas e em relação aos outros e condensá-lo em pontos que são locais de alta probabilidade, atacando-os. Isso volta ao ponto de causa e efeito - o problema está no sistema, não é mágico. É um problema que existe, portanto deve existir em algum lugar.
• Qualquer coisa pode ser configurada da maneira que alguém quiser. A única maneira que podemos definir um comportamento como "OK" e outro como "um problema" é porque o que alguém está recebendo não é o que eles querem. Você deve entender o que eles querem, o que eles estão recebendo de forma clara e específica.

O processo de solução de problemas:

• Qual é o problema. Certifique-se de que está acontecendo e pode reproduzi-lo por si mesmo para que não haja falhas de comunicação. Muitas vezes os problemas já passaram por várias pessoas no nosso helpdesk quando chegam a mim, mas ninguém consegue me explicar qual é realmente o problema.
• A bisseção recursiva é mais uma vez - dividir e conquistar, busca binária - você faz um teste que prova se o problema é deste lado do teste, ou daquele lado, e faz o teste para eliminar tanto quanto possível. Repita até resolver.
• Não saiba se você pode evitá-lo - é melhor bloquear a conta do banco de dados e provar que o problema ainda acontece quando o banco de dados não está envolvido do que passar horas aprendendo como o banco de dados é usado.
• É muito fácil me encontrar pensando "Eu não sei o que fazer a seguir". Observe quando isso acontecer e volte a fazer testes que localizem o problema.

A Internet não está funcionando? Verifique o problema, ache que é um site que eles não podem acessar. Testes rápidos envolvem sua conexão com a internet (funcionando), isso me carrega (não). Testes rápidos apontam para o site. Ao ver que o problema acontece para mim, afastei a probabilidade rapidamente do seu PC, navegador, DNS, firewall de escritório de conta de usuário, etc.

Então o site não carrega, e agora? Isso não pode ser corrigido ainda, então procure locais para dividir o problema em um menor. O servidor está ligado? Faz ping? o DNS funciona? Sim. O serviço responde na porta 80? Não. O serviço está em execução? Não. Começa? Não. Isso gera erros no log de eventos / arquivos de log? Sim! O que eles dizem?

Esta é uma solução de problemas eficiente e rápida porque está incansavelmente focada em reduzir o escopo do problema. Se eu aceitasse o relato de que a internet não está funcionando, eu estaria equivocado em pensar que é uma falha de conexão. Se eu aceitasse meu primeiro avistamento que ele não carrega para eles, eu perderia tempo com o computador deles achando que estava com defeito.

Crie pedaços de "coisas que não podem ser" tão grandes quanto possível.

Entenda o sistema. Quanto mais conhecimento geral eu tenho sobre um sistema, mais fácil fica. Onde eu tenho um entendimento fraco, os problemas são mais intimidadores, mais difíceis, mais lentos, e mais propensos a acabar com uma solução do que com uma correção, ou com uma grande correção lenta (reinstalar) do que uma correção cirúrgica pequena e precisa. p>     

Answer 7

Geralmente eu pergunto "O que mudou que poderia ter causado este problema"? A maioria dos problemas é causada por alterações em boas configurações conhecidas. Se você conseguir isolar quem fez a mudança, você geralmente recebe sua resposta.

    

Answer 8

Eu acho que é uma habilidade, não uma ciência. Há momentos em que você vai pelo caminho errado, mas na maior parte:

• Ter uma boa compreensão básica de todas as tecnologias associadas - Rede, hardware, SO, software, desenvolvimento, etc. - ajudará a eliminar alguns desses "caminhos errados"
• pense básico - não pule para o cenário mais complicado porque está na sua cabeça, execute sua solução de problemas básica e deixe que ele o leve.

Uma vez eu tive meu chefe me ligando com um engenheiro "sênior" no telefone - ele estava me dizendo que tinha um servidor que não podia se conectar e ele tentou trocar o cabo mas ainda não alegria. Eu podia ouvir bipes no fundo como um no-break em baterias. Eu perguntei se ele podia ver a atividade no interruptor, ele disse que não. Perguntei-lhe se o bip estava vindo do no-break, ele disse que sim, eu perguntei se ele podia ver alguma luz acesa no rack ele disse que não ... Olhe além do seu nariz - isso ajuda!

    

Answer 9

Eu começo verificando o óbvio. Existe uma mensagem de erro explicando qual é o problema? Está tudo bem conectado? Eu não gosto de perder várias horas solucionando problemas que poderiam ter sido resolvidos em poucos minutos. Eu acho que é possível ser muito metódico. Vi pessoas desperdiçarem um dia inteiro reproduzindo um problema, apesar de eu lhes ter dito exatamente qual era o problema. Não é isso que eu pago por eles.

Se a resposta não for óbvia, alinhe alguns suspeitos e teste-os primeiro. Somente depois de testar os suspeitos prováveis, você deve testar os suspeitos improváveis. Então você pode ser tão científico quanto quiser.