Le pager vient de sonner et la production est dégradée. Racontez-moi vos quinze premières minutes.

Accusez réception de l'alerte, confirmez l'impact utilisateur, et déclarez un incident avec un responsable clair et un canal de communication. Ensuite, arrêtez l'hémorragie avant de diagnostiquer : regardez ce qui a changé récemment et revenez en arrière ou désactivez le suspect si la chronologie colle. Tenez une chronologie des actions dans le canal, communiquez aux parties prenantes à intervalle fixe, et ne lancez l'analyse des causes qu'une fois l'impact contenu.

D'abord j'accuse réception de l'alerte pour que personne d'autre ne double le travail, puis je vérifie si des utilisateurs sont vraiment touchés, parce qu'une alerte qui se déclenche et des clients qui souffrent, ce n'est pas toujours la même chose. Si c'est réel, je déclare un incident, je prends le rôle de commandant ou je le confie explicitement à quelqu'un, et j'ouvre un canal pour qu'il y ait un seul endroit où vit la chronologie. Ensuite, atténuation avant diagnostic. La question la plus rentable, c'est qu'est-ce qui a changé, donc je regarde les déploiements récents, les feature flags et les changements d'infrastructure des dernières heures, et si quelque chose coïncide avec le début de l'impact, je reviens en arrière ou je coupe le flag. Je n'ai pas besoin de comprendre le bug pour arrêter le mal qu'il fait. Pendant ce temps je poste une mise à jour à intervalle fixe, à peu près toutes les quinze ou vingt minutes, même quand la mise à jour c'est qu'on cherche encore, parce que le silence pousse les gens à venir demander un par un. Je note les actions avec des horodatages au fil de l'eau, en partie pour le postmortem et en partie pour que quelqu'un qui arrive puisse se mettre à jour sans interrompre.