Le site fonctionne-t-il ? Uptime et gestion des incidents
À quelle vitesse une entreprise remarque que son site est en panne : surveillance uptime, chaîne d'alerte et un vrai post-mortem, expliqués simplement.
Équipe rabbitclipPublié: 5 min de lecture
En bref
La surveillance uptime est un contrôle externe qui tourne selon un planning et enregistre si un site ou une application répond vraiment. Un contrôle basique regarde seulement si la page d'accueil se charge ; une configuration plus fiable teste une vraie transaction, paiement, connexion, envoi d'un formulaire, selon le même planning. L'idée est de repérer une panne avant qu'un client ne le fasse, et cela ne marche que si une alerte est définie à l'avance : qui elle atteint, sur quel canal, en combien de temps.
Si la page de paiement d'un fabricant de vêtements de travail se met à renvoyer des erreurs un dimanche matin, cela peut passer inaperçu pendant des heures si une réclamation client en est le premier signe. Un contrôle qui surveille le parcours de paiement lui-même détecte la même panne en quelques minutes et alerte la bonne personne ; la différence se situe entre une perte de plusieurs heures et une réaction de quelques minutes.
Que mesure vraiment la surveillance uptime ?
La surveillance uptime est l'enregistrement du fait qu'un serveur ou une page, interrogé depuis un point de contrôle externe selon un planning, généralement toutes les une à cinq minutes, répond du tout. La réponse doit à la fois exister et porter le contenu attendu, le bon code de statut, un texte précis sur la page ; qu'un serveur soit simplement joignable ne suffit pas en soi, la page doit réellement fonctionner.
Ce type de contrôle repère bien un serveur totalement en panne ou qui ne répond plus, mais ne détecte pas toujours un ralentissement, une erreur partielle, ou un problème qui n'apparaît que sur un seul navigateur. C'est pourquoi la surveillance uptime vient s'ajouter au suivi d'erreurs et à la surveillance de performance, pas les remplacer.
Quel contrôle repère quel problème ?
Différents types de contrôles couvrent différents risques ; en choisir un ne rend pas les autres inutiles.
- contrôle ping/HTTP : si le serveur répond du tout, en quelques secondes
- contrôle de contenu : si la page s'est chargée correctement, en se basant sur un texte précis ou un code de statut
- contrôle synthétique : si un processus multi-étapes comme le paiement, la connexion ou l'envoi d'un formulaire fonctionne de bout en bout
- contrôle de certificat SSL : combien de temps avant l'expiration du certificat
Comment construire une chaîne d'alerte
Une alerte qui n'atteint personne, ou qui atteint tout le monde en même temps si bien que personne ne s'en charge, est l'endroit où la surveillance échoue le plus souvent en pratique. Une escalade par paliers réduit ce risque.
- première détection : le contrôle automatique confirme la panne sur 2-3 tentatives consécutives, pour qu'un simple incident réseau ne soit pas pris pour une panne
- 0-5 minutes : une notification immédiate à la personne d'astreinte, dans l'app ou par e-mail
- 5-15 minutes : sans réponse, un SMS ou un appel se déclenche, et une deuxième personne est alertée
- après 15 minutes : un responsable intervient, la page de statut est mise à jour
Que se passe-t-il pendant une panne ?
La première tâche dès qu'une panne est repérée n'est pas de la corriger mais d'en comprendre l'ampleur : tout le site est-il en panne ou juste une partie, combien d'utilisateurs sont touchés, quand cela a-t-il commencé. Agir sans cette information risque de corriger la mauvaise chose en manquant la cause réelle.
Une page de statut publique rend service à ce moment-là ; elle permet au support de renvoyer chaque client vers une seule page à jour au lieu de répondre à chacun individuellement. La page doit être mise à jour jusqu'à la fin de la panne, puis clôturée une fois résolue.
Pourquoi le bilan post-incident ne doit jamais être sauté
Une fois la panne résolue, un court bilan est rédigé : ce qui s'est passé, quand cela a été remarqué, combien de temps la correction a pris, ce qui va changer pour empêcher que cela se reproduise. Le document existe pour éviter une répétition, pas pour désigner un coupable.
Si le système de réservation d'une chaîne de spas tombe en panne deux fois de suite pour la même raison, le problème n'est pas technique mais organisationnel ; ce que le premier bilan avait demandé de corriger n'a jamais été réellement appliqué. Une deuxième panne pour la même cause mérite d'être prise plus au sérieux que la première, pas moins.
Erreurs fréquentes
La surveillance uptime peut devenir un outil mis en place puis oublié ; cela arrive presque aussi souvent que les pannes qu'elle est censée repérer.
- ne surveiller que la page d'accueil en laissant le paiement ou la connexion sans surveillance
- n'envoyer les alertes qu'à une seule personne, si bien que personne ne remarque son absence
- contrôler trop rarement, par exemple toutes les trente minutes, en manquant complètement les pannes courtes
- passer directement à la crise suivante sans faire de bilan post-incident
La surveillance uptime n'empêche pas une panne ; elle fait en sorte qu'elle soit repérée avant un client et gérée de façon ordonnée. Une chaîne d'alerte bien construite et l'habitude d'un court bilan post-incident raccourcissent la durée de la prochaine panne. Un premier échange avec rabbitclip est un bon endroit pour revoir ensemble votre dispositif de surveillance actuel.
Questions fréquentes
La surveillance uptime peut-elle se faire avec des outils gratuits ?
Oui, un contrôle ping/HTTP basique est couvert par de nombreuses offres gratuites. La surveillance synthétique et des contrôles plus fréquents se trouvent généralement dans les offres payantes.
À quelle fréquence les contrôles doivent-ils tourner ?
Une à cinq minutes est courant pour les pages critiques. Des contrôles plus fréquents repèrent les problèmes plus tôt, mais ajoutent aussi de la charge au serveur.
Chaque site a-t-il besoin d'une page de statut ?
Elle vaut la peine pour les sites à forte interaction client et pour l'e-commerce. Un site vitrine à faible trafic peut s'en passer.
Le bilan post-incident sert-il à désigner un coupable ?
Non. Le but est d'éviter une répétition ; le bilan examine le processus et le système, pas une personne.
