Un objectif de niveau de service chiffre la fiabilité qu’on promet, un budget d’erreur dit combien de marge il reste sur la période. Mais ni l’un ni l’autre ne répond à la seule question qui compte à l’instant où ça dérape : faut-il réveiller quelqu’un maintenant, ou est-ce que ça peut attendre le matin ? Une alerte qui se contente de surveiller le budget restant arrive systématiquement en retard, puisqu’elle ne sonne qu’une fois le mal fait. C’est ce trou que comble le burn-rate alerting multi-fenêtres, une méthode formalisée par Google dans son SRE workbook et qui se simplifie très bien pour une équipe sans SRE dédié.

Le burn rate, une vitesse plutôt qu’un niveau

Le burn rate mesure la vitesse à laquelle on consomme le budget d’erreur, pas le niveau restant. Un burn rate de 1 signifie qu’on dépense le budget exactement au rythme prévu par le SLO ; un burn rate de 10 signifie qu’au rythme actuel, tout le budget de la période partirait dix fois plus vite que prévu. La formule tient en une ligne : burn rate = (part du budget consommée) divisée par (part de la période écoulée). Sur un SLO mensuel, consommer 5 % du budget en une seule heure donne un burn rate de 0,05 / (1h / 720h) = 36 — un rythme qui viderait le budget du mois en moins d’un jour s’il se maintenait.

Le problème d’une seule fenêtre

L’approche naïve consiste à alerter dès que le burn rate calculé sur une fenêtre dépasse un seuil. Le choix de la fenêtre impose alors un compromis frustrant. Une fenêtre courte (5 minutes) détecte vite une vraie panne, mais réagit aussi à un pic isolé qui s’est déjà résorbé au moment où le pager sonne — le même défaut que l’alerte sans clause for décrite dans les règles d’alerting Prometheus par symptôme. Une fenêtre longue (plusieurs heures) lisse ce bruit, mais détecte une vraie dégradation trop tard : le temps que la moyenne glissante bouge, une bonne partie du budget est déjà partie.

Deux fenêtres, une seule décision

La solution n’est pas de choisir entre les deux fenêtres, mais d’exiger leur accord. Une règle multi-fenêtres calcule le burn rate sur une fenêtre longue (par exemple 1 heure) pour juger si la situation est sérieuse, et sur une fenêtre courte (par exemple 5 minutes) pour confirmer qu’elle est toujours en cours au moment où l’alerte se déclenche. L’alerte ne part que si les deux dépassent le même seuil en même temps. Un pic bref fait grimper la fenêtre courte mais pas la longue : pas d’alerte. Une dégradation qui s’installe finit par faire grimper les deux : alerte, et rapidement, parce que la fenêtre courte réagit vite dès que la fenêtre longue a confirmé l’ampleur du problème.

Deux paliers pour deux urgences

Une seule paire de fenêtres ne suffit pas à couvrir tous les cas, parce qu’une consommation lente du budget n’a pas besoin de sortir quelqu’un du lit. Deux paliers suffisent pour une équipe réduite. Un palier rapide, sur une fenêtre longue courte (une heure, confirmée à 5 minutes) et un seuil de burn rate élevé, qui page : la trajectoire viderait le budget en un jour ou deux si rien ne change. Un palier lent, sur une fenêtre longue plus large (trois jours, confirmée à quelques heures) et un seuil de burn rate modéré, qui ouvre seulement un ticket à traiter en heures ouvrées : la trajectoire viderait le budget en une semaine ou plus. Le calcul du paragraphe précédent donne le seuil exact pour chaque palier une fois la fenêtre et le temps d’épuisement visé choisis.

Ce qu’il faut déjà avoir instrumenté

Ces règles ne calculent rien de plus que ce que la méthode RED expose déjà : un taux de requêtes en erreur, agrégé sur deux fenêtres au lieu d’une. Le point de départ Prometheus ressemble à ceci, avec N le burn rate du palier et objectif la part d’erreurs tolérée par le SLO (0,001 pour 99,9 %) :

(
  sum(rate(http_requests_total{status=~"5.."}[1h]))
  /
  sum(rate(http_requests_total[1h]))
) > (N * objectif)
and
(
  sum(rate(http_requests_total{status=~"5.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
) > (N * objectif)

L’opérateur and fait tout le travail : sans lui, on retombe sur une alerte à une seule fenêtre. Chaque palier (page ou ticket) est une seconde règle avec sa propre paire de fenêtres et son propre N, routée différemment dans Alertmanager par le label severity, exactement comme pour les alertes par symptôme.

Où ça se raccorde

Le burn-rate alerting ne remplace pas la discipline symptôme contre cause, il l’affine sur un seul axe : la vitesse de consommation d’un budget déjà défini plutôt qu’un seuil figé. Un dispositif de ce type reste au cœur d’une mission fiabilité et observabilité ; d’autres sujets dans la catégorie observabilité.