Qu'est-ce que 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 qu'elle a lieu : ce qui ne fonctionne pas, qui est concerné, ce que vous faites et quand elles auront des nouvelles. Elle se distingue de la réponse aux incidents, 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 l'attendent.

Les deux se déroulent en parallèle et se disputent la même attention, ce qui explique que la communication soit souvent négligée. Une équipe en plein basculement de base de données n'a pas envie de rédiger une mise à jour, et c'est pourtant à ce moment que les clients en veulent une.

Le cycle d'une mise à jour

La plupart des équipes utilisent quatre libellés standard que les lecteurs connaissent déjà :

1. Investigation (Investigating) : un problème existe, la cause est en cours de recherche.
2. Cause identifiée (Identified) : la cause est connue, la correction est en cours.
3. Surveillance (Monitoring) : le correctif est appliqué, on vérifie qu'il tient.
4. Résolu (Resolved) : le service fonctionne de nouveau normalement.

Chaque mise à jour est ajoutée au même incident au lieu d'en créer un nouveau, pour qu'on puisse relire toute l'histoire dans l'ordre.

Un exemple

Investigation, 14h05 UTC : « Certains clients ne peuvent pas se connecter. Nous enquêtons. Prochaine mise à jour avant 14h30 UTC. »
Cause identifiée, 14h22 UTC : « Un nœud de base de données défaillant provoque les erreurs de connexion. Nous basculons sur un réplica. Prochaine mise à jour avant 14h45 UTC. »
Surveillance, 14h41 UTC : « Les connexions refonctionnent. Nous surveillons les taux d'erreur. »
Résolu, 15h10 UTC : « Les taux d'erreur sont redevenus normaux. Nous publierons un postmortem. »

Ce qui rend une mise à jour utile

• Décrire l'impact avec les mots du client. « Les connexions échouent » vaut mieux que « auth-service renvoie des 500 ».
• Dire ce que vous savez et ce que vous ignorez. « Nous ne connaissons pas encore la cause » est une vraie mise à jour, meilleure que le silence.
• S'engager sur l'heure de la prochaine mise à jour, pas sur celle du correctif. Vous maîtrisez quand vous reprenez la parole, rarement quand le correctif arrive.
• Publier la première mise à jour tôt. Une courte note à dix minutes vaut mieux qu'une détaillée à quatre-vingt-dix.
• Éviter de blâmer comme de minimiser. Les deux coûtent de la confiance, dans des sens opposés.

Erreurs courantes

• Héberger la page de statut sur le système en panne. Elle doit vivre sur une infrastructure séparée pour survivre à la panne.
• Se taire quand le correctif est « presque prêt ». Gardez le rythme de mises à jour jusqu'à Résolu.
• Raconter des histoires différentes selon les canaux. Rédigez un seul texte et reprenez-le par e-mail, chat et réseaux sociaux.
• Effacer l'historique ensuite. Un historique public des incidents passés contribue à la crédibilité d'une page de statut.
• Compter sur quelqu'un qui y pense. Si une personne doit se souvenir de publier, ce sera tard. Reliez la première mise à jour à vos alertes de surveillance.

Où publier les mises à jour

Le lieu habituel est une page de statut. Les abonnements par e-mail envoient les mises à jour à ceux que cela intéresse sans qu'ils aient à surveiller la page. Les travaux planifiés suivent le même schéma avec une annonce préalable, voir la maintenance planifiée. Les engagements contractuels de disponibilité relèvent de la gestion des SLA. Un postmortem suit souvent un incident important, mais il s'adresse à un autre public et sert un autre but que les mises à jour en direct.

Ce que fait LoadFocus

Les pages de statut de LoadFocus associent des composants à vos moniteurs. D'après la page produit, avec les incidents automatiques activés, un moniteur en échec ouvre lui-même l'incident sur la page, et les abonnés sont prévenus à l'ouverture puis à la clôture. Les incidents ont une gravité (minor, major, critical) et passent par investigating, identified, monitoring et resolved, puis un postmortem peut être publié. Les abonnements e-mail utilisent la double confirmation, l'offre gratuite comprend 1 page, 10 composants et 250 abonnés, et les mises à jour peuvent aussi aller vers Slack ou un webhook. Les domaines personnalisés et les pages privées demandent une offre payante. Pour la surveillance en amont, voir la surveillance d'API ; pour aller plus loin, les bonnes pratiques de monitoring pour DevOps et développeurs.

Questions fréquentes : communication d'incident

Quelle différence avec la réponse aux incidents ?

La réponse est le travail technique pour trouver et corriger le problème. La communication tient les personnes concernées informées pendant ce travail. Les deux ont lieu en même temps et demandent généralement des personnes différentes.

À quelle fréquence publier des mises à jour pendant un incident ?

Indiquez dans chaque message l'heure de la prochaine mise à jour et tenez-la, même pour dire qu'il n'y a pas de changement. Un rythme fiable compte plus que le détail.

Que doit dire la première mise à jour ?

Que vous connaissez le problème, ce que voient les clients et quand viendra la prochaine mise à jour. Vous n'avez pas encore besoin de la cause.

Où héberger la page de statut ?

Séparément du service qu'elle décrit, pour qu'elle reste accessible même si vos propres systèmes sont en panne.

Faut-il publier un postmortem ?

Pour les incidents importants, c'est utile. Décrivez ce qui s'est passé, l'impact, la cause et ce qui change désormais. Il est rédigé après coup pour un public plus large que celui des mises à jour en direct.