La fatigue d'alerte est un problème de conception, pas de discipline
Par L'équipe Atflow
Chaque équipe qui assure une astreinte depuis plus d'un an connaît le même canal : créé avec de bonnes intentions, mis en sourdine par la moitié des ingénieurs, et consulté seulement après que quelqu'un a écrit « la prod est down ? » dans un autre canal. Le diagnostic habituel est que les gens manquent de discipline. Ce diagnostic est faux, et il mène à des solutions qui aggravent le problème.
Une alerte est une demande de votre attention
Chaque notification affirme qu'une personne doit interrompre ce qu'elle fait. Quand la plupart d'entre elles ne le justifient pas, les gens apprennent — à juste titre — que le canal ne vaut pas la peine d'être interrompu. Mettre en sourdine est une réaction rationnelle face à un canal qui a menti.
Les trois choses qui règlent vraiment le problème
- Regrouper les échecs identiques. Trois cents occurrences d'un même bug constituent un seul problème et doivent produire un seul message.
- Acheminer selon la conséquence, pas selon l'étiquette de gravité. Une carte refusée envoie un e-mail au client ; une écriture en échec alerte l'astreinte.
- Laisser les rapports connus pour être bruyants emprunter une branche plus discrète, au lieu de désactiver complètement les alertes.
- Escalader une fois par incident, pas une fois par événement.
“Si votre canal d'alertes est en sourdine, c'est le canal qui est cassé. Les gens se comportent raisonnablement.”
Ces trois points sont des décisions d'acheminement : ils doivent donc vivre dans un flux que l'on peut voir et modifier, et non être éparpillés dans des instructions if à travers quatre services.