Le temps d’arrêt est le temps pendant lequel un site web ne peut pas remplir sa fonction. Les visiteurs peuvent voir une page d’erreur, une page qui ne finit jamais de se charger ou un avertissement du navigateur. Ce qui compte, c’est le résultat : ils ne peuvent pas utiliser le site.
Le temps d’arrêt est le pendant de l’uptime. Un site avec 99,9 % d’uptime sur un mois de 30 jours a environ 43 minutes de temps d’arrêt.
Arrêt planifié et non planifié
Un arrêt planifié est choisi à l’avance. Les raisons typiques sont une migration de base de données, une mise à niveau de serveur ou une version majeure qui ne peut pas tourner à côté de l’ancienne. La bonne pratique est de le programmer aux heures creuses, de prévenir les utilisateurs et d’afficher une page de maintenance claire. Un serveur volontairement éteint pour maintenance répond souvent par 503 Service Unavailable, qui signale une situation temporaire et peut inclure un en-tête Retry-After indiquant aux clients quand revenir.
Un arrêt non planifié est tout le reste : les défaillances que personne n’a programmées. C’est celui qui fait mal, car il arrive sans prévenir et le chronomètre tourne jusqu’à ce que quelqu’un s’en aperçoive et corrige.
Les contrats et les rapports traitent souvent les deux différemment. De nombreux accords de niveau de service excluent du calcul la maintenance annoncée. Que cela s’applique à un site donné dépend entièrement de la formulation convenue.
Causes courantes
| Cause | Ce qui se passe | Ce que voit souvent un visiteur |
|---|---|---|
| Défaillance du serveur | La machine ou le serveur virtuel plante, manque de mémoire ou d’espace disque, ou est surchargé | Connexion refusée, délai d’attente dépassé ou erreur 5xx |
| Problème réseau | Une liaison, une règle de pare-feu ou une panne chez un fournisseur coupe le trafic entre le visiteur et le serveur | Délai d’attente dépassé, « le site est inaccessible » |
| Problème DNS | Le nom de domaine ne se résout pas, parce qu’un enregistrement est faux ou supprimé, ou que le domaine a expiré | « Serveur introuvable » |
| Problème de certificat | Le certificat TLS a expiré ou ne correspond pas au domaine | Un avertissement de sécurité du navigateur en pleine page |
| Défaillance de l’application | Un bogue, un déploiement raté ou une dépendance cassée fait planter l’application | Une erreur 500, ou une page blanche |
| Surcharge | Un pic de trafic ou une tâche lourde consomme toute la capacité disponible | Pages très lentes, erreurs 503 ou 504 |
| Dépendance à un service tiers | Un service de paiement, de connexion ou de base de données dont le site dépend cesse de répondre | Une page qui s’affiche, mais dont une fonction échoue |
De nombreuses pannes combinent plusieurs causes. Un serveur surchargé tombe, et le redémarrage est retardé par un certificat expiré sur le serveur de secours. Regarder la première défaillance compte généralement plus que le dernier symptôme.
Comment le temps d’arrêt apparaît en HTTP
Quand un visiteur charge une page, le serveur renvoie un code d’état HTTP. Les codes de la famille 5xx, comme 500, 502, 503 et 504, signalent que le serveur a échoué. Si le serveur est tout simplement injoignable, il n’y a pas de code d’état, seulement un délai d’attente dépassé ou une erreur de connexion. Le sens de chaque famille est détaillé dans codes d’état HTTP.
Ce qu’une vérification par requête web ne voit pas
C’est la limite la plus importante à comprendre. Une vérification de surveillance qui demande une page et lit la réponse ne peut rapporter que ce que dit le serveur. Elle ne peut pas savoir si le site fonctionne.
Un serveur peut renvoyer 200 OK alors que :
- le panier échoue quand quelqu’un clique sur « ajouter »,
- le formulaire de connexion rejette tous les mots de passe,
- la page se charge mais est vide parce qu’un appel au serveur d’arrière-plan a échoué,
- un message d’erreur s’affiche au milieu d’une page par ailleurs normale.
Du point de vue du moniteur, le site est en ligne. Du point de vue d’un client, il est en panne. Détecter ces défaillances demande des vérifications qui suivent de vrais parcours d’utilisateur, ou des alertes au niveau de l’application, ou les deux. Une simple vérification d’adresse est une première ligne de défense fiable contre les pannes où le serveur ne répond pas ou répond par une erreur, et rien de plus.
Conséquences
Les effets du temps d’arrêt dépendent de la fonction du site :
- Perte de chiffre d’affaires quand les clients ne peuvent ni commander ni payer.
- Perte de confiance quand les utilisateurs tombent sur une erreur là où ils attendaient un service.
- Charge pour le support quand les gens demandent si le problème vient de chez eux.
- Pénalités contractuelles quand un accord définit des objectifs de disponibilité et des crédits.
Détecter et rétablir
Trois choses raccourcissent le temps d’arrêt : le remarquer vite, comprendre la cause et avoir un moyen de revenir en arrière.
- Détecter. Un moniteur vérifie le site à intervalle régulier et déclenche une alerte après des échecs répétés, afin qu’une seule requête perdue ne réveille personne. UptimeWire, par exemple, répète deux fois une vérification échouée, à environ 20 secondes d’écart, avant d’ouvrir un incident.
- Diagnostiquer. La vérification échouée enregistre une raison, comme un délai d’attente dépassé, une erreur de connexion ou un code d’état. Cela restreint la recherche : une erreur DNS et une erreur 500 mènent à des endroits complètement différents.
- Rétablir. Les remèdes courants sont de redémarrer un service, d’annuler une version, de restaurer un certificat ou de corriger un enregistrement DNS. Dès que le site répond de nouveau correctement, les vérifications passent et l’incident se ferme.
- Apprendre. Une courte note sur la cause et la correction, conservée avec l’incident, aide la fois suivante.
Le temps écoulé entre le début de la panne et le moment où quelqu’un l’apprend fait aussi partie du temps d’arrêt. C’est pourquoi l’intervalle de vérification compte : un site vérifié toutes les minutes peut être remarqué plus tôt qu’un site vérifié toutes les dix minutes.