Close

Gestion des incidents pour les équipes haute vélocité

En quoi un processus de post-mortem d'incident est-il important ?

Les incidents, ça arrive.

C'est un fait. Au fur et à mesure que nos systèmes gagnent en taille et en complexité, les échecs sont inévitables.

Les incidents sont également une opportunité d'apprentissage.

Ils sont l'occasion de détecter les vulnérabilités dans notre système. Une opportunité d'atténuer les incidents répétés et d'accélérer la résolution. Un moment pour rassembler vos équipes et planifier la manière dont elles pourront être encore meilleures la prochaine fois.

Le meilleur moyen de travailler sur ce qui s'est passé durant un incident et de consigner des leçons apprises consiste à organiser un post-mortem d'incident, aussi appelé revue post-incident.

Un post-mortem d'incident rassemble les personnes pour évoquer les détails d'un incident : pourquoi il s'est produit, son impact, quelles actions ont été entreprises pour l'atténuer et le résoudre, et les actions à entreprendre pour éviter qu'un tel incident ne se reproduise.

Grâce à des outils comme le contrôle de version, les feature flags (indicateurs de fonctionnalités), et la livraison continue, beaucoup d'incidents peuvent être rapidement « éliminés ». De nombreux incidents sont causés par un bug dans un changement envoyé en production, et l'annulation de ce changement peut rendre l'app de nouveau opérationnelle. C'est vraiment bénéfique pour tout le monde, cela permet de restaurer le service rapidement. Mais souvent, cela ne vous aide pas à comprendre ce qui a échoué ni quelles en sont les raisons. C'est là que les post-mortems entrent en scène.

Un post-mortem d'incident est un framework permettant de tirer des enseignements des incidents et de partir des problèmes pour avancer. Il permet également de renforcer la confiance des clients, des collègues et des utilisateurs finaux (essentiellement les personnes touchées par l'incident) et de les prévenir que votre équipe travaille à minimiser les incidents et l'impact futurs.

Illustration d'un cycle de post-mortem

Un post-mortem est une étape importante dans le cycle de vie d'un service disponible en continu. Les résultats de votre post-mortem devraient être directement intégrés à votre processus de planification. Vous pourrez ainsi vous assurer que les tâches de remédiation essentielles identifiées dans le post-mortem trouvent une place dans le travail à venir et sont équilibrées par rapport aux autres tâches et priorités à venir.

Avantages d'un post-mortem d'incident

Vous pourriez être tenté d'ignorer une réunion formelle de post-mortem d'incident et sa rédaction, surtout si vous êtes certain des causes de l'incident, et que vous êtes presque sûr d'avoir résolu le ticket.

C'est peut-être vrai, pour vous. Mais certains membres de votre équipe peuvent ne pas avoir assimilé ce qui a mené à l'incident et pourraient alors bénéficier de votre parfaite compréhension de la situation afin d'améliorer leur service à l'équipe, et à vos clients.

En rassemblant les personnes afin d'entamer un processus structuré et collaboratif, chacun pourra faire profiter aux autres des leçons qu'il a tirées, et vous pourrez développer la confiance et la résilience au sein de votre équipe. De plus, consigner l'incident et la manière dont l'équipe l'a résolu peut influencer la gestion future des incidents.

Vous pourriez également décider de partager des points clés de votre post-mortem d'incident avec vos clients ou le reste de votre organisation. Cela pourrait contribuer à redonner confiance à des personnes qui n'étaient pas forcément impliquées de près dans l'incident. D'autres équipes de votre organisation, en particulier la direction, peuvent avoir besoin de voir les détails du problème et les mesures prises pour le résoudre afin d'éviter toute remise en question de votre équipe à l'avenir.

Les partenaires, les clients et les utilisateurs finaux peuvent également vouloir savoir ce qui s'est passé et quelles mesures vous avez prises pour améliorer leur expérience. La mise en ligne de votre post-mortem d'incident sur votre site web public n'est pas toujours appropriée. Cependant, vos équipes marketing ou relations publiques peuvent vous aider à tourner vos phrases. Ainsi, les personnes obtiennent les informations de manière informative et la confiance dans vos services est renforcée.

Bonnes pratiques pour un post-mortem d'incident

Votre approche du post-mortem d'incident est tout aussi importante que la checklist des mesures que vous prenez. Les tensions peuvent être vives à la suite d'un incident. La clé pour amener les personnes à s'engager dans le processus et à être prêtes à aborder un problème difficile ? Vous devez leur donner un sentiment de sécurité psychologique.

Mettez en place une culture sans reproches

L'ancien DSI d'Etsy, John Allspaw, a rédigé un billet de blog phare sur les « post-mortem sans reproches ». Cette approche de l'enquête sur les incidents permet aux personnes impliquées de tenir compte de toutes leurs actions, de leur impact, de ce qu'elles savaient et du moment où elles l'ont fait, sans crainte de punition ou de représailles.

Cette approche est un atout majeur pour vous assurer que vos équipes partagent ouvertement les informations et identifient la cause profonde d'un incident. Si une personne craint les reproches, elle peut retenir des informations ou essayer de blâmer d'autres personnes. Lorsque cela se produit, les personnes n'ont plus confiance les unes en les autres. Et l'organisation perd la possibilité de renforcer la résilience au sein de ses équipes et de ses systèmes. De nombreuses équipes, y compris chez Atlassian et Google, ont adopté les principes du post-mortem sans reproches afin d'éviter ces pièges.

Évitez de pointer du doigt, faites des critiques constructives

Lors de votre réunion de post-mortem, ainsi que lors de la rédaction des résultats, évitez les termes qui désignent des personnes comme étant personnellement responsables de l'incident. Concentrez-vous plutôt sur les actions, les résultats et l'impact.

Bien qu'il soit important de maintenir la conversation sécurisée et objective, déterminer la cause première de l'incident est essentiel à sa résolution. Lors de votre réunion, vous pouvez utiliser une technique appelée « les « Cinq pourquoi ». Commencez par vous assurer que tout le monde est d'accord sur le problème. Demandez ensuite pourquoi cela s'est produit, puis demandez « pourquoi ? » à la réponse à cette question. Répétez cette opération au moins cinq fois pour vous assurer de découvrir tous les facteurs profonds qui contribuent au problème. Assurez-vous que les personnes présentes n'essaient pas d'éviter une vérité inconfortable ou de parvenir à un consensus facile. Vous pouvez en apprendre plus sur l'approche des « Cinq pourquoi » grâce à notre scénario du playbook.

Passez en revue tous les post-mortems, et intégrez-les à votre processus

Un rapport de post-mortem d'incident non révisé pourrait tout aussi bien ne jamais avoir été écrit. Une fois le rapport de post-mortem d'incident ébauché, il est important de le réexaminer pour traiter tout problème non résolu, consigner des idées à envisager dans le futur et finaliser le rapport. Vous pouvez même dire que l'incident n'est pas réellement résolu tant qu'il n'a pas été passé en revue.

Comment y parvenir ? Planifiez une réunion récurrente avec l'équipe d'ingénierie (et toute autre personne qui pourrait y avoir un intérêt, comme le support client ou les chargés de compte), au moins tous les mois, pour passer en revue les rapports de post-mortem d'incidents. Vous pouvez décider de passer en revue des rapports récents ou plus anciens et de partager les leçons qui sont encore pertinentes aujourd'hui.

Plan de post-mortem d'incident efficace

Pour que les post-mortems soient efficaces et vous permettent de développer une culture d'amélioration continue, vous devez mettre en place un processus simple et reproductible auquel tout le monde peut participer. La manière d'y parvenir dépend de votre culture et de votre équipe. Chez Atlassian, nous avons développé une méthode qui fonctionne pour nous, et vous pouvez en apprendre plus à ce propos dans notre manuel de gestion des incidents.

Voici quelques conseils pour vous lancer :

Conseil n° 1 : Définissez un seuil

Dans votre organisation, les incidents doivent avoir des niveaux de gravité clairs et mesurables. Ces niveaux peuvent être utilisés pour déclencher le processus de post-mortem. Par exemple, tout incident dont la gravité est de 1 ou plus déclenche le processus de post-mortem, alors que ce dernier peut être optionnel pour les incidents moins graves. Envisagez de donner aux responsables d'équipe ou à la direction la possibilité de demander une analyse post-mortem pour tout incident qui n'atteint pas le seuil.

Conseil n° 2 : Ne procrastinez pas

Il est important de faire une pause et de se reposer après un incident. Mais ne tardez pas à rédiger le post-mortem d'incident. Si vous attendez trop longtemps, vous pourriez perdre ou oublier des informations importantes. Idéalement, il est rédigé immédiatement après une réunion de revue post-incident qui doit se tenir dans les 24 à 48 heures suivant la résolution de l'incident, et pas plus de cinq jours ouvrés après.

Conseil n° 3 : Assignez des rôles et des propriétaires

Une réunion de revue post-incident est le moment où vous allez discuter des informations qui seront consignées dans le post-mortem d'incident. Il est recommandé de déléguer la rédaction du post-mortem à une personne spécifique, idéalement à une personne qui connaît l'incident, et qui dispose du niveau de connaissances techniques et organisationnelles requis pour comprendre les causes et atténuations.

Conseil n° 4 : Travaillez à partir d'un modèle

Un modèle peut vous permettre d'éviter d'oublier des informations clés. C'est également un bon moyen de développer de la cohérence tout au long de vos post-mortems.

Conseil n° 5 : Ajoutez une chronologie

Une chronologie est une aide très utile dans la documentation des incidents. C'est souvent la première chose que vos lecteurs consulteront lorsqu'ils essaieront d'évaluer ce qui s'est passé. Essayez d'être aussi clair et spécifique que possible. Préférez « 11 h 14 PST » à « autour de 11 h ». La précision de l'horodatage vous permet de cartographier une chaîne d'événements haute fidélité, ce qui est utile pour identifier des domaines d'amélioration. Par exemple, vous pourriez identifier que l'intervalle entre le début de l'impact et la notification aux clients était trop long.

Heures importantes à inclure :

  • Première alerte ou premier ticket
  • Premières annonces communes (internes et/ou externes)
  • Heure de mise à jour de la page d'état
  • Heure des tentatives de remédiation (restaurations du code, etc)
  • Heure de résolution

Conseil n° 6 : Ne lésinez pas sur les détails

En lésinant sur les détails, vous risquez de rédiger des post-mortems peu utiles et peu clairs. Ajoutez autant de détails que possible sur ce qui s'est passé et ce qui a été fait durant l'incident. À la place de « puis communications publiques lancées », écrivez « Nous avons envoyé les premières communications publiques annonçant l'incident sur notre page d'état publique et sur notre compte Twitter ».

Dès que possible, ajoutez des liens et des noms, des liens vers les tickets et les mises à jour d'état, des liens vers les documents d'état de l'incident et les graphiques de surveillance. N'hésitez pas également à ajouter des captures d'écran de graphiques ou tableaux de bord pertinents. Un graphique provenant de votre système de surveillance qui montre clairement les heures de début et de fin de l'incident (par exemple, une baisse du taux de demandes suivi d'un retour à la normale) est très utile, car il est sans ambiguïté. Il devient encore plus puissant lorsqu'il est combiné à des graphiques qui montrent l'envers du décor à cet instant précis, par exemple, les connexions à la base de données, l'état des liaisons réseau ou la consommation du processeur, de la mémoire, des entrées/sorties et de la bande passante sur la même période.

Conseil n° 7 : Capturez les métriques d'incident

Lorsque vous capturez des métriques dans votre post-mortem d'incident, vous appliquez des données concrètes aux tickets et à leur impact. Disposer de ces points de données vous permet de déterminer si votre équipe est sur la bonne voie et de réduire le nombre d'incidents, leur gravité, ainsi que les temps d'arrêt. Grâce à des métriques cohérentes mesurées, vous pouvez prendre du recul et observer les tendances d'incident au fil du temps.

Quelques métriques à prendre en compte dans votre suivi de post-mortem d'incident :

  • Le nombre de minutes de temps d'arrêt, afin de pouvoir suivre si ce nombre est croissant ou décroissant
  • La gravité de l'incident, afin de pouvoir déterminer la fiabilité relative de vos systèmes
  • La durée moyenne de résolution (MTTR), qui mesure le temps moyen nécessaire pour résoudre un incident, à partir du moment où il a été initialement signalé

Le conseil le plus important ? Ne sautez pas d'étape. Pour mener un post-mortem d'incident qui vous permet d'améliorer votre équipe et vos systèmes, vous devez disposer d'un processus et vous y tenir.

Utilisez un modèle de post-mortem d'incident pour simplifier le processus

Afin d'assurer que votre équipe développe une culture autour des revues de post-mortem d'incident, facilitez la capture des informations, planifiez des réunions et publiez le rapport final grâce à des checklists réutilisables et des modèles. Un processus reproductible offre de la cohérence et aide les personnes à savoir ce à quoi elles doivent s'attendre, puis à intégrer le processus dans un état d'esprit productif.

Éléments typiques pour un post-mortem d'incident :

Les réunions qui doivent être effectuées :

  • Réunion de collecte d'informations
  • Révision du rapport
  • Présentation du rapport

Les informations qui doivent être collectées à l'avance :

  • Programme standard à chaque réunion
  • Participants, parties prenantes, réviseurs
  • Rédaction du rapport de post-mortem d'incident standardisé grâce à un modèle
Suivant
Template