Vos règles de dépannage, approche du dépannage? [fermé]

Avez-vous des règles générales sur lesquelles vous vous rabattez lorsque vous dépannez un problème réseau / matériel / logiciel difficile?

Par exemple: "J'isoler la source du problème en testant un périphérique avec un deuxième ordinateur" ou "Je supprime autant de matériel que possible pour allumer l'appareil, puis rajouter des composants un par un jusqu'à ce que je puisse reproduire le problème" , etc.

Juste une liste de points que je me suis notés après avoir lutté avec un problème pendant un certain temps:

1. Quel est votre objectif principal ? Doit être énoncé de façon claire et concise. L'objectif doit être très particulier. Cela ne devrait pas être général. De préférence une phrase .
   
2. Quel est votre problème ?
   
3. Y a-t-il un ou plusieurs problèmes ? S'il y en a plusieurs, résolvez-les un par un.
   
4. Essayez de reproduire le problème dans différentes conditions . Peut-il être reproduit dans toutes les conditions possibles ou non? Cela dit-il quelque chose sur la nature du problème?
   
5. S'il s'agit d'un problème urgent, y a-t-il une solution de contournement ? Essayez de trouver autant de solutions de contournement que possible.
   
6. Essayez de faire autant de suppositions que possible sur la cause de votre problème.
   
7. Essayez de prouver vos suppositions, expérimentez le système.
   
8. Soyez cohérent dans ce que vous essayez de faire. Faites une chose à la fois.
   
9. Gardez une trace de ce que vous faites, de ce que vous avez déjà essayé.
   
10. Ne vous écartez pas de votre objectif principal. Vérifiez constamment si vous résolvez toujours votre problème principal, pas différent.
    
11. Ne fixez pas non plus.

Il y avait aussi une grande liste de règles de débogage, c'était sous forme PDF avec des exemples et des explications pour chacune des règles. Je n'ai pas pu trouver rapidement le PDF, mais je pense que c'est une affiche de la liste:

• Si le problème est lié à Internet, c'est probablement le DNS.

• Si le problème est difficile à diagnostiquer, c'est probablement la RAM.

• Si le problème vient d'un poste de travail Windows, il est probablement plus rapide de le recréer.

• Si le problème est un vendredi, c'est probablement quelque chose de grave.

J'aime revenir à la méthode scientifique .

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

1. Définissez la question
2. Recueillir des informations et des ressources (observer)
3. Hypothèse de forme
4. Effectuer des expériences et collecter des données
5. Analyser les données
6. Interpréter les données et tirer des conclusions qui servent de point de départ à de nouvelles hypothèses
7. Documenter les résultats

En règle générale, j'aime toujours essayer de vérifier mes hypothèses de base. Est-ce qu'il a du courant, est-il branché, le câblage est-il bon? Il est très ennuyeux de passer des heures à essayer de résoudre un problème logiciel lorsque vous avez un câble lâche.

Je trouve très important pendant la phase de création de l'hypothèse de trouver autant de causes possibles du problème que possible. Ensuite, j'essaie de choisir les idées à tester en premier en fonction de la facilité de test et de la probabilité de l'idée.

Il est également important d'obtenir de l'aide. Consultez vos collègues, votre fournisseur ou la personne qui connaît le mieux les systèmes en question si vous le pouvez. Ne passez pas beaucoup de temps à faire tourner vos roues sur un problème s'il y a quelqu'un qui peut vous aider à résoudre le problème.

O'Reilly a un bon livre Network Troubleshooting Tools qui a un bon ensemble d'étapes à suivre qui est très similaire à la méthode scientifique. J'ai trouvé le livre très utile et le recommande vivement. Le livre est beaucoup plus détaillé et propose de nombreux outils utiles.

Depuis les outils de dépannage réseau

1. Énoncez votre objectif
2. Définir le système
3. Identifier les résultats possibles
4. Identifiez et sélectionnez ce que vous mesurerez
5. Le cas échéant, identifier les paramètres et les facteurs du test
6. Sélectionnez les outils
7. Établir des contraintes de mesure
8. Revoir la conception expérimentale
9. Collecter des données
10. Analyser les données

Voir également:

• 3COM a un guide de dépannage
• La loi de Murphy - Tout ce qui peut mal tourner, oui.
• Occam's_razor - Toutes choses étant égales par ailleurs, la solution la plus simple est la meilleure.

(Ces faits saillants sont paraphrasés du chapitre "Débogage" de "La pratique de l'administration système et réseau" )

Deux choses à savoir:

1. Sachez à quoi ressemble la version "fixe". De préférence, une commande que vous pouvez exécuter qui donne une certaine sortie lorsque les choses fonctionnent. Par exemple: j'essaie de comprendre pourquoi SSH demande un mot de passe lorsque j'ai correctement configuré les clés (ou du moins je le pensais). Donc mon test est: "upsime de nom de serveur ssh" et cela devrait fonctionner sans demander de mot de passe.

2. Décrivez le problème au bon niveau. Un utilisateur se plaignant de ne pas pouvoir envoyer une requête ping à un serveur ne doit pas vous envoyer pour exécuter et réparer le serveur. Le travail de la personne n'est pas de rester assis et de cingler une machine toute la journée. Ils veulent faire une sorte de tâche comme utiliser la machine comme serveur DNS. Exemple: une fois qu'un utilisateur s'est plaint qu'il ne pouvait pas envoyer de ping à une machine à l'autre bout du monde. Je passe la journée à rechercher des administrateurs système dans cette partie de l'entreprise pour découvrir ce qui n'allait pas avec cette machine. Il a été mis hors service et ils paniquaient parce qu'ils pensaient peut-être qu'ils avaient éteint la mauvaise machine. J'ai contacté l'utilisateur et lui ai dit "en plus d'avoir besoin de faire un ping sur cette machine, que voudriez-vous en faire?". Il s'est avéré qu'il voulait exécuter un certain travail dessus et s'il avait suivi la procédure appropriée, ses tâches auraient été automatiquement redirigées vers la machine de remplacement. J'avais perdu toute ma journée et le temps des administrateurs système locaux. Une autre raison pour laquelle «je ne peux pas faire de ping» n'est pas la bonne chose à tester: les pare-feu sont souvent configurés pour supprimer les paquets ping mais autoriser le passage d'autres paquets. Testez ce que vous voulez vivre.

Deux stratégies:

1. Additif: Continuez à ajouter des composants jusqu'au début du problème. La dernière chose que vous avez ajoutée est le problème. Exemple: les navigateurs Web ne peuvent pas parler à un serveur. Entre le serveur et l'utilisateur se trouve un équilibreur de charge, un pare-feu, un cache et le proxy Web local de l'utilisateur. Essayez d'abord d'envoyer des requêtes directement au serveur, puis à travers le LB au serveur, puis à travers le pare-feu au LB au serveur, etc. etc. à chaque fois en ajoutant un composant.

2. Soustractif: Continuez à retirer les composants jusqu'à ce que le problème disparaisse. La dernière chose que vous avez supprimée est le problème: Exemple: une machine avec des dizaines de cartes ne démarre pas. Continuez à retirer les cartes jusqu'à ce que la machine démarre.

Deux morceaux de chance stupide:

1. Oubliez tout ce que j'ai dit. Le problème est dû à la dernière modification apportée au système. (cela fonctionne 99% du temps ... le problème est que 99% du temps vous ne savez pas quel était le dernier changement)

2. Lorsque tout le reste échoue, vérifiez les choses stupides. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Exemple: un problème fou ne pouvait tout simplement pas être expliqué. Ensuite, nous avons vérifié le fichier de configuration: un utilisateur l'avait modifié en le copiant dans une boîte Windows, en le modifiant, puis en le recopiant. Il avait maintenant un ^ M à la fin de chaque ligne. Nous ne l'avons jamais remarqué car notre éditeur de texte a caché ce fait en silence. Malheureusement, le logiciel qui a lu le fichier de configuration a transformé ces ^ Ms en un espace incassable qui a gâché des tonnes d'autres procédures.

Pratiques générales dont je me souviens tout au long du processus:

1. Écrivez tout ce que je fais.
2. Faites un seul changement à la fois.
3. Si possible, annulez le changement avant d'en essayer un autre à moins que des progrès définitifs ne soient réalisés.

Lors du dépannage, voici ma méthodologie de base:

• Lorsque le système fonctionne correctement, avant qu'il n'y ait un problème, j'essaie d'apprendre à voir ce qu'il fait. Joe Richards explique pourquoi beaucoup mieux que moi dans ce court espace .
• Je commence par la solution la plus simple. Par exemple, pas de connectivité réseau? Vérifiez la couche physique. Je ne peux pas vous dire combien de fois les problèmes de connexion intermittents n'étaient pas un problème de serveur mais un câble réseau à moitié enfoncé ou défectueux.
• J'essaie de capturer tous les symptômes que je peux voir à partir de toutes les sources probables avant de commencer à apporter des modifications.
• Je lance des tests de diagnostic préliminaires. Par exemple, quand on me dit qu'un serveur est en panne, la première chose que je fais est d'utiliser ping et nbtstat (Windows) pour le vérifier. Le problème pourrait être à l'autre bout (pour emprunter un vieux dicton de contrôle technique de l'Air Force).
• Je n'ai pas peur de faire des recherches. Google, support.microsoft.com, eventid.net et des sites comme celui-ci sont vos amis.
• Je n'ai pas peur de demander de l'aide à la communauté. Pas seulement des sites comme serverfault.com, mais j'ai un bon assortiment de personnes en qui j'ai confiance et que je respecte sur Twitter avec qui je reste en contact.
• J'évalue les réponses que je trouve avec ce que je vois. Je ne suppose pas qu'une solution soit la bonne jusqu'à ce que je puisse faire suffisamment de réflexion sur les preuves que je vois avec ce qui est rapporté dans la solution.

Attitudes que j'essaie de maintenir:

• Une confiance absolue que la cause et l'effet fonctionnent et que rien n'est magique. Il ne se passe rien de vraiment bizarre, seulement des choses que je ne comprends pas.
• Confiance absolue que si je continue à pousser, je vais le résoudre (cela peut impliquer de le porter à quelqu'un de plus compétent, d'apprendre, de demander de l'aide, de travailler dur, etc.).
• Grogner sur la façon dont une configuration, un programme ou un scénario est mal conçu ou vraiment stupide n'aide pas, alors ne le faites pas. (Je trouve ça dur, marmonner est amusant).

Ce sont des attitudes qui me sont utiles à retenir - elles m'empêchent de lever les bras en l'air, de déclarer quelque chose de "bizarre" puis d'abandonner, ou d'être malheureuse parce que cela semble "insoluble".

Façons dont je pense au dépannage:

• Les systèmes ont beaucoup de pièces, s'ils sont connectés ensemble ou configurés de manière aléatoire, ils ne fonctionneront pas comme vous le souhaitez. Il existe une ou deux configurations très spécifiques qui fonctionneront - de toutes les millions de façons d'empiler des briques et du métal, seules quelques-unes sont des ponts et seulement une ou deux sont des ponts assez bons. La cause peut être un caractère dans un fichier texte ou un serveur défaillant, mais chaque partie doit être correcte pour que tout soit correct. Je dois être prêt à être minutieux et méticuleux si nécessaire. Les systèmes ne peuvent pas faire "le spectacle doit continuer".
• Vous commencez avec un système entier comme une carte, vous imaginez un nuage de probabilité flottant sur la carte représentant "où est le problème" et votre travail consiste à utiliser l'expérience et à trouver des tests pour éloigner la probabilité de certaines zones et vers d'autres et pour le condenser en points qui sont des emplacements de problème à forte probabilité, puis attaquez-les. Cela revient au point de cause à effet - le problème est dans le système, ce n'est pas magique. C'est un problème qui existe donc il doit exister quelque part.
• Tout peut être configuré comme bon vous semble. La seule façon de définir un comportement comme "OK" et un autre comme "un problème" est que ce que quelqu'un obtient n'est pas ce qu'il veut. Vous devez comprendre ce qu'ils veulent, ce qu'ils obtiennent clairement et spécifiquement.

Le processus de dépannage:

• Quel est le problème. Assurez-vous que cela se produit et que vous pouvez le reproduire vous-même afin qu'il n'y ait aucun problème de communication. Donc, souvent, des problèmes ont été rencontrés par plusieurs personnes de notre service d'assistance au moment où ils me parviennent encore, personne ne peut m'expliquer quel est réellement le problème.
• C'est une bissection récursive à nouveau - diviser pour mieux régner, recherche binaire - vous trouvez un test qui prouvera si le problème est de ce côté du test, ou de ce côté, et faites le test pour qu'il élimine autant que possible. Répétez jusqu'à résolution.
• N'apprenez pas si vous pouvez l'éviter - mieux vaut verrouiller le compte de la base de données et prouver que le problème persiste lorsque la base de données n'est pas impliquée que de passer des heures à apprendre comment la base de données est utilisée.
• C'est beaucoup trop facile de me retrouver à penser "Je ne sais pas quoi faire ensuite". Notez quand cela se produit et revenez à proposer des tests qui localisent le problème.

Internet ne fonctionne pas? Vérifiez le problème, trouvez que c'est un site Web auquel ils ne peuvent pas accéder. Les tests rapides impliquent leur connexion Internet (fonctionne), ça se charge pour moi (non). Des tests rapides indiquent qu'il s'agit du site. En voyant le problème se produire pour moi, j'ai éloigné rapidement la probabilité de leur PC, navigateur, DNS, pare-feu de bureau de compte d'utilisateur, etc.

Donc, le site ne se charge pas, maintenant quoi? Ce n'est pas encore réparable, alors recherchez des endroits pour résoudre le problème en un plus petit. Le serveur est-il allumé? Est-ce que ça cingle? fonctionne DNS? Oui. Le service répond-il sur le port 80? Non. Le service fonctionne-t-il? Non. Ça commence? Non. Cela donne-t-il des erreurs dans le journal des événements / fichiers journaux? Oui! Qu'est-ce-qu'ils disent?

Il s'agit d'un dépannage efficace et rapide car il se concentre sans relâche sur la réduction de l'étendue du problème. Si j'acceptais leur rapport selon lequel Internet ne fonctionne pas, je serais induit en erreur en pensant qu'il s'agit d'un échec de connexion. Si j'acceptais ma première observation qu'il ne se charge pas pour eux, je perdrais du temps sur leur ordinateur en pensant qu'il est en faute.

Découpez des morceaux de "choses qui ne peuvent pas être" aussi gros que possible.

Comprenez le système. Plus j'ai de connaissances générales sur un système, plus c'est facile. Là où j'ai une mauvaise compréhension, les problèmes sont plus intimidants, plus difficiles, plus lents et plus susceptibles de se retrouver avec une solution de contournement qu'un correctif, ou avec un gros correctif lent (réinstaller) qu'un petit correctif chirurgical.

En général, je demande "Qu'est-ce qui a changé qui pourrait avoir causé ce problème"? La plupart des problèmes sont causés par des modifications de bonnes configurations connues. Si vous pouvez isoler qui a effectué le changement, vous obtenez généralement votre réponse.

Je pense que c'est une compétence, pas une science. Il y a des moments où vous suivez le mauvais chemin, mais pour la plupart:

• Avoir une bonne compréhension de base de toutes les technologies associées - réseau, matériel, système d'exploitation, logiciel, développement, etc. - vous aidera à éliminer certains de ces "mauvais chemins"
• pensez basique - ne sautez pas dans le scénario le plus compliqué parce que c'est dans votre tête, effectuez votre dépannage de base et laissez-le vous guider.

Une fois, mon patron m'a appelé avec un ingénieur "senior" au téléphone - il me disait qu'il avait un serveur qui ne pouvait pas se connecter et il avait essayé de changer le câble mais toujours pas de joie. J'entendais un bip à l'arrière-plan comme un onduleur sur batterie. Je lui ai demandé s'il pouvait voir une activité sur l'interrupteur, il a dit non. Je lui ai demandé si le bip provenait de l'onduleur, il a dit oui, je lui ai demandé s'il pouvait voir des lumières allumées dans le rack, il a dit non ... Regardez au-delà de votre nez - ça aide!

Je commence par vérifier l'évidence. Y a-t-il un message d'erreur expliquant quel est le problème? Tout est-il correctement connecté? Je n'aime pas perdre plusieurs heures à dépanner quelque chose qui aurait pu être résolu en quelques minutes. Je pense qu'il est possible d'être trop méthodique. J'ai vu des gens perdre une journée entière à reproduire un problème malgré le fait que je leur ai dit précisément quel était le problème. Ce n'est pas pour ça que je les paie.

Si la réponse n'est pas évidente, alignez certains suspects et testez-les d'abord. Ce n'est qu'après avoir testé les suspects probables que vous devez tester les suspects improbables. Ensuite, vous pouvez être aussi scientifique que vous le souhaitez.