Alerting et astreinte

La surveillance (monitoring) occupe la base de la hiérarchie des besoins de production : sans elle, on vole à l'aveugle, incapable de savoir si le service fonctionne, et a fortiori de mesurer son alignement avec les objectifs métier. À l'échelle de Google, surveiller un système distribué pose deux défis : le nombre brut de composants à analyser, et la nécessité de maintenir une charge d'entretien raisonnable sur les ingénieurs qui en sont responsables. La réponse, forgée sur dix ans, a consisté à faire de la collecte de séries temporelles (time-series) le rôle premier du système de surveillance — avec un outil maison, Borgmon, dont Prometheus est aujourd'hui très proche. Une fois ces signaux disponibles vient la seconde moitié de l'équation humaine : organiser une astreinte (on-call) à la fois efficace et soutenable, capable de répondre aux incidents sans épuiser les équipes.

Du script de vérification à la série temporelle

Les systèmes de surveillance de Google ont évolué d'un modèle traditionnel — des scripts maison qui vérifient des réponses et déclenchent des alertes, totalement séparés de l'affichage des tendances — vers un nouveau paradigme. Ce modèle a fait de la collecte de séries temporelles un objet de première classe, et remplacé les scripts de vérification par un langage riche pour transformer ces séries en graphiques et en alertes.

La bascule tient à une observation d'échelle. Être alerté pour la panne d'une machine isolée est inacceptable : la donnée est trop bruyante pour être exploitable. Plutôt que de gérer une myriade de composants individuels, un grand système doit être conçu pour agréger les signaux et élaguer les valeurs aberrantes (outliers). Il faut pouvoir alerter sur des objectifs de service de haut niveau, tout en conservant la granularité d'inspecter un composant au besoin. Google ne mesure d'ailleurs pas de simples métriques comme le temps de réponse moyen d'un serveur web : il lui faut comprendre la distribution de ces temps de réponse sur tous les serveurs d'une région, afin d'identifier les facteurs qui nourrissent la traîne de latence (latency tail).

Borgmon et la collecte en boîte blanche

Peu après la création en 2003 de Borg, l'infrastructure d'ordonnancement de tâches, Borgmon fut bâti pour le compléter. Plutôt que d'exécuter des scripts pour détecter les pannes, Borgmon repose sur un format d'exposition de données commun, qui autorise une collecte de masse à faible coût et évite la dépense d'exécuter des sous-processus et d'ouvrir des connexions réseau. C'est ce qu'on appelle la surveillance en boîte blanche (white-box monitoring) : on inspecte l'état interne du service.

Pour permettre cette collecte de masse, le format des métriques a dû être standardisé. Une ancienne méthode d'export de l'état interne, dite varz, a été formalisée pour permettre la collecte de toutes les métriques d'une cible en une seule requête HTTP. Pour consulter une page de métriques à la main, il suffit d'interroger l'URI /varz :

% curl http://webserver:80/varz
http_requests 37
errors_total 12

Le gestionnaire /varz liste simplement toutes les variables exportées en texte brut, paires clé-valeur séparées par des espaces, une par ligne. Une extension ultérieure a ajouté une variable mappée, où l'on définit plusieurs étiquettes sur un nom de variable pour exporter une table de valeurs ou un histogramme — par exemple 25 réponses HTTP 200 et 12 HTTP 500. Ajouter une métrique à un programme ne réclame qu'une seule déclaration dans le code. Ce caractère textuel et sans schéma abaisse considérablement la barrière à l'instrumentation — un atout pour les équipes de développement comme pour les SRE.

Collecter les données exportées

Pour trouver ses cibles, une instance Borgmon est configurée avec une liste, souvent dynamique : recourir à la découverte de service (service discovery) réduit le coût d'entretien et permet à la surveillance de passer à l'échelle. À intervalles prédéfinis, Borgmon récupère l'URI /varz de chaque cible, décode les résultats et stocke les valeurs en mémoire. Il répartit la collecte de chaque instance sur tout l'intervalle, afin qu'elles ne soient pas synchronisées au pas l'une de l'autre.

Borgmon enregistre aussi des variables synthétiques pour chaque cible, afin d'identifier si le nom a bien été résolu en hôte et port, si la cible a répondu à la collecte, si elle a répondu à un contrôle de santé (health check), et l'heure de fin de collecte. Ces variables rendent triviale l'écriture de règles détectant qu'une tâche surveillée est indisponible : l'échec de collecte devient lui-même un signal.

Stockage : l'arène de séries temporelles

Borgmon stocke toutes les données dans une base en mémoire, régulièrement sauvegardée sur disque (checkpoint). Les points ont la forme (horodatage, valeur) et sont rangés dans des listes chronologiques — les séries temporelles — chacune nommée par un ensemble unique d'étiquettes de la forme nom=valeur. Conceptuellement, une série temporelle est une matrice unidimensionnelle de nombres qui progresse dans le temps ; à mesure qu'on ajoute des permutations d'étiquettes, la matrice devient multidimensionnelle.

Arène de séries temporelles (bloc mémoire de taille fixe)

  point = (horodatage, valeur)  ──► ~24 octets

  série = liste chronologique nommée par un labelset :
  {var=http_requests, job=webserver, instance=host0:80, zone=us-west}
     t0   t1   t2   t3   t4   t5   ...   ► le temps avance
      0    1    2    3    4    5

  horizon = écart entre le point le plus récent et le plus ancien
            (ce qui reste interrogeable en RAM)
  garbage collector : expire les plus vieilles entrées quand l'arène est pleine

En pratique, la structure est un bloc mémoire de taille fixe — l'arène de séries temporelles (time-series arena) — doté d'un ramasse-miettes qui expire les plus anciennes entrées une fois l'arène pleine. L'intervalle entre l'entrée la plus récente et la plus ancienne est l'horizon : il indique combien de données restent interrogeables en RAM. Les Borgmon de datacenter et globaux sont typiquement dimensionnés pour douze heures de données. Un point coûtant environ 24 octets, on peut loger un million de séries uniques sur douze heures à intervalle d'une minute en moins de 17 Go de RAM. Périodiquement, l'état mémoire est archivé vers un système externe, la base de séries temporelles (TSDB), plus lente mais moins chère et plus vaste que la RAM d'un Borgmon.

Étiquettes et vecteurs

Les séries sont des suites de nombres et d'horodatages appelées vecteurs : comme en algèbre linéaire, ce sont des coupes transversales de la matrice multidimensionnelle. Le nom d'une série est un labelset, un ensemble d'étiquettes clé=valeur ; l'une de ces étiquettes est le nom de la variable lui-même. Quelques étiquettes sont déclarées importantes : pour être identifiable, une série doit au minimum porter var (le nom de la variable), job (le type de serveur surveillé), service (un regroupement lâche de jobs rendant un service aux utilisateurs) et zone (l'emplacement, typiquement le datacenter). Réunies, elles forment l'expression de variable. Une requête n'exige pas de spécifier toutes les étiquettes : une recherche par labelset retourne toutes les séries correspondantes dans un vecteur. On peut aussi interroger dans le temps en ajoutant une durée, par exemple [10m] pour les dix dernières minutes d'historique.

Évaluer des règles : la calculatrice programmable

Borgmon n'est, au fond, qu'une calculatrice programmable assortie d'un peu de sucre syntaxique pour générer des alertes. Le code de règles consiste en expressions algébriques simples qui calculent de nouvelles séries à partir d'autres séries. Ces règles sont puissantes parce qu'elles peuvent interroger l'historique d'une série (l'axe du temps), interroger différents sous-ensembles d'étiquettes sur de nombreuses séries à la fois (l'axe de l'espace), et appliquer quantité d'opérations mathématiques. Centraliser cette évaluation, au lieu de la déléguer à des sous-processus, permet de calculer en parallèle contre de nombreuses cibles similaires, tout en gardant une configuration compacte et expressive.

L'agrégation est la pierre angulaire de l'évaluation de règles en environnement distribué : il s'agit de sommer un ensemble de séries issues des tâches d'un job pour traiter le job comme un tout, et d'en déduire des taux globaux. Le débit total de requêtes par seconde d'un job dans un datacenter, par exemple, est la somme de tous les taux de variation des compteurs de requêtes.

Les règles suivent une convention de nommage lisible : chaque variable calculée porte un triplet séparé par des deux-points indiquant le niveau d'agrégation, le nom de la variable et l'opération. Ainsi task:http_requests:rate10m se lit « taux sur 10 minutes des requêtes HTTP au niveau tâche », et dc:http_requests:rate10m au niveau datacenter. La fonction rate() retourne le delta total divisé par le temps écoulé entre la première et la dernière valeur ; on emploie une fenêtre temporelle comme [10m] pour disposer d'assez de points et survivre à d'éventuelles collectes ratées.

Chaîne de règles : du taux brut au ratio d'erreurs

  http_requests ─rate([10m])►  task:http_requests:rate10m   (par tâche)
                  sum without instance ►  dc:http_requests:rate10m   (cluster)

  http_responses ─rate by code►  task:http_responses:rate10m (par tâche, par code)
                  sum without instance ►  dc:http_responses:rate10m  (cluster, par code)
                  sum (code != 200)    ►  dc:http_errors:rate10m     (cluster)

  dc:http_errors:rate10m / dc:http_requests:rate10m
                  ►  dc:http_errors:ratio_rate10m   = 0,15

Pour alerter quand un cluster web sert trop d'erreurs, on calcule le ratio entre la somme des taux de codes non-200 et la somme des taux de requêtes. Comme les règles créent de nouvelles séries conservées dans l'arène, ces résultats intermédiaires s'inspectent comme les séries sources : on peut en explorer l'historique en table ou en graphique, ce qui est précieux pour déboguer en pleine astreinte — et toute requête ad hoc utile peut être promue en visualisation permanente sur une console de service.

Du calcul à l'alerte

Quand une règle d'alerte (alerting rule) est évaluée, son résultat est vrai (l'alerte se déclenche) ou faux. L'expérience montre que les alertes peuvent « battre » (flapping), basculant rapidement d'état ; les règles imposent donc une durée minimale de vérité avant l'envoi — typiquement au moins deux cycles d'évaluation, pour qu'une collecte manquée ne provoque pas de fausse alerte. On peut ainsi alerter quand le ratio d'erreurs sur dix minutes dépasse 1 % et que le nombre absolu d'erreurs dépasse 1, l'état devant tenir deux minutes (for 2m) avant de réellement se déclencher.

Borgmon est relié à un service central, l'Alertmanager, qui reçoit les RPC d'alerte et route la notification vers la bonne destination. L'Alertmanager peut inhiber certaines alertes lorsque d'autres sont actives, dédupliquer les alertes provenant de plusieurs Borgmon au même labelset, et regrouper (fan-in) ou diffuser (fan-out) les alertes selon leurs étiquettes. Conformément à la philosophie de surveillance : les alertes dignes d'un page partent vers la rotation d'astreinte, les alertes importantes mais subcritiques vers une file de tickets, et tout le reste demeure de la donnée informative pour les tableaux de bord.

Boîte noire, partitionnement et maintien

Borgmon est un système de boîte blanche : il connaît les entrailles du service, ce qui le rend excellent pour identifier vite quel composant défaille, quelle file déborde, où se situe le goulot. Mais la boîte blanche ne montre pas ce que voient les utilisateurs. On ne voit que les requêtes qui parviennent à la cible ; celles perdues par une erreur DNS sont invisibles, celles avalées par un crash serveur ne font aucun bruit. On ne peut alerter que sur les pannes qu'on a anticipées.

Google comble cette lacune avec Prober, qui exécute un contrôle de protocole contre une cible et rapporte succès ou échec — un modèle de surveillance en boîte noire (black-box monitoring). Prober peut valider le contenu de la réponse (par exemple le HTML d'une réponse HTTP), en extraire des valeurs et exporter des histogrammes de temps de réponse par type d'opération. Pointé tantôt sur le domaine frontal, tantôt derrière le répartiteur de charge, il permet de distinguer les pannes localisées : on sait que le trafic reste servi quand un datacenter tombe, ou l'on isole rapidement l'arête défaillante dans le graphe de flux.

Aspect	Boîte blanche (Borgmon)	Boîte noire (Prober)
Point de vue	État interne du service	Expérience extérieure de l'utilisateur
Source	Variables /varz collectées en masse	Contrôle de protocole de bout en bout
Force	Diagnostiquer composants, files, goulots	Détecter ce que l'utilisateur subit réellement
Limite	N'alerte que sur l'attendu ; aveugle au DNS, aux crashes	Peu de visibilité sur la cause interne
Alerte sur	L'état interne, ouvrant la distinction symptômes/causes	Symptômes du point de vue utilisateur

Côté partitionnement (sharding), un Borgmon peut importer les séries d'autres Borgmon via un protocole de streaming, plus économe que le format texte varz. Un déploiement typique compte deux Borgmon globaux ou plus pour l'agrégation de tête, et un Borgmon par datacenter ; les très gros services scindent encore en une couche de pure collecte et une couche d'agrégation. Les étages supérieurs filtrent ce qu'ils streament des étages inférieurs, pour ne pas saturer leur arène — bâtissant une hiérarchie de caches locaux où l'on peut plonger (drill down) au besoin.

Enfin, maintenir la configuration est un enjeu de coût. Borgmon sépare la définition des règles des cibles surveillées : un même jeu de règles s'applique à de nombreuses cibles sans réécriture, et des modèles (templates) de type macro permettent de constituer des bibliothèques de règles réutilisables. Cette configuration est testée par intégration continue — on synthétise des séries pour vérifier que les règles se comportent comme leur auteur le croit — puis empaquetée et expédiée à tous les Borgmon de production, qui la valident avant de l'accepter.

Être d'astreinte : un devoir critique

Les signaux étant en place, encore faut-il quelqu'un pour y répondre. De nombreux services importants de Google — Search, Ads, Gmail — disposent d'équipes SRE dédiées, et ces SRE sont d'astreinte pour les services qu'ils soutiennent. Ils diffèrent radicalement des équipes purement opérationnelles par leur insistance sur l'ingénierie : Google plafonne le temps consacré au travail purement opérationnel à 50 %, et au moins la moitié du temps d'un SRE doit aller à des projets d'ingénierie qui démultiplient l'impact de l'équipe par l'automatisation.

En astreinte, l'ingénieur doit pouvoir intervenir sur les systèmes de production en quelques minutes, selon des temps de réponse aux pages convenus avec l'équipe et les propriétaires métier. Les valeurs typiques sont 5 minutes pour les services orientés utilisateurs ou très critiques en temps, et 30 minutes pour les systèmes moins sensibles. Ces temps découlent directement de la disponibilité visée : un système exigeant quatre neufs (99,99 %) sur un trimestre ne tolère qu'environ 13 minutes d'indisponibilité, ce qui impose des réactions de l'ordre de la minute.

Disponibilité visée  ──►  budget d'indisponibilité  ──►  temps de réaction

  99,99 % (4 neufs) /trimestre  ≈ 13 min d'arrêt  ──►  réaction en minutes
  SLO plus relâché              ≈ plus de marge   ──►  réaction en dizaines de min

Dès qu'un page est reçu et acquitté, l'ingénieur trie le problème et œuvre à sa résolution, en impliquant d'autres membres et en escaladant au besoin. Les événements non urgents — alertes de priorité basse, mises en production de logiciel — peuvent être traités pendant les heures ouvrées, mais cèdent toujours la priorité aux pages. Beaucoup d'équipes maintiennent une rotation primaire et une secondaire : la secondaire sert parfois de filet aux pages manqués par la primaire, parfois prend en charge l'activité non urgente pendant que la primaire ne traite que les pages. Quand une secondaire dédiée n'est pas nécessaire, deux équipes apparentées se servent mutuellement de secondaire.

Une astreinte équilibrée : quantité et qualité

Les équipes SRE imposent des contraintes précises sur deux axes : la quantité d'astreinte (le pourcentage de temps passé en garde) et la qualité (le nombre d'incidents par garde). Le rôle du management SRE est de tenir cette charge équilibrée et soutenable sur les deux axes.

L'équilibre en quantité

Le « E » de « SRE » étant une caractéristique définitoire, on investit au moins 50 % du temps dans l'ingénierie ; du reste, au plus 25 % peut aller à l'astreinte, laissant jusqu'à 25 % pour les autres travaux opérationnels non liés aux projets. De cette règle des 25 % se déduit la taille minimale d'une équipe. En supposant toujours deux personnes d'astreinte (primaire et secondaire), une équipe mono-site a besoin d'au moins huit ingénieurs : avec des gardes d'une semaine, chacun est d'astreinte une semaine par mois. Pour une équipe bi-site, un minimum raisonnable est de six par site.

Configuration	Minimum d'ingénieurs	Rythme de garde	Avantage clé
Mono-site	8 (primaire + secondaire)	1 semaine sur 4	Simplicité, communication directe
Bi-site (follow the sun)	6 par site	Réparti sur deux fuseaux	Pas de gardes de nuit, santé préservée

Quand le volume de travail justifie d'agrandir une équipe mono-site, Google préfère bâtir une équipe multi-site. Les gardes de nuit nuisent à la santé ; une rotation « follow the sun » (suivre le soleil) les évite. Limiter le nombre d'ingénieurs en rotation garantit aussi qu'ils ne perdent pas le contact avec la production. Mais le multi-site impose un surcoût de communication et de coordination : le choix doit peser ces compromis, l'importance du système et la charge qu'il génère.

L'équilibre en qualité

On définit un incident comme une séquence d'événements et d'alertes liés à une même cause racine, qui seraient discutés dans un même post-mortem. En moyenne, traiter toutes les tâches d'un incident d'astreinte — analyse de cause racine, remédiation, et suivi comme la rédaction du post-mortem et la correction des bugs — prend 6 heures. Il en découle un plafond direct.

La compensation et le sentiment de sécurité

Le soutien hors heures ouvrées doit être compensé. Google offre du repos compensateur (time-off-in-lieu) ou une rémunération en numéraire, plafonnée à une fraction du salaire global. Ce plafond constitue en pratique une limite à la quantité d'astreinte qu'un individu prendra en charge : il incite à participer comme l'équipe en a besoin, tout en favorisant une distribution équilibrée et en limitant les dérives — épuisement (burnout) ou temps insuffisant pour le travail de projet.

Reste l'enjeu humain du sentiment de sécurité. La recherche distingue deux modes de pensée face à un défi : l'action intuitive, automatique et rapide, et la cognition rationnelle, concentrée et délibérée. Face aux pannes de systèmes complexes, c'est le second qui produit les meilleurs résultats. Or les hormones de stress — cortisol, CRH — provoquent des conséquences comportementales, dont la peur, qui altèrent les fonctions cognitives et poussent à des décisions sous-optimales. Sous leur influence, l'approche délibérée cède à l'action irréfléchie et à l'abus d'heuristiques : quand la même alerte page pour la quatrième fois et que les trois précédentes venaient d'une infrastructure externe, le biais de confirmation souffle d'attribuer la quatrième à la même cause — parfois à tort.

Les équipes de développement des systèmes soutenus participent généralement à une rotation 24/7 : il est toujours possible d'escalader vers ces équipes partenaires, ce qui est une façon de principe de réagir aux pannes graves aux dimensions inconnues. Lorsqu'un incident implique plusieurs équipes ou qu'on ne peut estimer une borne supérieure à sa durée, on adopte un protocole formel de gestion d'incident, soutenu par un outil web qui automatise les actions mondaines — passation de rôles, enregistrement et diffusion des mises à jour — pour que les gestionnaires se concentrent sur l'incident lui-même. Enfin, après un incident significatif, on écrit un post-mortem centré sur les événements plutôt que sur les personnes ; reconnaître les occasions d'automatisation est l'un des meilleurs moyens de prévenir les erreurs humaines.

Éviter une charge opérationnelle inappropriée

Que se passe-t-il si l'activité opérationnelle dépasse le plafond de 50 % ? L'équipe et sa direction doivent inscrire des objectifs concrets dans la planification trimestrielle pour ramener la charge à un niveau soutenable ; prêter temporairement un SRE expérimenté à une équipe surchargée peut offrir un peu d'air. Idéalement, les symptômes de surcharge sont mesurables, pour quantifier les objectifs (par exemple : tickets quotidiens < 5, événements de page par garde < 2).

Une surveillance mal configurée est une cause fréquente de surcharge. Les alertes de page doivent être alignées sur les symptômes qui menacent les SLO du service, et toutes doivent être actionnables. Des alertes de basse priorité qui dérangent l'ingénieur toutes les heures détruisent la productivité, et la fatigue d'alerte (alert fatigue) qu'elles induisent fait traiter les alertes sérieuses avec moins d'attention. Il faut aussi maîtriser le fan-out : une seule condition anormale peut générer plusieurs alertes ; on regroupe les alertes liées, et l'on vise un ratio 1:1 alerte/incident, quitte à faire taire (silence) les alertes en double pendant un incident pour rendre le calme nécessaire à la concentration.

Symptôme	Cause probable	Contre-mesure
Pages quotidiens sur le même composant	Médiane d'incidents/jour > 1	Corriger la cause racine ; objectifs trimestriels
Réveils horaires par des alertes mineures	Alertes non actionnables, mal calibrées	Aligner les pages sur les symptômes menaçant le SLO
Plusieurs alertes pour un seul incident	Fan-out excessif	Regrouper les alertes liées ; viser le 1:1 ; silence
Bruit introduit par les développeurs	Changements applicatifs déstabilisants	Objectifs communs dev/SRE ; en dernier recours, « rendre le pager »

Quand la cause échappe à l'équipe SRE — des développeurs introduisant des changements qui rendent le système plus bruyant ou moins fiable — on fixe des objectifs communs avec eux. En cas extrême, le SRE peut « rendre le pager » (give back the pager) : demander à l'équipe de développement d'assurer seule l'astreinte jusqu'à ce que le système atteigne les standards SRE. C'est rare, car il est presque toujours possible de collaborer pour réduire la charge ; mais cette possibilité de renégociation atteste de l'équilibre des pouvoirs entre les équipes, et de la façon dont la tension saine entre fiabilité et vélocité des fonctionnalités se résout au bénéfice du service.

À retenir

• La surveillance moderne de Google a fait de la collecte de séries temporelles un objet de première classe : on agrège les signaux et on élague les valeurs aberrantes pour alerter sur des objectifs de haut niveau sans noyer l'ingénieur sous le bruit machine par machine.
• Borgmon (l'ancêtre de Prometheus) collecte en boîte blanche des variables exposées via /varz, les range dans une arène de séries temporelles étiquetées, puis évalue des règles — c'est une calculatrice programmable dont l'agrégation est la pierre angulaire.
• On préfère les compteurs aux jauges et la somme des taux au taux des sommes ; les alertes exigent une durée minimale de vérité (anti-flapping) et transitent par l'Alertmanager qui inhibe, déduplique et regroupe.
• La boîte noire (Prober) complète la boîte blanche en mesurant ce que voit l'utilisateur ; séparer règles et cibles et viser un coût de maintenance sous-linéaire rendent la surveillance soutenable à l'échelle.
• Le temps de réaction d'astreinte découle de la disponibilité visée (4 neufs ≈ 13 min/trimestre → réaction en minutes) ; on plafonne le travail opérationnel à 50 %, dont au plus 25 % d'astreinte, d'où un minimum de 8 ingénieurs mono-site.
• Qualité de l'astreinte : un incident coûtant ~6 heures, le maximum est de 2 incidents par garde de 12 heures, avec une médiane idéalement à 0 ; au-delà, des mesures correctives s'imposent.
• Une astreinte saine combine compensation (repos ou numéraire plafonné), sécurité psychologique (escalade, procédures, post-mortems sans blâme favorisant la pensée délibérée plutôt que l'intuition), et la lutte contre la surcharge (alertes actionnables, ratio 1:1) comme contre la sous-charge.