Modèles de panne
Problèmes courants de disponibilité des sites web
Comprenez les couches fréquentes derrière les incidents de disponibilité : erreurs DNS, échecs de confiance SSL, ports fermés, applications surchargées et problèmes propres à une route.
La plupart des incidents de disponibilité deviennent moins mystérieux quand on les classe par couche. La difficulté vient du fait que les utilisateurs les décrivent tous de la même façon : « le site est indisponible ». En diagnostic, cette phrase peut désigner un enregistrement DNS cassé, un service arrêté sur 443, un certificat expiré, une origine surchargée qui renvoie 503 ou un problème de route régional.
Des pannes différentes se ressemblent pour les utilisateurs
Une page d'erreur navigateur, un délai dépassé vide et un 503 peuvent tous être signalés comme « indisponible », alors qu'ils viennent de couches différentes.
Le classement par couche fait gagner du temps
Une fois la couche identifiée, DNS, connexion, TLS, HTTP ou routage, l'outil suivant et le responsable probable deviennent plus clairs.
Un rapport doit mener à une action suivante
Le but du diagnostic n'est pas de collecter toutes les données possibles, mais de réduire le problème assez vite pour rendre la prochaine vérification évidente.
01
Les grandes familles de problèmes de disponibilité
Ces groupes couvrent la plupart des incidents pratiques observés sur les sites publics.
Problèmes de résolution de nom
Le nom d'hôte ne se résout pas correctement, pointe au mauvais endroit ou varie à cause de données DNS obsolètes ou incohérentes.
Problèmes de disponibilité du service
L'hôte cible peut exister, mais le port web attendu est fermé, filtré, refusé ou en délai dépassé depuis un point de test.
Problèmes de confiance TLS
Le service est assez joignable pour démarrer HTTPS, mais le certificat, le nom d'hôte, la chaîne ou la négociation bloque une session de confiance.
Problèmes au niveau applicatif
La requête atteint le site, mais le résultat HTTP final montre une erreur serveur, une surcharge, une maintenance ou une restriction d'accès.
02
Symptôme, couche probable et meilleur premier contrôle
Utilisez cette carte de triage quand le signalement d'un collègue ou client reste vague.
| Symptôme | Couche probable | Meilleur premier contrôle |
|---|---|---|
| Le nom d'hôte ne se résout pas ou se résout étrangement | DNS | Vérificateur de site, puis Recherche DNS |
| Le navigateur signale un certificat ou une confiance HTTPS | TLS / SSL | Vérificateur SSL, puis vérificateur de site |
| Connexion refusée ou délai dépassé sur 80/443 | Port ou disponibilité réseau | Vérificateur de port, puis Ping ou Traceroute |
| Le site répond 403, 429, 500, 502, 503 ou 504 | Application / CDN / amont | Vérificateur de site, puis hébergement ou suivi SSL/DNS si nécessaire |
| Seuls certains utilisateurs ou régions se plaignent | Routage, propagation DNS, géo ou politique | Vérificateur de site puis validation depuis un autre environnement |
03
Une séquence de triage propre
Elle évite de passer d'un outil à l'autre sans apprendre quoi que ce soit de nouveau.
Commencez par l'URL exacte qui échoue
Utilisez le vrai nom d'hôte, le schéma et le chemin quand c'est possible afin que redirections et certificat restent pertinents.
Classez la première couche d'échec
Décidez si le premier signal sérieux pointe vers DNS, connexion, TLS ou réponse HTTP/applicative.
Ouvrez un seul outil de suivi dédié
Utilisez Recherche DNS, le vérificateur SSL, le vérificateur de port, Ping ou Traceroute seulement après que le premier passage large a identifié la couche à examiner.
Vérifiez si le résultat peut être lié à une localisation
Si seuls certains utilisateurs se plaignent ou si le site est derrière un CDN ou une politique régionale, gardez la limite des sondes en tête avant de généraliser.
04
Signaux qui induisent souvent en erreur
Ce sont des observations techniquement vraies qui orientent pourtant vers le mauvais diagnostic.
- « Ping fonctionne, donc le site doit aller bien. »
- « Le certificat est valide, donc HTTPS ne peut pas être le problème. »
- « DNS répond, donc la panne est forcément dans l'application. »
- « Le site échoue depuis une ou deux sondes ici, donc il est indisponible pour tout le monde. »
05
Meilleurs outils pour resserrer les problèmes courants
Choisissez l'outil qui correspond à la famille de problème la plus probable.
Meilleur premier passage quand vous savez seulement qu'une URL semble cassée et qu'il faut une classification sérieuse rapide.
Vérificateur de site webRéponses DNS structuréesUtilisez Recherche DNS pour les problèmes de nomOuvrez-la après des IP incorrectes, réponses vides, NXDOMAIN ou problèmes de propagation ou délégation supposés.
Recherche DNSCertificat et TLSUtilisez le vérificateur SSL pour les échecs de confiance HTTPSIdéal pour le cycle de vie des certificats, la couverture des noms, les certificats auto-signés et la visibilité de protocole.
Vérificateur SSLDisponibilité TCPUtilisez le vérificateur de port pour la couche connexionUtile quand 80 ou 443 peut être fermé, filtré ou ne pas écouter depuis un point de test.
Vérificateur de port