« Qu'est-ce que la surveillance de la disponibilité ? Guide complet pour les équipes Web et les SRE »

La surveillance de la disponibilité est la discipline opérationnelle fondamentale qui consiste à vérifier en permanence que les sites Web, les applications Web et les microservices API restent accessibles, réactifs et fonctionnels pour les utilisateurs du monde entier.

Dans le cloud computing moderne, les temps d'arrêt des sites Web nuisent directement aux revenus de l'entreprise, à la réputation de la marque, dégradent le classement des moteurs de recherche et entraînent une perte de clientèle.Ce guide complet explique comment fonctionne la surveillance automatisée de la disponibilité, comment calculer les pourcentages de disponibilité des accords de niveau de service (SLA), comment éliminer les fausses alertes positives et comment structurer les flux de travail de surveillance de la production.

Résumé de la réponse en premier

La surveillance de la disponibilité automatise les tests continus des points de terminaison Web via des pings HTTP/HTTPS planifiés à partir de serveurs de sonde géographiquement répartis.Il vérifie les codes d'état de réponse HTTP (2xx/3xx), le temps de résolution DNS, les négociations de connexion TCP et la validité du certificat TLS.Les systèmes à haute disponibilité ciblent des objectifs SLA tels que « Trois Neuf » (temps de disponibilité de 99,9 % = temps d'arrêt maximum de 8,76 heures/an) ou « Quatre Neuf » (temps de disponibilité de 99,99 % = temps d'arrêt maximum de 52,6 minutes/an).Pour éviter les fausses alertes positives, les moniteurs modernes tels que SimpleOps appliquent un consensus de sonde multirégional avant d'envoyer des notifications via Slack, Telegram, Email ou Webhooks.

Comment fonctionne la surveillance de la disponibilité : sous le capot

La surveillance automatisée de la disponibilité fonctionne comme un système de télémétrie distribué asynchrone :

Envoi planifié de la sonde : les nœuds de travail de sonde de surveillance distribués exécutent des requêtes HTTP/HTTPS sur les URL cibles enregistrées à des intervalles de temps fixes (par exemple toutes les 60 secondes).
Validation de réponse multicouche : chaque nœud de sonde inspecte plusieurs couches de protocole :
- Résolution DNS : mesure la latence requise pour que les serveurs de noms de domaine résolvent le domaine en une adresse IP.
- TCP Handshake : chronomètre la durée d'établissement de la connexion réseau.
- TLS/SSL Handshake : inspecte la validité du certificat, la négociation de la suite de chiffrement et la date d'expiration.
- Code d'état de réponse HTTP : vérifie que le serveur renvoie un code d'état de réussite 2xx ou de redirection 3xx attendu (signalant les erreurs client 4xx et les erreurs de serveur 5xx).
- Response Payload Matching : correspondance de mots clés facultative pour vérifier que les éléments clés de la page s'affichent correctement.
Consensus sur les échecs multi-régions : lorsqu'un nœud de vérification principal détecte une erreur HTTP ou un délai d'expiration de connexion, il envoie des tâches de revérification aux nœuds de vérification secondaires dans différentes régions géographiques du monde (par exemple, Amérique du Nord, Europe, Asie-Pacifique).Si plusieurs nœuds indépendants confirment l'échec, un incident officiel est ouvert.
Envoi de notifications d'alerte : les notifications instantanées sont acheminées vers les équipes d'ingénierie de garde via Slack, Telegram, Email, Webhooks ou PagerDuty.

SLA de disponibilité et échelle « neuf »

La disponibilité de la disponibilité est exprimée en pourcentage du temps de fonctionnement total sur une fenêtre de mesure donnée (mensuelle ou annuelle) :

$$\text{Disponibilité de la disponibilité (%)} = \frac{\text{Temps total} - \text{Temps d'arrêt total}}{\text{Temps total}} \times 100$$

L'échelle « Nines » standard de l'industrie classe les objectifs de disponibilité en niveaux opérationnels :

Objectif de disponibilité SLA	Temps d'arrêt annuel maximum autorisé	Temps d'arrêt mensuel maximum autorisé	Cas d'utilisation typique
99,0 % (« Deux neuf »)	3 jours, 15 heures, 39 minutes	7 heures et 18 minutes	Environnements de développement, sites de préparation internes.
99,5 %	1 jour, 19 heures, 49 minutes	3 heures et 39 minutes	Blogs non critiques, pages de destination marketing.
99,9 % ("Trois Neuf")	8 heures, 45 minutes, 57 secondes	43 minutes, 49 secondes	Produits SaaS standards, applications Web commerciales.
99,99 % ("Quatre Neuf")	52 minutes, 35 secondes	4 minutes et 23 secondes	API de paiement pour le commerce électronique, passerelles de paiement.
99,999 % ("Cinq Neuf")	5 minutes, 15 secondes	25,9 secondes	Télécommunications, plateformes de trading financier.

Prévention des alertes de temps d'arrêt faussement positives

Des alertes faussement positives se produisent lorsqu'un outil de surveillance signale une panne qui ne représente pas une véritable panne de service (comme un problème de réseau temporaire entre une seule sonde et le site cible).Les faux positifs créent une lassitude face aux alertes, obligeant les ingénieurs de garde à ignorer les notifications d'urgence légitimes.

Pour éviter les fausses alertes positives, SimpleOps applique trois mesures de protection :

Consensus géographique multirégional : une alerte n'est jamais déclenchée en fonction de la défaillance d'un seul nœud de sonde.Au moins deux nœuds de sonde distincts dans différentes régions du monde doivent confirmer indépendamment l'échec.
Seuils de défaillance consécutives : les pannes doivent persister sur plusieurs cycles de contrôle consécutifs (par exemple, 2 contrôles consécutifs échoués de 60 secondes) avant de déclencher une escalade hautement prioritaire.
Logique de relance intelligente : les sondes exécutent des tentatives immédiates et instantanées en cas d'expiration du délai d'attente du réseau pour distinguer la perte de paquets transitoire du temps d'arrêt réel du serveur.

Surveillance de la disponibilité et des performances

Bien que la surveillance de la disponibilité vérifie que votre serveur Web fonctionne et renvoie des réponses HTTP 200 OK, elle n'évalue pas la rapidité ou l'utilisabilité de votre site Web pour les utilisateurs réels.

Un site Web peut avoir une disponibilité HTTP de 100 % tout en restant inutilisable en raison d'images non compressées, de verrous d'exécution JavaScript sur le thread principal ou de la lenteur de Core Web Vitals (LCP, INP, CLS).Pour cette raison, les équipes d'ingénierie modernes combinent la surveillance de la disponibilité HTTP avec des audits synthétiques Lighthouse et un suivi sur le terrain des utilisateurs réels dans SimpleOps .

Implémentation d'une surveillance automatisée de la disponibilité avec SimpleOps

SimpleOps fournit une plate-forme de surveillance de la disponibilité sans code qui permet aux développeurs et aux équipes DevOps de configurer des contrôles globaux de disponibilité de 60 secondes en moins de deux minutes :

Plus de 15 nœuds de contrôle mondiaux : surveillez la disponibilité en Amérique du Nord, en Europe, en Asie-Pacifique et en Amérique du Sud.
Alertes multicanaux : acheminez instantanément les notifications vers Slack, Telegram, Email ou Webhooks personnalisés.
Suivi intégré de l'expiration SSL : surveillez les dates d'expiration des certificats HTTPS et les chaînes de confiance dès le départ.
Pages d'état publiques : partagez l'état du système en temps réel et les mesures historiques de disponibilité des SLA avec les clients et les parties prenantes.