B2-32 Incidents et dépannage méthodique

1. Incident, problème, demande : bien nommer les choses

Au support, tout ce qui arrive ressemble à « un souci ». Pourtant, le traitement n'est pas le même selon la nature de l'appel. Le référentiel de bonnes pratiques ITIL, utilisé par la plupart des services informatiques, distingue trois catégories.

1.1 Priorité = urgence × impact

Plusieurs tickets arrivent en même temps : lequel traiter d'abord ? On croise l'impact (combien de personnes ou de services sont touchés) et l'urgence (à quelle vitesse la situation devient grave pour l'entreprise). La gestion complète des tickets est vue dans le Bloc 1 (B1-06) ; ici, retiens la grille.

2. La démarche de diagnostic en six temps

Face à un incident, le réflexe du débutant est de tout essayer en même temps : redémarrer, changer une adresse, débrancher un câble… Si la panne disparaît, il ne sait pas pourquoi ; si elle empire, il ne sait plus revenir en arrière. Le technicien méthodique suit toujours le même cycle, un changement à la fois.

3. Chercher avec méthode : couche par couche

Le modèle OSI n'est pas qu'une leçon à réciter : c'est une check-list de dépannage. Chaque couche dépend de celle du dessous. Un service web ne peut pas fonctionner si l'adresse IP est fausse, et une adresse IP juste ne sert à rien si le câble est débranché.

3.1 Trois méthodes, trois situations

3.2 Diviser pour régner sur le chemin

La même idée s'applique au chemin du paquet : on teste les points de passage en partant du plus proche, pour trouver le premier qui ne répond plus.

4. Les outils du diagnostic

4.1 Lire un ping

C:\> ping 172.16.20.254

Envoi d'une requête 'Ping'  172.16.20.254 avec 32 octets de données :
Réponse de 172.16.20.254 : octets=32 temps=1 ms TTL=255
Réponse de 172.16.20.254 : octets=32 temps<1ms TTL=255
Réponse de 172.16.20.254 : octets=32 temps<1ms TTL=255
Réponse de 172.16.20.254 : octets=32 temps<1ms TTL=255

Statistiques Ping pour 172.16.20.254:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),

• Réponse de …La destination a répondu : le chemin aller et retour fonctionne jusqu'à elle (couches 1 à 3).
• tempsDurée de l'aller-retour. Sur un réseau local, moins de 1 à 2 ms ; des centaines de millisecondes signalent une saturation ou un lien lointain.
• TTLDurée de vie restante du paquet. Elle part de 255 (Cisco), 128 (Windows) ou 64 (Linux) et perd 1 à chaque routeur : elle trahit le système et la distance.
• pertePourcentage de paquets sans réponse. Une perte partielle (25 %, 50 %) évoque un câble abîmé, un lien Wi-Fi faible ou une saturation.

4.2 Lire un tracert

C:\> tracert -d 172.16.60.10
Détermination de l'itinéraire vers 172.16.60.10 avec un maximum de 30 sauts.
  1    <1 ms    <1 ms    <1 ms  172.16.20.254
  2     *        *        *     Délai d'attente de la demande dépassé.
  3     *        *        *     Délai d'attente de la demande dépassé.

Le premier saut (la passerelle R1) répond, le deuxième (R2, à Rennes) jamais : le paquet quitte bien le siège mais se perd après R1. On examine la liaison WAN et la table de routage de R1. L'option -d évite d'attendre la résolution DNS de chaque routeur.

5. Dépanner : pannes typiques et entraînement

5.1 Les pannes les plus fréquentes, couche par couche

5.2 Le diagnostic guidé : « mon poste n'accède à rien »

5.3 Entraîne-toi : les tickets du support

Tu es de permanence au support de Brocéliande Logistique. Six tickets arrivent les uns après les autres : lis le message, observe le relevé, puis choisis la cause. Applique la démarche : symptômes, couche concernée, preuve.

SW1# show ip interface brief | include 0/5
FastEthernet0/5        unassigned      YES unset  down                  down

C:\> ping 172.16.50.20
Réponse de 172.16.50.20 : octets=32 temps<1ms TTL=127
C:\> nslookup intranet.broceliande.lan
Serveur :   dns.google
Address:  8.8.8.8
*** dns.google ne parvient pas à trouver intranet.broceliande.lan

R1# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     unassigned      YES unset  administratively down down
GigabitEthernet0/1     203.0.113.2     YES manual up                    up

C:\> arp -a | findstr 172.16.30.40
  172.16.30.40     00-1b-21-3a-4c-10     dynamique
  (5 minutes plus tard)
  172.16.30.40     00-0c-29-77-e2-01     dynamique

PS> Test-NetConnection 172.16.50.10 -Port 445
ComputerName     : 172.16.50.10
RemotePort       : 445
PingSucceeded    : True
TcpTestSucceeded : False

#2310  02/10  Salle réunion : plus de réseau   Résolu : câble rebranché
#2366  09/10  Salle réunion : plus de réseau   Résolu : câble rebranché
#2402  14/10  Salle réunion : plus de réseau   Résolu : câble rebranché

6. Le compte rendu d'incident

Un incident résolu sans trace écrite est un incident à moitié traité : la prochaine fois, le collègue recommencera tout le diagnostic. Le compte rendu se rédige dans le ticket, en quelques lignes précises, au moment de la clôture.

• SymptômesCe que l'utilisateur a constaté, avec le message exact, l'heure et les personnes touchées.
• DiagnosticLes tests réalisés dans l'ordre, avec leur résultat : c'est la preuve qui mène à la cause.
• CauseLa cause identifiée, en une phrase, et la couche concernée.
• SolutionLa correction appliquée, et la vérification faite avec l'utilisateur.
• Suite à donnerRien, ou « ouvrir un problème », « mettre à jour la documentation », « prévoir le remplacement ».

Symptômes  : 14/10, 9 h 40. PC-COMPTA (Mme Morel) n'ouvre plus le partage
             \\SRV-01\Compta ; Internet fonctionne. Seul ce poste est touché.
Diagnostic : ipconfig /all : 172.16.20.31/24, passerelle .254, DNS 8.8.8.8 (anormal).
             ping 172.16.50.10 : OK. nslookup srv-01 : nom introuvable.
Cause      : DNS public saisi à la main sur le poste (couche application / DNS).
Solution   : carte remise en DHCP, ipconfig /renew et /flushdns ; partage ouvert
             devant l'utilisatrice à 9 h 55.
Suite      : aucune. Rappel aux techniciens : jamais de DNS public sur un poste du domaine.

7. À l'examen et en entreprise

8. L'essentiel

1. Incident : service interrompu, à rétablir vite ; problème : cause d'incidents répétés, à éliminer ; demande : besoin standard prévu.
2. Priorité = urgence × impact, jamais « celui qui appelle le plus fort ».
3. Trois questions d'ouverture : qui est touché, depuis quand, qu'est-ce qui a changé ?
4. Cycle : recueillir, reproduire, hypothèses, tester, corriger et vérifier, documenter.
5. Un seul changement à la fois, et on annule ce qui n'a rien résolu.
6. De bas en haut pour une panne totale, de haut en bas pour une seule application, diviser pour régner (un ping) pour aller vite.
7. Le long du chemin, chaque test réussi innocente tout ce qui se trouve avant le point testé.
8. ping par adresse OK mais pas par nom : c'est le DNS. 169.254.x.x : c'est le DHCP.
9. « administratively down » = un shutdown a été tapé ; « down / down » seul = pas de signal (câble).
10. Compte rendu : symptômes, diagnostic (tests et résultats), cause, solution vérifiée, suite à donner.

Les commandes clés

Tout cela tient sur une page : utilise le bouton Mémo à imprimer en haut de la fiche.

9. Quiz noté

10. Exercices : à toi de répondre

Écris ta réponse sous chaque énoncé et envoie-la à ton professeur. Quand il l'a validée, le corrigé s'affiche à la place du cadenas ; s'il te la renvoie « à revoir », lis son commentaire et corrige.

11. Fil rouge : les pannes cachées

SW1# show cdp neighbors
Device ID    Local Intrfce   Holdtme   Capability   Platform    Port ID
R1           Gig 0/1         152       R S I        CISCO1941   Gig 0/0
(SW2 n'apparaît plus : le lien Gig 0/2 est coupé ou débranché)