Chaque alerte doit mériter de réveiller quelqu’un

La plupart des ingénieurs d’astreinte savent vous dire quelles alertes ils ignorent. Ils le disent en haussant les épaules : « celle-là sonne tous les mardis », « celle-là se résout toute seule », « celle-là est cassée depuis la migration ». Personne n’a décidé de les ignorer. L’équipe a simplement appris, une fausse alerte après l’autre, que le pager ment.

C’est ça, le vrai coût du bruit. Les nuits hachées comptent, bien sûr. Mais le vrai problème arrive le jour où un incident réel se déclenche et reçoit le même haussement d’épaules.

Les symptômes, pas les causes

La source de bruit la plus fréquente qu’on rencontre : alerter sur des causes plutôt que sur des symptômes.

CPU à 85 %, un pod qui redémarre, une file au-delà d’un seuil choisi il y a deux ans : ce sont des causes possibles de douleur utilisateur. Parfois, ça compte. Souvent, non. Un service peut tourner à 90 % de CPU toute la journée et servir chaque requête dans les temps.

Les symptômes, c’est ce que vivent les utilisateurs :

• des requêtes qui échouent
• des requêtes qui ralentissent
• du travail qui ne se fait pas (jobs bloqués, messages non traités)

Si vous alertez sur les symptômes, vous réveillez quelqu’un quand ça compte. Les causes ont leur place sur les dashboards, que l’astreinte consulte après avoir été appelée, pour comprendre pourquoi.

Les quatre questions

Pour chaque alerte qui peut réveiller un humain, on pose quatre questions. Si la réponse à l’une d’elles est « non », l’alerte est corrigée, rétrogradée en ticket, ou supprimée.

1. Un utilisateur est-il touché, ou sur le point de l’être ? Sinon, ce n’est pas urgent.
2. Faut-il un humain maintenant ? Si ça peut attendre demain matin, c’est un ticket, pas une alerte.
3. Y a-t-il une première action claire ? Une alerte sans lien vers un runbook, c’est une devinette.
4. Remarquerait-on son absence ? Si elle n’a jamais mené à une vraie correction, c’est de la décoration.

Alerter sur la consommation du budget d’erreur

Une fois qu’un parcours utilisateur a son SLO, plus besoin de deviner des seuils. On alerte sur la vitesse à laquelle on consomme le budget d’erreur. Une consommation rapide réveille quelqu’un ; une consommation lente ouvre un ticket.

Voici une alerte multi-fenêtres simplifiée, en syntaxe Prometheus, pour un SLO de disponibilité à 99,9 % :

- alert: CheckoutErrorBudgetFastBurn
  expr: |
    (
      sum(rate(http_requests_total{service="checkout",code=~"5.."}[1h]))
      / sum(rate(http_requests_total{service="checkout"}[1h]))
    ) > (14.4 * 0.001)
    and
    (
      sum(rate(http_requests_total{service="checkout",code=~"5.."}[5m]))
      / sum(rate(http_requests_total{service="checkout"}[5m]))
    ) > (14.4 * 0.001)
  labels:
    severity: page
  annotations:
    summary: Checkout consomme son budget d'erreur trop vite
    runbook: https://runbooks.internal/checkout/error-budget

La fenêtre longue évite de réveiller quelqu’un pour un pic isolé. La fenêtre courte fait retomber l’alerte vite une fois le service rétabli. Et l’annotation runbook n’est pas optionnelle.

Mener la revue

Pas besoin d’un chantier d’un trimestre. Une première passe ressemble à ça :

Étape	Ce qu’on fait
Extraire	Toutes les alertes qui ont réveillé quelqu’un sur 90 jours, avec leur nombre de déclenchements et qui les a acquittées.
Trier	Par nombre de déclenchements. En haut de la liste, il y a en général une poignée d’alertes qui font l’essentiel du bruit.
Questionner	Les quatre questions, alerte par alerte, avec les personnes qui portent réellement le pager.
Agir	Corriger, rétrograder en ticket, ou supprimer. Et noter pourquoi.
Recommencer	Une courte revue d’alertes à chaque passation d’astreinte.

Supprimer des alertes fait peur. Ça mérite d’être dit : une alerte que tout le monde ignore ne protège déjà de rien. La retirer, c’est juste être honnête.

À quoi ressemble la cible

Vous êtes au bon endroit quand l’astreinte fait confiance au pager. Quand il sonne, on se lève. C’est presque toujours réel, et que l’alerte dit presque toujours par où commencer.

Y arriver, c’est surtout un travail de conception des alertes. C’est aussi l’une des premières choses qu’on regarde lors d’un audit.