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

Você tem alguma regra geral em que recorre ao solucionar um problema difícil de rede / hardware / software?

Por exemplo: "Eu isolei 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 componentes um a um até que eu possa reproduzir o problema" , etc.

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

1. Qual é o seu objetivo principal ? Deve ser declarado de forma clara e concisa. O objetivo deve ser muito particular. Não deve ser geral. De preferência uma frase .
   
2. Qual é o seu problema ?
   
3. Existe apenas um problema ou muitos ? Se houver muitos, resolva-os um de cada vez.
   
4. Tente reproduzir o problema com diferentes condições . Pode ser reproduzido em todas as condições possíveis ou não? Diz alguma coisa sobre a natureza do problema?
   
5. Se for um problema urgente, existe uma solução alternativa ? Tente encontrar o máximo de soluções possíveis.
   
6. Tente fazer o máximo possível de palpites sobre a causa do seu problema.
   
7. Tente provar suas suposições, experimente o sistema.
   
8. Seja fiel ao que você está tentando fazer. Faça uma coisa de cada vez.
   
9. Acompanhe o que você está fazendo, o que você já tentou.
   
10. Não se desvie do seu objetivo principal. Verifique constantemente se você ainda está resolvendo o seu principal problema, e não um problema diferente.
    
11. Você não fixar qualquer um.

Também havia uma grande lista de regras de depuração, em formato PDF com exemplos e explicações para cada uma das regras. Não consegui encontrar rapidamente o PDF, mas acho que este é um pôster da lista:

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

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

• Se o problema estiver em uma estação de trabalho Windows, provavelmente será mais rápido revê-la.

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

Eu gosto de voltar ao método científico .

De ( http://en.wikipedia.org/wiki/Scientific_method )

1. Defina a pergunta
2. Reunir informações e recursos (observar)
3. Formular hipótese
4. Realize experimentos e colete dados
5. Analisar dados
6. Interprete dados e tire conclusões que servem como ponto de partida para novas hipóteses
7. Resultados do Documento

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

Acho muito importante, durante a fase de criação da hipótese, encontrar o maior número possível de causas possíveis do problema. Depois, tento escolher idéias para testar primeiro, com base em como é fácil testar e em quão provável é a ideia.

Também é importante obter ajuda. Consulte seus colegas de trabalho, fornecedor ou quem tiver mais conhecimento 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 possui um bom conjunto de etapas a serem seguidas, muito semelhantes ao método científico. Achei o livro muito útil e recomendo vivamente. O livro entra em muito mais detalhes e sugere muitas ferramentas úteis.

Nas ferramentas de solução de problemas de rede

1. Declare seu objetivo
2. Definir o sistema
3. Identifique possíveis resultados
4. Identifique e selecione o que você medirá
5. Se apropriado, identifique os parâmetros e fatores de teste
6. Selecionar ferramentas
7. Estabelecer restrições de medição
8. Revisar o projeto experimental
9. Coletar dados
10. Analisar dados

Veja também:

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

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

Duas coisas a saber:

1. Saiba como é a versão "fixa". De preferência, um comando que você pode executar que fornece uma determinada saída quando as coisas funcionam. Por exemplo: estou tentando descobrir por que o SSH solicita uma senha quando configurei as chaves corretamente (ou assim eu pensava). Portanto, meu teste é: "ssh servername uptime" e deve funcionar sem solicitar uma senha.

2. Descreva o problema no nível certo. Um usuário reclamando que não pode executar ping em um servidor não deve enviá-lo para executar e corrigir o servidor. O trabalho da pessoa não é ficar sentado e pingar uma máquina o dia todo. Eles querem realizar algum tipo de tarefa, como usar a máquina como servidor DNS. Exemplo: uma vez que um usuário reclamou que não podia executar ping em uma máquina no meio do mundo. Passo o dia rastreando administradores do sistema naquela parte da empresa para descobrir o que havia de errado com essa máquina. Foi desativado e eles estavam 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 executar ping nesta máquina, o que você gostaria de fazer com ela?". Acabou que ele queria executar um determinado trabalho e, se estivesse seguindo o procedimento adequado, suas tarefas seriam automaticamente redirecionadas para a máquina de substituição. Eu havia desperdiçado meu dia inteiro e o tempo dos administradores de sistemas locais. Outro motivo para "não conseguir executar ping" não é a coisa certa a ser testada: geralmente os firewalls são configurados para descartar pacotes de ping, mas permitem que outros pacotes sejam executados. Teste o que você deseja 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 pelo LB para o servidor, depois pelo firewall para o LB para o servidor, etc. etc. sempre adicionando um componente.

2. Subtrativo: Continue removendo os 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é a máquina inicializar.

Dois pedaços de azar:

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

2. Quando tudo mais falhar, verifique se há coisas estúpidas. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Exemplo: Um problema louco simplesmente não pôde 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 novamente. Agora ele tinha um ^ M no final de cada linha. Nunca percebemos porque nosso editor de texto ocultou esse fato silenciosamente. Infelizmente, o software que leu o arquivo de configuração transformou essas ^ Ms em um espaço sem interrupção, que estragou muitos outros procedimentos.

Práticas gerais que eu lembro durante todo o processo:

1. Escreva tudo o que faço.
2. Faça apenas uma alteração de cada vez.
3. Se possível, inverta a alteração antes de tentar outra, a menos que haja um progresso definido.

Durante a soluçã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 está fazendo. Joe Richards explica por que muito melhor do que eu poderia neste curto espaço .
• Começo com a solução mais simples. Por exemplo, nenhuma conectividade de rede? Verifique a camada física. Não sei dizer quantas vezes os problemas de conexão intermitente não foram um problema no servidor, mas um cabo de rede que estava pela metade ou que estava com defeito.
• Tento capturar todos os sintomas que vejo de todas as fontes prováveis ​​antes de começar a fazer alterações.
• Eu corro testes de diagnóstico preliminares. Por exemplo, quando me dizem que um servidor está inoperante, a primeira coisa que faço é usar ping e nbtstat (Windows) para verificar isso. O problema pode estar no extremo distante (pedir emprestado um antigo ditado de controle técnico da Força Aérea).
• 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 à comunidade. Não apenas sites como serverfault.com, mas tenho uma boa variedade de pessoas em quem confio e respeito no Twitter em que mantenho contato.
• Eu avalio as respostas que estou encontrando com o que estou vendo. Não presumo que qualquer solução seja a correta, até que eu possa fazer considerações suficientes das evidências que estou vendo com o que é relatado na solução.

Atitudes que tento manter:

• Confiança absoluta de 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 pressionando, resolverei o problema (isso pode envolver levá-lo a alguém mais qualificado, aprender, pedir ajuda, trabalho duro, etc.).
• Resmungar sobre como uma instalação, programa ou cenário é mal projetado ou realmente estúpido simplesmente não ajuda, então não faça isso. (Acho isso difícil, resmungar é divertido).

Essas são atitudes que são úteis para mim - elas me impedem de levantar os braços no ar, declarar algo "bizarro" e depois desistir, ou ficar infeliz porque parece "insolúvel".

Maneiras de pensar na solução de problemas:

• Os sistemas têm muitas partes, se estiverem conectados juntos ou configurados aleatoriamente, eles não funcionarão como desejado. Existem uma ou duas configurações muito específicas que funcionarão - de todas as milhões de maneiras de empilhar tijolos e metais, apenas algumas são pontes e apenas uma ou duas são pontes suficientes. A causa pode ser um caractere em um arquivo de texto ou um servidor com falha, mas todas as partes precisam estar corretas para que tudo esteja certo. Eu preciso estar disposto a ser completo e meticuloso, se necessário. Os sistemas não podem "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 direção a outras; para condensá-lo até pontos que são locais com problemas de alta probabilidade e atacá-los. 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 de definir um comportamento como "OK" e outro como "um problema" é porque o que alguém está recebendo não é o que deseja. Você deve entender o que eles querem, o que estão recebendo de forma clara e específica.

O processo de solução de problemas:

• Qual é o problema. Certifique-se de vê-lo acontecendo e possa reproduzi-lo você mesmo, para que não haja falhas de comunicação. Muitas vezes, os problemas já passaram por várias pessoas em nosso serviço de assistência quando eles chegaram até mim, mas ninguém pode me explicar qual é realmente o problema.
• É uma bissecção recursiva mais uma vez - divida e conquiste, pesquisa binária - você cria um teste que prova se o problema é esse lado do teste ou esse lado, e faz o teste para que ele elimine o máximo 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 gastar horas aprendendo como o banco de dados é usado.
• É muito fácil me encontrar pensando "não sei o que fazer a seguir". Observe quando isso acontece e volte a apresentar testes que localizam o problema.

A Internet não está funcionando? Verifique o problema, encontre um site que eles não possam acessar. Testes rápidos envolvem a conexão à Internet (funcionando), isso carrega para mim (não). Testes rápidos apontam para o site. Ao ver o problema acontecer, afastei a probabilidade rapidamente do PC, navegador, DNS, firewall do escritório de contas de usuário etc.

Então o site não carrega, e agora? Ainda não é corrigível, então procure lugares para transformar o problema em um menor. O servidor está ligado? Ping? o DNS funciona? Sim. O serviço atende na porta 80? Não. O serviço está sendo executado? Não. Começa? Não. Dá erros no log de eventos / arquivos de log? Sim! O que eles dizem?

Trata-se de solução de problemas eficiente e rápida, pois concentra-se incansavelmente em restringir o escopo do problema. Se eu aceitasse o relatório de que a Internet não está funcionando, eu seria equivocado ao pensar que era uma falha de conexão. Se eu aceitasse meu primeiro avistamento de que ele não carrega, eu perderia tempo no computador deles, pensando que era um erro.

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

Entenda o sistema. Quanto mais conhecimento geral eu tiver sobre um sistema, mais fácil ele 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 alternativa do que uma correção, ou com uma grande e lenta correção lenta (reinstalar) do que uma pequena e precisa correção cirúrgica.

Geralmente pergunto "O que mudou que pode ter causado esse problema"? A maioria dos problemas é causada por alterações nas boas configurações conhecidas. Se você pode isolar quem fez a alteração, geralmente recebe sua resposta.

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

• Ter um bom entendimento básico 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-o guiar.

Certa vez, meu chefe me ligou com um engenheiro "sênior" ao telefone - ele estava me dizendo que tinha um servidor que não podia se conectar e que havia tentado trocar o cabo, mas ainda não tinha alegria. Eu ouvia um bipe no fundo como um no-break com baterias. Perguntei-lhe se ele podia ver atividade no interruptor, ele disse que não. Perguntei se o sinal sonoro vinha do no-break, ele disse que sim, perguntei se ele podia ver alguma luz acesa no rack e disse que não ... Olhe além do nariz - ajuda!

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

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.