0%
Des alertes qu'on ne coupe pas

Alertes

Symptômes, seuils, budget d'erreur, et la fatigue d'alerte qui ruine tout le dispositif.

10-15 min

Des alertes qu'on ne coupe pas

Regardez le canal d'alertes d'une équipe qui existe depuis deux ans. Vous y trouverez cent quarante messages par semaine, dont cent trente sont acquittés sans action, parce que tout le monde sait qu'ils se résolvent seuls. Demandez à un ingénieur d'astreinte ce qu'il fait quand son téléphone sonne à quatre heures du matin : il regarde le titre, reconnaît un nom familier, et se rendort. Il a raison statistiquement — l'alerte est fausse dans 93 % des cas. Le jour où elle sera vraie, il se rendormira aussi.

C'est le seul mode d'échec qui compte réellement en matière d'alerte, et il ne se corrige pas en ajoutant des règles. Une alerte n'a de valeur que si elle est crue, et la crédibilité est une ressource collective qui se consomme : chaque notification sans action à mener en dépense une part, définitivement. Le travail consiste donc à en avoir peu, et à ce que chacune corresponde à quelque chose qu'un humain doit faire immédiatement. Tout le reste — les seuils sur le processeur, les avertissements de disque à 70 %, les pics de latence de trois minutes — appartient à un tableau de bord ou à un rapport hebdomadaire, pas à un téléphone.

Commentaires

Les commentaires sont alimentés par GitHub Discussions

Connectez-vous avec GitHub pour participer à la discussion

Lien copié !