Concevoir des alertes utiles : peu de notifications, chacune avec une prochaine étape

Objectif

Un ensemble d'alertes où chaque notification déclenche une action et où personne n'apprend à ignorer le bipeur.

Prérequis

Le chapitre « Monitoring Distributed Systems » du livre SRE de Google cite les quatre signaux d'or : latence, trafic, erreurs et saturation, distingue les symptômes (« qu'est-ce qui est cassé ») des causes (« pourquoi ») et exige que chaque réveil guide vers une action (« Every page should be actionable »). Le SRE Workbook décrit des alertes fondées sur le taux de consommation du budget d'erreur (« burn rate »). En pratique, il faut des indicateurs de service mesurés à la frontière des utilisateurs, un système d'alerte avec un délai d'attente avant déclenchement — chez Prometheus, la clause for, complétée par keep_firing_for contre le flottement en phase de résorption — et un chemin d'escalade documenté.

Étapes

1. Pour chaque service, définir les symptômes ressentis par les utilisateurs : taux d'erreur, percentiles de latence, disponibilité, fraîcheur des données. Seuls ceux-ci peuvent réveiller. Les causes telles qu'une forte charge CPU ou un disque rempli à 80 pour cent deviennent des tickets ou des pavés de tableau de bord.
2. Dériver les seuils des objectifs : le Workbook cite comme point de départ pour un réveil une consommation de 2 pour cent du budget d'erreur en une heure ou de 5 pour cent en six heures ; un taux plus lent (10 pour cent en trois jours) génère un ticket plutôt qu'un réveil.
3. Munir chaque règle d'un délai d'attente (for: 10m) pour qu'un unique écart ne déclenche pas d'alerte, et ajouter une règle qui se déclenche lorsque le système de mesure lui-même cesse de fournir des données.
4. Joindre à chaque alerte, dans les annotations, un lien vers le runbook, les tableaux de bord concernés et la première étape de vérification.
5. Porter l'urgence comme étiquette (severity: page face à ticket) et piloter le routage en conséquence ; la nuit, seul le premier niveau atteint une personne.
6. Passer en revue chaque semaine toutes les alertes déclenchées : toute alerte qui n'a entraîné aucune action est réajustée ou supprimée ; tout incident sans alerte préalable en reçoit une.

Résultat attendu

Peu de réveils, chacun avec une prochaine étape claire ; les incidents sont repérés par la surveillance avant les utilisateurs ; l'équipe d'astreinte fait confiance au bipeur.

Limites et base de vérification

Les alertes sur symptômes détectent tardivement les dégradations progressives ; quelques indicateurs avancés de faible urgence (longueur de file d'attente, prévision « disque plein dans deux jours ») les complètent. Les principes suivent les chapitres SRE cités, la mécanique suit la documentation Prometheus citée ; à partir de quel taux d'alertes une équipe se désensibilise n'est pas démontré ici.