Quatre alertes qui réveillent quelqu'un, et rien d'autre

L'affirmation

Si plus de quatre conditions de votre système peuvent réveiller une personne à trois heures du matin, aucune ne sera prise au sérieux d'ici mars. La fatigue d'alerte n'est pas un problème de discipline à régler par de la formation. C'est un problème d'arithmétique : quelqu'un réveillé six fois par mois pour des riens finira, à juste titre, par supposer que la septième fois n'est rien non plus.

Alertez sur les symptômes, pas sur les causes

L'instinct pousse à alerter sur tout ce qui se mesure : processeur au-dessus de 80 %, mémoire au-dessus de 90 %, profondeur de file disque, retard de réplication, redémarrages de conteneurs. Ce sont toutes des causes. Aucune n'est nécessairement un problème : un traitement par lots qui sature le processeur vingt minutes, c'est le système qui fait son travail.

Alertez plutôt sur les quatre symptômes qu'une cliente pourrait réellement vivre :

1. Le site ne répond plus. Une sonde externe depuis deux régions échoue trois fois de suite. Pas une seule : un échec isolé relève généralement du réseau du vérificateur.
2. Les requêtes échouent. Le taux de 5xx dépasse 2 % des requêtes sur une fenêtre de cinq minutes, avec un plancher d'au moins 20 requêtes pour que deux erreurs un dimanche tranquille ne réveillent personne.
3. Les requêtes sont inutilisables tant elles sont lentes. La latence au 95e centile dépasse trois fois sa valeur normale pendant dix minutes. Utilisez un centile, jamais une moyenne : la moyenne masque la queue de distribution, et c'est dans cette queue que les clients s'en vont.
4. Le travail ne se fait plus. La profondeur de votre file de tâches croît sans redescendre depuis quinze minutes, ou la plus ancienne tâche non traitée dépasse dix minutes. C'est celle que les équipes omettent le plus souvent, et c'est ainsi que les factures cessent silencieusement de partir.

Tout le reste va vers un tableau de bord ou un billet, pas vers un téléphone.

Donnez un budget à chaque alerte, pas un seuil

Les seuils invitent au débat. Les budgets d'erreur y mettent fin. Choisissez une cible de disponibilité et faites la division :

99,9 %  = 43,8 minutes d'indisponibilite par 30 jours
99,95 % = 21,9 minutes
99,99 % =  4,4 minutes

Pour la plupart des PME, 99,9 % est la cible honnête : elle autorise un incident de quarante minutes une fois par mois sans rien enfreindre, ce qui correspond à ce qu'une équipe de deux personnes peut réellement absorber. N'annoncez pas 99,99 % à moins que quelqu'un soit de garde et payé pour l'être : un seul redémarrage imprévu épuise le budget du mois entier.

Une fois le budget établi, le seuil d'alerte découle du rythme de consommation plutôt que du goût. Une règle qui brûle 5 % du budget mensuel en une heure mérite de réveiller quelqu'un ; une qui mettrait trois semaines à l'épuiser est un billet pour lundi.

Des avertissements qui sont en fait des prédictions

Certaines conditions méritent de l'attention sans urgence, et la forme utile est une prévision plutôt qu'un niveau :

# Le disque sera plein d'ici quatre jours au rythme actuel
predict_linear(node_filesystem_avail_bytes[6h], 4*24*3600) < 0

Même chose pour l'expiration d'un certificat TLS à quatorze jours et pour une file de tâches échouées jamais vidée. Cela part vers un canal en heures ouvrables. Ce sont ces deux catégories — disque et certificats — qui expliquent une large part des urgences évitables, et toutes deux s'annoncent des jours à l'avance pour qui regarde.

Chaque alerte a besoin d'un lien vers une marche à suivre

Une alerte qui dit HighErrorRate firing on api-prod n'apprend rien à son destinataire. La notification devrait porter la valeur actuelle, le seuil, l'heure du dernier déploiement et un lien vers trois commandes précises à exécuter d'abord. Rédiger cette marche à suivre prend vingt minutes par alerte. Avec quatre alertes seulement, cela fait quatre-vingts minutes de travail, ce qui reste le meilleur argument pratique pour garder la liste courte.

Qui les reçoit

Quatre alertes ont tout de même besoin d'un destinataire nommé. Pour une équipe sans garde formelle, l'arrangement praticable est une personne principale par semaine, désignée à l'avance, avec une seconde inscrite en escalade après quinze minutes sans accusé de réception. Publiez le calendrier là où toute l'entreprise le voit, pour que personne n'ait à deviner qui appeler et pour que la personne de garde puisse décliner un engagement du jeudi soir sans négocier.

Révisez la liste chaque trimestre

Sortez toutes les alertes des quatre-vingt-dix derniers jours et triez-les en trois piles : action immédiate requise, aurait pu attendre le matin, ou n'était rien. Si la troisième pile dépasse le cinquième du total, l'alerte qui l'a majoritairement produite est ajustée ou supprimée avant tout ajout. Une alerte qui n'a jamais attrapé un vrai problème n'est pas une assurance. C'est une taxe sur le sommeil de votre équipe, et elle rend moins probable qu'on réponde à la vraie.