Bienvenue
Bienvenue
Une flotte à l'échelle web contient de nombreuses machines. À tout moment, certaines sont en bonne santé, certaines démarrent, certaines sont en cours de vidage, et certaines sont silencieusement défectueuses. La flotte survit à cela parce que chaque machine répond à deux questions simples sur demande :
- /health — suis-je actuellement en mesure de traiter de vraies requêtes ?
- /version — quel code exécuté-je ?
Plus un point de terminaison de métriques (généralement /metrics) qui expose des compteurs et des jauges pour que les outils de surveillance puissent les collecter.
Cette leçon enseigne comment concevoir ces points de terminaison afin qu'ils reflètent réellement la réalité, ce que signifient les quatre signaux dorés au niveau du proxy, et comment les données observées guident les décisions de capacité.
À la fin, vous saurez :
- Concevoir un point de terminaison /health qui détecte l'échec réel d'un chemin, et non seulement la vitalité du processus
- Concevoir un point de terminaison /version qui vous permet de vérifier qu'un déploiement a bien eu lieu
- Appliquer les quatre signaux dorés (latence, trafic, erreurs, saturation) au niveau du proxy
- Relier les métriques de pic observées aux décisions de capacité : quand augmenter la capacité, quand drainer, quand alerter
- Raisonner sur les SLO et le taux de consommation du budget d'erreurs en tant que discipline opérationnelle derrière la question « à quel point nous importe-t-il ? »
Les deux types de vérification de santé
Vivacité (Liveness) vs Prêt à l'emploi (Readiness)
Vivacité (Liveness) : le processus est-il vivant ? Utilisé par les orchestrateurs (Kubernetes, systemd) pour décider s'il faut redémarrer le processus.
Prêt à l'emploi (Readiness) : le processus est-il prêt à traiter du trafic réel maintenant ? Utilisé par les équilibreurs de charge pour décider s'il faut envoyer des requêtes.
Ce sont des questions différentes. Un processus qui est vivant mais qui ne peut pas atteindre sa base de données est vivant mais pas prêt à l'emploi. Un processus qui démarre est vivant mais pas encore prêt à l'emploi.
Vérifications de santé superficielles vs approfondies
Superficielle : renvoie {"status": "ok"} si le gestionnaire HTTP s'exécute. Triviale. Détecte uniquement l'arrêt du processus.
Approfondie : exerce réellement le chemin de requête réel. Vérifie que le pool de connexions de la base de données peut retourner une connexion, que le cache est accessible et que les dépendances en aval répondent. Détecte les pannes fonctionnelles que les vérifications superficielles manquent.
Le compromis : les vérifications approfondies coûtent plus cher (chacune est essentiellement une requête synthétique) & peuvent provoquer un échec en cascade (si la vérification de santé de chaque réplique martèle la base de données, une base de données lente rend toutes les répliques non saines, ce qui les retire de la rotation, ce qui supprime toute la capacité).
Meilleure pratique : une vérification superficielle pour la vivacité (rapide, peu coûteuse, sans dépendances externes) & une vérification plus approfondie pour la disponibilité (résultats en cache, limitée pour éviter de marteler les services en aval).
Points de terminaison de version
/version renvoie le commit git, l'heure de construction & le nom du service. Après un déploiement, vous exécutez curl https://service.example.com/version & confirmez que le commit renvoyé correspond à celui que vous avez poussé. S'il ne correspond pas, le déploiement a échoué silencieusement.
Sans /version, un déploiement obsolète peut sembler réussi & rester caché pendant des heures.
Forme minimale de la réponse : {"service": "my-api", "git_commit": "abc1234", "build_time": "2026-05-19T10:00:00Z"}.
Latence, Trafic, Erreurs, Saturation
Quatre nombres couvrent la plupart des opérations
Du livre Google SRE. Quatre signaux que vous mesurez sur chaque niveau de service. Si vous instrumentez bien ces quatre signaux, vous détectez la plupart des problèmes de production avant les utilisateurs.
Latence : combien de temps prend une requête ? Rapportez des distributions, et pas seulement des moyennes. Le p99 (latence au 99e percentile) est plus important que la moyenne, car la latence de queue est ce que les utilisateurs perçoivent comme « lent ». Un service avec une moyenne de 50 ms et un p99 de 5 000 ms a un problème réel que la plupart des utilisateurs ne remarquent jamais, mais que les 1 % les plus affectés ressentent absolument.
Trafic : combien de requêtes par seconde ? Requêtes totales, par point d'entrée, par code de statut, par région. La référence est connue ; alertez sur les anomalies (chute soudaine = problème d'entrée ; pic soudain = afflux ou attaque).
Erreurs : taux de requêtes échouées. Distinguez les 4xx (erreurs client, pas de votre faute) des 5xx (erreurs serveur, de votre faute). Suivez le taux d'erreurs en pourcentage du trafic, et non en nombres absolus, afin que les alertes fonctionnent à tous les niveaux de charge.
Saturation : à quel point le système est-il plein ? Utilisation du CPU, mémoire, profondeur du pool de connexions, longueur de la file d'attente. L'indicateur précurseur. La saturation augmente avant que la latence ou les erreurs ne se dégradent. Un niveau à 90 % de saturation est à une mauvaise minute du effondrement de la file d'attente.
Au niveau d'un niveau de proxy
Chaque signal s'allume à la couche de bord :
- Latence au niveau du proxy : durée de la poignée de main TLS, temps de connexion en amont, total requête-réponse. Mesurés séparément car ils se situent sur différentes parties du chemin.
- Trafic au niveau du proxy : requêtes totales/seconde, distribution par backend (un backend surchargé signale un déséquilibre du répartiteur de charge), répartition par code de statut.
- Erreurs au niveau du proxy : 4xx provenant des clients (vos utilisateurs accédant à de mauvais points d'entrée), 5xx provenant des backends (vos services en échec), erreurs internes au proxy (502 = backend inaccessible, 504 = délai d'attente du backend dépassé).
- Saturation au niveau du proxy : nombre de sessions TLS, profondeur de la piscine de connexions amont, CPU du proxy lui-même (la terminaison TLS est gourmande en CPU).
Astuce pro : une augmentation soudaine des 502 avec une faible latence du backend signifie que le backend raccroche avant de répondre (réinitialisation de la connexion, crash, OOM). Une augmentation des 504 signifie que le backend est lent mais répond encore. Lisez le code d'erreur ; il vous indique où se situe la panne.
Lire les signaux
Votre tableau de bord affiche les éléments suivants sur les 10 dernières minutes :
- Trafic : relativement stable à 800 req/s (pas de pic)
- Latence : p50 stable à 40 ms, p99 passée de 200 ms à 2 500 ms en 5 minutes et toujours en hausse
- Erreurs : le taux 4xx est stable à 0,3 % (bruit de fond normal) ; le taux 5xx est passé de 0,1 % à 1,2 % (principalement des 504 Gateway Timeout)
- Saturation : le CPU des backends est passé de 45 % à 78 % au cours des 5 minutes correspondantes ; le CPU du proxy est stable à 30 %
Quand mettre à l'échelle, quand drainer, quand alerter
Les décisions de capacité nécessitent des déclencheurs
Observer les métriques est facile. Savoir quand agir sur elles est la discipline.
Mettre à l'échelle (scale up) lorsque : la saturation dépasse un seuil soutenu (par exemple, CPU backend > 70 % pendant 5 minutes), ou que la profondeur de la file d'attente dépasse une cible, ou que la latence p99 dépasse l'objectif de service (SLO). Le déclencheur doit se déclencher avant que les choses ne cassent, pas au moment de la rupture.
Drainer un réplique lorsque : il est lent ou en erreur de manière constante tandis que les pairs sont sains (un réplique qui tourne à chaud est souvent un problème au niveau de l'hôte, et non un problème applicatif), ou lors du déploiement d'une nouvelle version, ou lors de la mise à l'écart gracieuse d'un réplique.
Alerter un humain lorsque : un objectif de service (SLO) est consommé plus vite que le budget d'erreurs ne peut le soutenir, ou qu'un déclencheur de saturation se déclenche sans que la mise à l'échelle automatique ne l'absorbe, ou qu'un motif en cascade apparaît (taux d'erreurs et taux de réessais en hausse simultanée).
Ne pas alerter lorsque : une seule mauvaise minute se résout d'elle-même, ou que des tâches par lot en arrière-plan provoquent des fluctuations périodiques attendues, ou que le bruit dépasse le seuil (le seuil est incorrect, pas le système).
SLO et consommation du budget d'erreurs
Un SLO (objectif de niveau de service) définit les performances acceptables : « taux de réussite >= 99,9 % sur une fenêtre de 28 jours ». Le complément (0,1 %) est le budget d'erreurs.
Taux de consommation (burn rate) : la vitesse à laquelle vous consommez le budget d'erreurs. Si vous consommez 10 % du budget en 1 heure, le taux est 240 fois supérieur au taux soutenable (1 heure représente 1/672 d'une fenêtre de 28 jours ; consommer 10 % dans cette fenêtre = 10 % × 672 = 6720 % projeté pour la fenêtre complète, alors que seul 100 % est autorisé).
Alertes de consommation multi-fenêtres : déclencher une alerte (page) lorsque, à la fois, une fenêtre courte (5 minutes à un taux de 14,4x) et une fenêtre longue (1 heure à un taux de 6x) consomment le budget plus vite que le taux soutenable. Permet de détecter à la fois les pannes rapides et les dégradations lentes.
Pourquoi c'est important pour la capacité : un service fonctionnant avec un SLO de 99,9 % et une marge de 1 % peut absorber les petites fluctuations. Un service à 99,93 % (qui atteint tout juste le SLO) est à un mauvais jour de la violation. Les décisions de capacité doivent viser une marge SLO confortable, et non le minimum nécessaire pour l'atteindre.
Une décision de capacité sous observation
Votre service a un SLO de 99,9 % de requêtes réussies sur 28 jours. État actuel selon la surveillance de la dernière heure :
- Taux de réussite : 99,5 % (maintenu pendant 30 minutes)
- CPU backend : moyenne de 82 % sur l'ensemble de la flotte (objectif : 70 %)
- Latence p99 : 800 ms (objectif SLO : <500 ms)
- Trafic : 1 400 req/s, en hausse par rapport à la base de 1 000 req/s (40 % au-dessus de la normale ; la tendance est toujours à la hausse)
- Mise à l'échelle automatique : configurée pour ajouter des répliques lorsque le CPU dépasse 80 % pendant 5 minutes consécutives ; actuellement en cours de mise à l'échelle vers le haut, qui ajoutera 3 répliques dans ~90 secondes
Concevoir un plan d’observabilité pour le lancement
Synthèse
Vous pouvez désormais concevoir un /health qui détecte les pannes réelles, un /version qui permet de vérifier les déploiements, des tableaux de bord à quatre signaux dorés au niveau du proxy, et des déclencheurs de capacité liés au taux de consommation des SLO.
Appliquez les quatre.
Votre équipe lance search.example.com (le service de recherche du cours sur les modes de défaillance). L’équipe souhaite déployer une observabilité capable de détecter les problèmes avant les utilisateurs, avec une matrice de décision claire « page ou non ». SLO : 99,9 % de requêtes réussies, latence p99 < 300 ms, sur une fenêtre de 28 jours.
Clôture du cours
Clôture du cours
Vous avez terminé les cinq leçons :
- Proxies & Origines : la forme de la couche d'extrémité utilisée par presque tous les services web publics
- Mise à l'échelle horizontale sans état : pourquoi une couche sans état se multiplie à moindre coût et comment la dimensionner
- Séparation des entrées et des sorties : pourquoi une seule machine devient deux, et le mode de défaillance qui l'impose
- Modes de défaillance et rayon d'impact : points de défaillance unique (SPOF), réactions en chaîne, analyses post-mortem, actions correctives sans blâme
- Observabilité et capacité (celui-ci) : quoi mesurer pour que les problèmes apparaissent avant que les utilisateurs ne les constatent
Le fil conducteur : un système distribué à l'échelle du web n'est pas de la magie. C'est un petit ensemble de motifs (proxy inverse, répliques sans état, séparation entrées/sorties, cloisons et disjoncteurs, quatre signaux dorés) composés avec soin. Une fois que vous reconnaissez ces motifs, vous les voyez dans chaque architecture de production.
Leçons complémentaires : cinq leçons de géométrie-* réinterprètent le même contenu sous la forme de la théorie des graphes et de la géométrie. Elles fonctionnent bien dans n'importe quel ordre.
Bien joué.