Concevoir des alertes que personne n'ignore

Chaque alerte qui se déclenche sans qu'un humain ait à agir apprend, en silence, à votre équipe à ignorer la suivante. Faites cela quelques semaines et l'alerte qui compte vraiment finit dans un canal que personne ne lit, ou est balayée à 3 h du matin à côté des dix-sept autres qui ne comptaient pas. Le vrai coût, ce n'est pas la panne qui vous a échappé : c'est l'ingénieur d'astreinte qui a appris, à juste titre, que les alertes ne sont que du bruit de fond.

L'objectif ici n'est donc pas 'plus de supervision'. C'est l'inverse : une poignée d'alertes dont chacune signifie qu'un humain doit agir maintenant, branchées sur la vitesse à laquelle vous consommez votre budget d'erreur, tout le reste étant routé là où ça ne réveille personne. Je vais dérouler les calculs, vous donner des règles Prometheus prêtes à coller, et parler du processus qui garde tout cela honnête.

Si un humain n'a pas de décision intelligente à prendre, cela ne devrait pas le réveiller. Appliquez cette seule règle sans pitié et l'essentiel du bruit disparaît.

Le bruit est en soi un problème de fiabilité

Traitez l'astreinte comme n'importe quel système doté d'un SLO. Une cible raisonnable : pas plus d'un ou deux pages exploitables par tour de garde, et quasiment zéro page injustifié. Dès que vous dépassez cela, le délai avant qu'on réagisse grimpe, les gens coupent les notifications, et la confiance dans tout le système d'alertes s'effondre — bien plus dangereux qu'un tableau passé au rouge.

Chaque page injustifié dépense une chose difficile à récupérer : la présomption qu'un page est réel. Protégez cette présomption comme vous protégeriez les données de production.

L'essentiel de la douleur d'astreinte est un problème de bruit et de routage : des dizaines d'alertes de cause se réduisent à une poignée de pages qui ont vraiment besoin d'un humain.

Trois destinations, une seule réveille quelqu'un

Avant d'ajuster le moindre seuil, décidez où vont les signaux. La plupart des pagailles d'alertes sont, au fond, des pagailles de routage : tout pointait vers le pager.

Page — un humain doit agir en quelques minutes. Réservé à un préjudice visible par l'utilisateur, soutenu et qui brûle le budget vite.
Ticket — un humain doit agir, mais cela peut attendre les heures ouvrées : fuites lentes de budget, tendances de capacité, un certificat qui expire la semaine prochaine.
Dashboard / journal — simple prise de conscience. Personne n'est réveillé ; cela alimente la vue d'astreinte et la revue hebdomadaire.

Votre pic d'erreur d'une seconde, qui s'est rétabli tout seul, appartient au troisième seau : visible sur un dashboard, enregistré contre le budget, revu plus tard. Il est réel, il vous a coûté quelque chose, et il ne justifie certainement pas un appel.

Décidez où va chaque signal avant de toucher au moindre seuil. Seul le page réveille quelqu'un ; le pic d'une seconde qui s'est rétabli appartient à un dashboard.

Alertez sur les symptômes, pas sur les causes

Les alertes basées sur les causes — 'CPU > 80 %', 'disque à 90 %', 'pod redémarré' — se déclenchent à tout bout de champ et coïncident rarement avec un utilisateur qui souffre. Les systèmes modernes tournent chauds et redémarrent des choses exprès ; c'est sain, ce n'est pas un incident. Les alertes basées sur les symptômes préviennent de ce que l'utilisateur ressent vraiment :

Les requêtes échouent-elles ? (taux d'erreurs)
Sont-elles lentes au point que l'utilisateur le remarque ? (SLI de latence)
Le travail passe-t-il ? (débit, âge de la file, fraîcheur des données)

Alertez sur le symptôme et vous pourrez supprimer la plupart des alertes de cause : vous apprendrez que le disque s'est rempli parce que les requêtes ont commencé à échouer — et vous l'apprendrez avec un page au lieu de neuf. Les causes appartiennent aux dashboards et aux runbooks, où elles aident au diagnostic, pas au pager, où elles ne font que se disputer votre attention.

Alertez sur ce que l'utilisateur ressent ; gardez les causes sur les dashboards et dans les runbooks, où elles aident au diagnostic au lieu de se disputer l'attention.

Pourquoi un seuil unique ne peut jamais gagner

L'alerte SLO naïve, c'est 'préviens-moi quand on brûle du budget'. Choisissez une seule fenêtre et vous voilà coincé dans un mauvais compromis. Courte, elle devient nerveuse : un hoquet de 30 secondes réveille quelqu'un pour un problème déjà réglé tout seul. Longue, elle devient molle : vous pouvez être 20 minutes en pleine panne avant que quoi que ce soit ne se déclenche.

C'est exactement le problème du pic d'une seconde. Un pic bref consomme une miette de budget (vrai, et bon à enregistrer) mais ne devrait jamais déclencher de page — et un seuil unique ne distingue pas 'bref et rétabli' de 'soutenu et qui empire'. Il vous faut deux échelles de temps à la fois.

Le burn rate, depuis le début

Partez du budget. Un SLO de disponibilité de 99,9 % sur 30 jours autorise 0,1 % de requêtes en échec — c'est votre budget d'erreur, environ 43 minutes de panne totale équivalente sur le mois. Dépensez-le lentement et tout va bien ; dépensez-le en un après-midi et vous avez un incident.

Le burn rate, c'est la vitesse à laquelle vous dépensez par rapport à 'pile dans le budget'. Un burn rate de 1 dépense exactement 100 % du budget sur la fenêtre du SLO — soutenable. Un burn rate de 14,4 dépense 14,4× trop vite : à ce rythme vous cramez tout le budget de 30 jours en environ deux jours, et vous en avez déjà brûlé 2 % dans la dernière heure.

burn_rate = (erreurs / total) / (1 - SLO)

# SLO de 99.9%  ->  1 - SLO = 0.001
# si 1.44% des requetes echouent en ce moment :
#   burn_rate = 0.0144 / 0.001 = 14.4
#
# budget depense sur une fenetre = burn_rate * (fenetre / periode_SLO)
#   14.4 * (1h  / 720h) =  2%   du budget de 30 jours, en une heure
#    6   * (6h  / 720h) =  5%   en six heures
#    1   * (72h / 720h) = 10%   en trois jours

Ces trois lignes ne sont pas arbitraires : ce sont les niveaux d'alerte. Décidez combien de budget vous acceptez de perdre avant d'impliquer un humain, et le burn rate et la fenêtre tombent directement des calculs.

Chaque niveau de burn rate n'est qu'une pente. 14.4× vide un budget de 30 jours en environ deux jours, 6× en cinq, 1× arrive pile au jour 30 — et c'est de là que viennent les seuils d'alerte.

Multi-fenêtre, multi-burn-rate

La solution au piège du seuil unique, c'est de surveiller une fenêtre longue et une fenêtre courte ensemble, avec plus d'un burn rate. La fenêtre longue confirme que le problème est réel et soutenu ; la courte — environ un douzième de la longue — rend l'alerte rapide à se déclencher et, surtout, rapide à s'éteindre une fois rétabli. L'alerte ne se déclenche que lorsque les deux fenêtres dépassent le seuil.

Un pic d'une seconde déclenche la fenêtre courte mais jamais la longue, donc il ne page jamais — une combustion soutenue déclenche les deux et page. La fenêtre courte fait aussi retomber l'alerte quelques minutes après le rétablissement, et c'est ce qui met fin au flapping.

La sévérité vient du burn rate, pas de l'empilement de fenêtres de même taille. Combustion rapide et raide = réveiller quelqu'un maintenant. Combustion lente et douce = un ticket pour demain :

SEVERITE    BURN    FENETRE-L  FENETRE-C   BUDGET BRULE      DESTINATION
----------------------------------------------------------------------
critique    14.4x   1h         5m          2%  en 1 heure    page
eleve        6x     6h         30m         5%  en 6 heures   page
avert.       1x     3d         6h          10% en 3 jours    ticket

Lisez-le comme vous le diriez à voix haute : une combustion raide sur un horizon court est un page critique ; une combustion douce qui n'apparaît qu'au bout de plusieurs jours est un ticket d'avertissement pour la fuite lente que le niveau rapide laisserait passer. Lancez les trois en même temps : ils ne se gênent pas, ils couvrent des formes de panne différentes.

La fenêtre courte, c'est la partie qui tue le bruit. Comme l'alerte a aussi besoin de la fenêtre courte active, elle cesse de page quelques minutes après le rétablissement, au lieu de traîner sur toute la durée de la fenêtre longue. C'est ce qui met fin au flapping — et au page de 3 h du matin pour un truc réglé il y a 90 secondes.

Les requêtes

Calculez le SLI une seule fois

Définissez le symptôme une seule fois comme un ratio d'erreurs. Dans Prometheus, vous le pré-calculez par fenêtre avec des recording rules — peu coûteux, lisible et réutilisé par chaque dashboard. Dans Datadog, vous définissez le SLI une fois dans un SLO basé sur des métriques et il calcule les fenêtres pour vous.

groups:
- name: payments-slo
  rules:
  # SLI du symptôme : fraction de requêtes mauvaises (5xx ou trop lentes)
  - record: job:sli_err:ratio5m
    expr: |
      sum(rate(http_requests_total{job="payments",code=~"5.."}[5m]))
      / sum(rate(http_requests_total{job="payments"}[5m]))
  - record: job:sli_err:ratio1h
    expr: |
      sum(rate(http_requests_total{job="payments",code=~"5.."}[1h]))
      / sum(rate(http_requests_total{job="payments"}[1h]))
  # ...répétez pour les fenêtres 30m, 6h et 3d sur lesquelles vous alertez

# Datadog calcule les fenêtres pour vous : définissez le SLI une fois comme un
# SLO basé sur des métriques (bons événements / total). Le ratio d'erreur brut :
100 * (
  sum:trace.http.request.errors{service:payments}.as_count()
  / sum:trace.http.request.hits{service:payments}.as_count()
)

Alert rules — multi-fenêtres, multi-burn-rate

Le SLO est de 99,9%, donc le dénominateur du budget est 0,001. Chaque niveau exige que sa fenêtre longue et sa fenêtre courte dépassent toutes deux le burn rate avant de se déclencher — écrit explicitement dans Prometheus, et un paramètre natif du monitor de burn rate de Datadog.

- alert: PaymentsBudgetFastBurn
  expr: |
    job:sli_err:ratio1h / 0.001 > 14.4
    and
    job:sli_err:ratio5m / 0.001 > 14.4
  labels: { severity: page }
  annotations:
    summary: "Payments brûle le budget à 14,4x (2%/h)"
    runbook: "https://runbooks/payments/error-budget"

- alert: PaymentsBudgetSlowBurn
  expr: |
    job:sli_err:ratio3d / 0.001 > 1
    and
    job:sli_err:ratio6h / 0.001 > 1
  labels: { severity: ticket }
  annotations:
    summary: "Payments : fuite lente de budget (10%/3j)"
    runbook: "https://runbooks/payments/error-budget"

# Datadog fait le multi-fenêtres nativement — un monitor de burn rate sur le SLO,
# avec les fenêtres longue et courte en paramètres :

# burn rapide -> page  (2% du budget de 30 jours en 1h)
burn_rate("payments-availability").over("30d").long_window("1h").short_window("5m") > 14.4

# burn lent -> ticket  (10% en 3 jours)
burn_rate("payments-availability").over("30d").long_window("3d").short_window("6h") > 1

Ajoutez le niveau 6× / 6h / 30m au milieu et vous avez couvert les pannes rapides, les dégradations moyennes et les fuites lentes avec trois alertes par service — pas trente.

Chaque page doit mériter sa place

Les calculs vous donnent un signal propre ; le processus le garde propre. Soumettez chaque page à quatre tests :

Exploitable — si l'astreinte ne peut rien faire tout de suite, c'est un ticket ou on le supprime.
Avec runbook — le page renvoie à 'ce qui ne va pas et par où commencer', pas à une fouille du wiki à 3 h du matin.
Avec un propriétaire — il arrive à exactement une équipe, et cette équipe peut le modifier.
Apporte du neuf — il dit quelque chose que le page précédent ne disait pas ; regroupez les doublons.

Ensuite, rendez deux habitudes peu coûteuses et régulières. Une revue hebdomadaire du budget d'erreur : combien on a dépensé, sur quoi, est-on dans les temps. Et une revue des alertes : passez en revue chaque page qui s'est déclenché et, pour chacun, gardez-le, corrigez-le ou supprimez-le. Supprimer des alertes est le travail de fiabilité le plus sous-estimé qui soit.

Anti-modèles à supprimer cette semaine

Seuils fixes sur des métriques en dents de scie ('CPU > 80 %') : ils se déclenchent sous une charge saine.
Pages disque ou mémoire par machine : alertez sur le symptôme visible par l'utilisateur ; le reste se planifie en tickets.
Pages 'informatifs' : une contradiction ; envoyez-les sur un dashboard.
Alerter sur une cause dont vous alertez déjà le symptôme : vous prendrez deux pages pour un même incident.
Toute alerte sans runbook et sans propriétaire : personne ne peut agir, donc c'est du pur bruit.

Comment y arriver sans voler à l'aveugle

Définissez un SLI et un SLO par parcours utilisateur (paiement, connexion, commande) : des symptômes, pas des machines.
Ajoutez les recording rules pour les fenêtres sur lesquelles vous alerterez.
Déployez les trois niveaux de burn rate d'abord en mode ticket seulement — pas encore de pages.
Observez deux ou trois semaines ; comparez ce qui aurait page avec ce qui fut vraiment un incident.
Faites passer le niveau rapide en page ; gardez le lent en tickets.
Supprimez les pages de cause que cela rend redondants — un par un, en surveillant le budget.
Mettez en place la revue hebdomadaire du budget et la revue des alertes, et continuez à élaguer.

Le but n'a jamais été 'moins d'alertes' comme métrique de vanité. C'est que, quand le téléphone sonne, ce soit réel, exploitable, avec un runbook qui attend — pour que les gens fassent confiance, répondent, et que le système reste fiable parce que les humains qui le défendent ne sont pas épuisés.