Ici, vous devez isoler une erreur avec un test, comparer le résultat attendu au résultat réel et choisir la prochaine action. Cette méthode peut être appliquée à un programme, un conteneur ou un service réseau. Vous avez besoin d’une action utilisateur connue qui aurait dû fonctionner ainsi que l’accès pour examiner la solution concernée.

Commencez par les sept étapes et « Testez le prévu contre le réel », puis utilisez-les dans la Tâche 1. L’ordre des réseaux sert de support lorsque l’erreur concerne le réseau. Le tableau Linux/Proxmox est un exemple, et non des commandes à exécuter pour toutes les erreurs. L’autotest est un exercice facultatif.

Si vous souhaitez voir cette méthode appliquée à une erreur concrète, suivez modélisation du dépannage d’une application. Là-bas, justifiez votre prochain test avant d’afficher la proposition de réponse.

Les sept étapes

1. Cartographiez les circonstances. Qu’est-il arrivé et quand cela a-t-il commencé ?
2. Réproduisez l’erreur lorsque c’est sûr de le refaire.
3. Localisez et délimitez les sources d’erreurs possibles – quelle couche ou quel composant pourrait être en cause ?
4. Rassemblez des informations – journaux, messages d’erreur, résultats de commandes.
5. Déterminez les solutions possibles à partir de ce que vous savez maintenant.
6. Testez une solution ou une hypothèse à la fois. Si vous modifiez plusieurs choses simultanément, vous ne savez pas ce qui a réellement résolu le problème.
7. Documentez l’erreur et sa solution, afin que vous (ou quelqu’un d’autre) puissiez la reconnaître lors de la prochaine occurrence.

Ordre de dépannage pour le réseau et les services

Lorsque vous ne savez pas où se situe une erreur de réseau, cet ordre fournit un point de départ. Si vous avez déjà un résultat de test pertinent, utilisez-le pour choisir où poursuivre vos investigations. Vous n’avez pas besoin d’exécuter tous les tests réseau pour une erreur de code.

flowchart TD
    A[Connexion physique] --> B[Interface réseau]
    B --> C[Configuration IP]
    C --> D[Réseau local]
    D --> E[Passerelle et routage]
    E --> F[DNS]
    F --> G[Service]

Vidéo : Comment tester la connexion réseau avec ping

La vidéo montre comment utiliser ping pour vérifier si un appareil est accessible via le réseau.

Pour chaque point, vous devez être capable de :

• expliquer ce que le point de contrôle examine réellement
• trouver les valeurs pertinentes à l’aide de la bonne commande (voir [[Protocoles Niveau 1 - Protocoles réseau|🌐 Protocoles réseau]] pour ping, nslookup, etc.)
• distinguer une observation d’une supposition
• choisir le prochain contrôle basé sur le résultat du précédent, plutôt qu’intuitivement

Commandes par couche dans une machine virtuelle Linux sous Proxmox

Ceci est une application de la méthode lorsqu’une machine virtuelle Linux ne parvient pas à joindre un service. Exécutez les commandes pertinentes dans la Console de la VM, et non dans le Shell de l’hôte Proxmox. Consultez 🧭 Naviquer dans Proxmox VE si nécessaire. Choisissez le test correspondant à ce que vous investiguez ; le tableau n’est pas une exigence pour la Tâche 1.

En cas d’absence de route par défaut, investigatez comment la VM doit atteindre des cibles en dehors de son propre réseau ; certaines destinations peuvent avoir leurs propres routes. Certains réseaux bloquent ping, donc l’absence de réponse ne prouve à elle seule que la connexion est interrompue. Si la résolution de nom et les dépôts de paquets fonctionnent, vous avez des résultats concrets pour continuer. 🌐 IP, sous-réseau et passerelle par défaut explique l’adresse, le préfixe et la route.

Tester attendu contre réel

Un test de dépannement n’est utile que si vous savez ce à quoi vous vous attendez avant de l’exécuter. Notez :

Besoin :            Que l'utilisateur doit-il pouvoir faire ?
Objectif :          Quelle adresse/service testez-vous ?
Attendu :           Que se passe-t-il si tout fonctionne correctement ?
Réel :              Qu'est-ce qui s'est passé ?
Prouve :            Que prouve ce résultat ?
Ne prouve pas seul : Que ne prouve PAS ce résultat ?

Exercice 1 - Appliquer la méthode à un problème réel

Prenez un problème que vous avez rencontré dans une autre matière d’Exploitation ou de Développement (un conteneur qui ne démarre pas, un service auquel vous n’arrivez pas à communiquer, un script qui échoue) :

1. Passez par les sept étapes ci-dessus, une par une.
2. Écrivez « attendu contre constaté » pour chaque test que vous exécutez.
3. Notez quelle composante ou quelle couche le test délimite. Utilisez l’ordre réseau uniquement s’il convient au problème.
4. Essayez une correction justifiée dans un environnement de test où vous êtes autorisé à effectuer des modifications. Répétez l’action utilisateur initiale et vérifiez que la correction fonctionne réellement. Conservez un moyen de revenir à la configuration précédente.

Si vous n’avez aucune erreur disponible, vous pouvez analyser cet exemple : Une application renvoie la page attendue sur /, mais HTTP 404 sur /status. Que montrent ces deux réponses et qu’est-ce que vous examineriez en premier ? Les deux requêtes ont reçu une réponse HTTP ; le premier contrôle est de vérifier si /status existe effectivement dans l’application et si le client utilise la bonne route. L’exemple sert d’exercice d’analyse, il ne constitue pas une preuve que vous avez corrigé votre propre solution.

Point de contrôle : Le défaut est délimité et maîtrisé

Affichez le journal des tests et expliquez quelle observation a étayé le test suivant ou la correction. Après la correction, l’action initiale doit produire le résultat attendu. Vous pouvez vous expliquer à l’oral ou par écrit avec les commandes et les résultats devant vous. Si le défaut reste ouvert, indiquez ce qui a été testé, ce qui demeure incertain et un prochain test précis. N’écrivez pas une cause présumée comme confirmée.

Évaluez-vous-même

Auto-évaluation facultative avec retour d’information. Les réponses ne sont pas envoyées à l’instructeur. Utilisez votre propre journal de tests pour démontrer le dépannage réel ; l’évaluation par auto-test ne remplace pas la vérification pratique.

Résumé

• Le dépannage est une méthode, pas de la devinette – sept étapes fixes allant de l’identification à la documentation
• La bisection peut limiter un ensemble d’hypothèses lorsque vous connaissez les éléments utilisés par le test
• Pour les réseaux : utilisez les couches pour choisir un prochain test pertinent basé sur vos observations
• Notez toujours l’attendu vs le constaté avant de tester, et rappelez-vous qu’un seul test ne prouve rarement tout