Observabilité : une alerte qui ne dit pas quoi faire finit ignorée

Une équipe d'exploitation qui reçoit quarante alertes par jour n'en traite aucune. Elle apprend en quelques semaines lesquelles sont du bruit, et elle finit par les ignorer toutes — y compris celle qui compte.

C'est le mode de défaillance le plus courant de l'observabilité, et il est organisationnel plutôt que technique.

La règle de l'alerte

Une alerte doit correspondre à une action humaine immédiate. Si personne ne doit rien faire en la recevant, ce n'est pas une alerte, c'est une métrique. Elle a sa place dans un tableau de bord, pas dans une notification.

Ce critère élimine généralement la majorité des alertes d'une configuration existante.

Les quatre attributs d'une alerte utile

Un destinataire nommé. Pas une liste de diffusion, pas un canal général. Une personne d'astreinte identifiée, avec une escalade définie si elle ne répond pas.

Un lien vers un runbook. Le runbook dit quoi vérifier, dans quel ordre, et quoi faire selon le résultat. Une alerte sans runbook oblige la personne d'astreinte à réinventer le diagnostic à trois heures du matin.

Un seuil justifié. Pourquoi 85 % et pas 90 % ? Si personne ne sait, le seuil a été copié d'un modèle et déclenchera au mauvais moment. Un seuil doit venir d'une observation : à partir de quelle valeur un incident réel est-il survenu ?

Une durée. Alerter sur une valeur instantanée produit du bruit ; alerter sur une valeur maintenue pendant cinq minutes produit un signal.

Sur quoi alerter en priorité

L'ordre qui fonctionne, du plus utile au moins utile :

1. Les symptômes visibles par l'utilisateur. Taux d'erreur des requêtes, temps de réponse au percentile 95, échec d'un traitement métier planifié. C'est ce qui compte réellement.
2. Les seuils de capacité qui approchent. Espace disque, quotas, connexions à la base : ceux qui donnent un délai avant l'incident.
3. Les échecs de traitements de fond. Sauvegardes, imports, jobs nocturnes. Un échec silencieux de sauvegarde pendant trois semaines est un scénario classique.

Alerter sur l'utilisation processeur d'une machine, en revanche, est presque toujours du bruit : une machine à 90 % qui répond correctement ne pose pas de problème.

Le nettoyage périodique

Une fois par trimestre, listez les alertes déclenchées et classez-les en trois catégories : celles qui ont conduit à une action, celles qui ont été acquittées sans action, et celles qui n'ont pas été acquittées du tout.

Les deux dernières catégories doivent être supprimées ou reconfigurées. Un système d'alerte qui n'est jamais élagué se dégrade mécaniquement.

Le lien avec le contrat de service

Si vous avez un engagement de disponibilité avec un prestataire, vérifiez que la mesure vient d'une source que vous contrôlez, ou au minimum d'une source partagée. Un engagement mesuré uniquement par les outils du prestataire est un engagement invérifiable, et il le sait.