La communication d'incident

Qu'est-ce que la communication d'incident ?

La communication d'incident consiste à dire aux personnes touchées par une panne ce qui se passe, pendant que cela se passe. Elle se distingue de la réponse à incident, qui est le travail technique de détection, de confinement et de correction. La réponse rétablit le service ; la communication s'occupe de tous ceux qui attendent.

Les deux avancent en parallèle et se disputent la même attention, et c'est pourquoi la communication est généralement ce qui passe à la trappe. Une équipe plongée dans un basculement de base de données n'est pas portée à s'arrêter pour écrire une mise à jour, et c'est précisément le moment où les clients en veulent une.

Le cycle de vie d'une mise à jour

La plupart des communications d'incident suivent une séquence reconnue, et les libellés standard aident car le lecteur sait déjà ce qu'ils veulent dire :

1. Investigation - vous savez que quelque chose ne va pas et cherchez quoi.
2. Identifié - la cause est connue, un correctif est en cours.
3. Surveillance - le correctif est appliqué et vous vérifiez qu'il tient.
4. Résolu - le service fonctionne de nouveau normalement.

Chaque mise à jour s'ajoute au même incident au lieu d'être publiée comme un nouveau, afin que l'on puisse tout relire dans l'ordre ensuite.

Ce qui rend une mise à jour utile

• Décrivez l'impact en langage client. « Les connexions échouent » vaut mieux que « auth-service renvoie des 500 ».
• Dites ce que vous savez et ce que vous ignorez. « Nous ne connaissons pas encore la cause » est une mise à jour légitime, préférable au silence.
• Engagez-vous sur la prochaine mise à jour, pas sur le correctif. Vous maîtrisez quand vous republierez ; rarement quand la correction aboutira.
• Publiez tôt la première. Une mise à jour brève à dix minutes vaut mieux qu'une détaillée à quatre-vingt-dix.
• Ni accusation ni minimisation. Les deux coûtent de la confiance, en sens inverse.

Où elle est publiée

Le lieu habituel est une page de statut, hébergée séparément du service pour survivre à la panne. Les abonnements e-mail poussent les mises à jour vers les personnes concernées sans leur demander de surveiller une page, et beaucoup d'équipes reprennent le même texte sur le chat et les réseaux plutôt que d'en écrire une version par canal.

Après l'incident

Une fois résolu, l'enregistrement de l'incident reste publié. Cet historique fait partie de ce qui rend une page de statut crédible : il montre une équipe qui rapporte ses pannes au lieu de les effacer discrètement. Un postmortem suit souvent pour ce qui est significatif, mais il sert un objectif et un public différents des mises à jour écrites pendant l'événement.

LoadFocus prend en charge le cycle de vie complet des incidents avec des abonnés e-mail sur ses pages de statut, y compris les incidents créés automatiquement à partir des résultats des moniteurs.