Mises à jour de statut d'incident : un modèle et une cadence

Objectif

Tenir les utilisateurs et les parties prenantes internes informés pendant que les intervenants travaillent, sans détourner ces derniers pour répondre à des questions, et laisser une chronologie que le post-mortem pourra exploiter.

Prérequis

Des rôles nommés : l'ouvrage SRE de Google (cité) décrit un rôle de communication dont le titulaire est le visage public de la cellule de réponse à l'incident et publie des mises à jour périodiques ; le manuel pratique SRE (cité) appelle ce rôle le responsable des communications (Communications Lead), qui rend compte au commandant de l'incident (Incident Commander). Une page de statut ou un canal d'annonce, une échelle de gravité, et des modèles convenus avant l'incident.

Étapes

1. Lorsqu'un incident est déclaré, confier la communication à une personne qui n'est pas en train de déboguer. Si l'équipe compte deux personnes, le commandant communique et l'autre personne enquête.
2. Publier la première mise à jour dans un délai fixe après la déclaration, même si elle se limite à indiquer qu'un problème est en cours d'investigation. Décrire l'impact du point de vue de l'utilisateur (« les envois échouent avec une erreur depuis 9 h 40 UTC »), et non la cause supposée.
3. Utiliser un seul modèle pour chaque mise à jour : Statut (en investigation, cause identifiée, sous surveillance, résolu), Impact (qui, quoi, depuis quand), Ce que l'on sait, Ce qui est fait, Contournement s'il en existe un, Prochaine mise à jour à une heure précise avec le fuseau horaire.
4. Respecter la cadence promise. Une mise à jour qui indique « aucun changement ; prochaine mise à jour à 11 h 00 UTC » constitue une information ; une mise à jour manquée devient un second incident pour le lecteur. Le processus public de PagerDuty (cité) charge son agent de liaison interne, et non le commandant, de fournir des mises à jour de statut régulières à l'équipe de direction, environ toutes les trente minutes ; choisir une cadence par niveau de gravité et la consigner par écrit.
5. Séparer la formulation interne de la formulation externe. Les mises à jour internes peuvent nommer les systèmes, les hypothèses et les personnes ; les mises à jour externes nomment les effets visibles pour les utilisateurs et les contournements, et évitent toute spéculation sur la cause.
6. À la résolution, indiquer l'heure, si des données ont été perdues ou retardées, ce que les utilisateurs doivent faire (rien, réessayer, renvoyer), et qu'un post-mortem suivra, avec une date.
7. Conserver chaque mise à jour telle quelle ; la séquence constitue la chronologie de communication pour le post-mortem, aux côtés du document d'incident que décrit l'ouvrage SRE.

Résultat attendu

Les parties prenantes cessent de demander des nouvelles aux intervenants, car elles savent quand arrivera la prochaine mise à jour ; le post-mortem dispose d'horodatages exacts sur ce qui a été communiqué et à quel moment.

Limites et base de vérification

Les obligations de notification contractuelles ou réglementaires sortent du cadre de cet article. Les modèles ne peuvent pas décider de ce qu'il est sûr de divulguer ; cela reste un jugement propre à chaque incident. Les rôles et le chiffre de cadence proviennent des documents cités ; aucune réduction de la durée des incidents n'est avancée.