Processus de post-mortem d'incident : suivre, documenter et améliorer

Points clés

• Les post-mortems d'incident aident les équipes à comprendre ce qui s'est passé, pourquoi et ce qui doit changer pour éviter que les problèmes se reproduisent.

• L'utilisation conjointe de Jira Service Management, Confluence et Jira crée un workflow connecté pour la réponse, la documentation et le suivi.

• Un modèle de post-mortem cohérent facilite la documentation, la comparaison et l'exploitation des enseignements tirés des analyses d'incidents au fil du temps.

• La transformation d'actions correctives en tickets Jira avec des propriétaires et des échéances aide les équipes à transformer les leçons apprises en améliorations concrètes. 

Lorsque quelque chose ne va pas en production, la correction n'est que le début. Ce qui compte tout autant, c'est de comprendre pourquoi cela s'est produit et de s'assurer que cela ne se reproduise pas de la même manière. 

Un post-mortem d'incident est une analyse structurée de l'incident du début à la fin, couvrant ce qui s'est produit, comment l'équipe a réagi et ce qui doit changer à l'avenir.

Grâce à un modèle de plan de réponse aux incidents qui guide le processus, votre équipe peut documenter chaque incident de manière cohérente, afin qu'aucun élément important ne soit négligé et que chaque analyse conduise à de réelles améliorations.

Fonctionnement : gestion des incidents et capture de post-mortems

Une bonne gestion des incidents ne consiste pas seulement à éteindre les incendies. Il s'agit de créer un système où chaque incident contribue à améliorer les processus, les outils et la préparation pour la prochaine fois. L'utilisation conjointe de Jira Service Management, Confluence et Jira offre à votre équipe un workflow connecté qui couvre l'ensemble du cycle de vie de la réponse aux incidents, depuis le déclenchement de l'alerte jusqu'à l'analyse post-mortem et aux interventions de suivi. 

Cette approche assure une documentation cohérente entre les incidents et établit une chaîne de responsabilité claire. Au lieu d'être éparpillés dans des messages Slack, des e-mails et la mémoire de chacun, les détails des incidents sont désormais centralisés dans un écosystème unique et connecté où ils peuvent être consultés, référencés et utilisés pour agir. Cette cohérence signifie également que votre modèle de plan de réponse aux incidents reste au cœur du processus plutôt que d'être quelque chose que l'équipe remplit quand elle en a le temps. 

Voici comment le processus se décompose à chaque étape :

Gérer l'incident dans Jira Service Management

Jira Service Management est l'endroit où votre réponse aux incidents commence. Dès qu'un ticket arrive, consignez-le dans JSM, définissez le niveau de gravité et assignez les intervenants appropriés. 

Pendant l'incident, les équipes peuvent utiliser JSM pour :

• Suivre les actions, décisions et remontées en temps réel

• Conserver un enregistrement clair des personnes impliquées et des modifications apportées

• Consigner les détails qui serviront ultérieurement au post-mortem

• Tenir la direction informée sans gêner le travail des intervenants

Étant donné que JSM s'intègre à Confluence et Jira, les données recueillies pendant l'incident peuvent être transmises directement dans la documentation post-mortem et les tickets de suivi. Pour les équipes qui utilisent JSM dans le cadre d'une configuration plus large du logiciel ITSM, les données d'incident s'intègrent également dans le tableau global de la gestion des services.

JSM soutient également une communication efficace sur les incidents tout au long de la réponse en aidant les équipes à :

• Tenir les clients, les équipes d'assistance et les parties prenantes informés

• Réduire la confusion pendant les incidents en cours

• Offrir une visibilité sur l'état et l'impact

• Communiquer plus clairement lors d'événements graves ou de scénarios de gestion de crise

Au moment où l'incident est résolu, l'équipe dispose déjà d'un enregistrement détaillé de son déroulement, ce qui facilite la documentation du post-mortem et le rend plus utile pour les améliorations futures.

Capturer le post-mortem dans Confluence

Une fois l'incident résolu, consignez-le par écrit tant que les détails sont encore frais dans votre mémoire, de préférence dans les 24 à 48 heures. Plus vous attendez, plus le contexte s'estompe et moins le post-mortem devient utile. 

Créez une page Confluence dédiée en utilisant un modèle de post-mortem d'incident et parcourez chaque section : chronologie, analyse de cause racine, évaluation d'impact et leçons apprises. Le modèle de réponse aux incidents inclus sur cette page fournit un framework complet que votre équipe peut copier et remplir pour chaque nouvel incident, vous évitant ainsi de devoir déterminer à chaque fois ce qu'il faut documenter.

Conserver les post-mortems dans Confluence offre plusieurs avantages pratiques :

• Visibilité à l'échelle de l'équipe : n'importe qui, du service ingénierie à la direction, peut consulter le déroulement des faits sans avoir à solliciter l'intervenant d'astreinte pour un récapitulatif oral.

• Identification de modèles : lorsque chaque incident est documenté dans le même format, il devient beaucoup plus facile de repérer les défaillances récurrentes et les faiblesses systémiques d'un trimestre à l'autre.

• Documentation impartiale : un modèle structuré de réponse aux incidents maintient la conversation centrée sur les systèmes et les processus plutôt que de pointer du doigt, ce qui conduit à des rapports plus honnêtes et utiles.

• Intégration plus rapide pour les nouvelles recrues : les nouveaux membres de l’équipe peuvent consulter les rapports d’incidents précédents pour comprendre comment vos systèmes se comportent sous pression et ce que l’équipe a déjà appris des incidents précédents.

Pour un guide plus approfondi sur la conduite de post-mortems productifs, consultez notre manuel sur les post-mortems d'incident.

Suivre les actions de suivi en tant que tickets Jira

Un post-mortem n'est utile que dans la mesure où il génère des actions. Chaque action corrective et ticket récurrent identifié lors de la révision doit être converti en ticket Jira avec un propriétaire clairement défini et une échéance. 

C'est l'étape qui distingue les équipes qui s'améliorent réellement de celles qui continuent de rencontrer les mêmes problèmes. Lorsque les actions correctives existent sous forme de tickets traçables dans Jira, les responsables peuvent surveiller l'avancement et les équipes peuvent se tenir mutuellement responsables de la réalisation des améliorations convenues. Cela aide également à établir les priorités. Lorsque les tickets liés aux incidents sont intégrés au reste de votre backlog, il est plus facile de les comparer aux autres priorités plutôt que de les laisser discrètement glisser au bas de la liste.

Les bons outils de gestion des incidents connectent l'ensemble de ce workflow de bout en bout. Lorsque vos systèmes de réponse, de documentation et de suivi sont intégrés, l'écart entre la détection d'un problème et la prévention de sa récurrence se réduit considérablement.

Modèle de réponse aux incidents

Vous trouverez ci-dessous un modèle de plan de réponse aux incidents que votre équipe peut copier et adapter pour chaque nouvel incident. Il passe en revue chaque phase d'un post-mortem, du résumé initial et de la chronologie jusqu'à l'analyse de la cause racine, aux leçons apprises et aux actions correctives. L'utilisation d'une structure cohérente pour chaque incident garantit qu'aucun élément n'est négligé et que vos post-mortems sont faciles à comparer dans le temps.

Les exemples du modèle constituent un point de départ, pas un script rigide. Ajustez la langue et le niveau de détail pour qu'ils correspondent au mode de fonctionnement de votre organisation. L'objectif est de documenter suffisamment de contexte pour que toute personne lisant le post-mortem des mois plus tard puisse comprendre exactement ce qui s'est passé et ce que l'équipe a fait pour y remédier.

Résumé de l'incident

Rédigez un résumé de l'incident en quelques phrases. Décrivez ce qui s'est passé et pourquoi, la gravité de l'incident et la durée de son impact.

Exemple :

Entre {time range of incident, e.g. 15:45 and 16:35} le {DATE}, {NUMBER} utilisateurs ont rencontré {EVENT SYMPTOMS}. 

L’événement a été déclenché par un {CHANGE} à {TIME OF CHANGE THAT CAUSED THE EVENT}. 

Le {CHANGE} contenait {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}. 

Un bug dans ce code a entraîné {DESCRIPTION OF THE PROBLEM}. 

L’événement a été détecté par {MONITORING SYSTEM}. L’équipe a commencé à travailler sur l’événement en {RESOLUTION ACTIONS TAKEN}.

Cet incident {SEVERITY LEVEL} a touché {X%} des utilisateurs.

Il y a eu d’autres répercussions, comme indiqué par {e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS} soulevées à propos de cet incident. 

Prémices

Décrivez la séquence des événements qui ont entraîné l'incident, notamment les changements précédents qui ont introduit des bugs qui n'avaient pas encore été détectés.

Exemple :

Le {MM/DD/YY} à {16:00}, ({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}), un changement a été apporté à {PRODUCT OR SERVICE} afin de {THE CHANGES THAT LED TO THE INCIDENT}. 

Ce changement a entraîné {DESCRIPTION OF THE IMPACT OF THE CHANGE}.

Panne

Expliquez pourquoi le changement apporté n'a pas fonctionné comme prévu. Si possible, joignez des captures d'écran des visualisations de données pertinentes qui illustrent l'erreur.

Exemple :

{NUMBER} réponses ont été envoyées par erreur pour {XX%} des demandes. Cela a duré {TIME PERIOD}.

Impact

Décrivez comment les utilisateurs internes et externes ont été affectés au cours de l'incident. Incluez le nombre de dossiers de support créés.

Exemple :

Entre {XXhrs XX minutes} et {XX:XX UTC and XX:XX UTC} le {MM/DD/YY}, nos utilisateurs ont été concernés par cet incident : {SUMMARY OF INCIDENT}.

Cet incident a affecté {XX} clients (X % DES {SYSTEM OR SERVICE} UTILISATEURS), qui ont rencontré {DESCRIPTION OF SYMPTOMS}.

{XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS} ont été soumis.

Détection

Quand l'équipe a-t-elle détecté l'incident ? Comment a-t-elle pris conscience de sa survenue ? Comment améliorer le temps de détection ? Posez la question suivante : comment aurions-nous pu réduire ce temps de moitié ?

Exemple :

L’incident a été détecté lorsque {ALERT TYPE} a été déclenché et {TEAM/PERSON} ont été alertés. 

Ils ont ensuite dû alerter {SECONDARY PERSON}, car {FIRST PERSON} n’étaient pas responsables du service écrivant sur le disque, ce qui a retardé la réponse de {XX MINUTES/HOURS}.

{DESCRIBE THE IMPROVEMENT} sera configuré par {TEAM OWNER OF THE IMPROVEMENT} de sorte que {EXPECTED IMPROVEMENT}.

Réponse

Qui a répondu à l'incident ? Quand la réponse a-t-elle eu lieu et en quoi consistait-elle ? Notez tout retard ou obstacle à la réponse.

Exemple :

Après avoir été alerté à {XX:XX UTC}, {ON-CALL ENGINEER} s’est connecté à {XX:XX UTC} dans {SYSTEM WHERE INCIDENT INFO IS CAPTURED}. 

Cet ingénieur était peu familier avec {AFFECTED SYSTEM}, de sorte qu’une deuxième alerte a été envoyée à {XX:XX UTC} à {ESCALATIONS ON-CALL ENGINEER} qui est entré dans la pièce à {XX:XX UTC}.

Récupération

Décrivez comment le service a été rétabli et pourquoi l'incident a été jugé terminé. Expliquez comment vous avez réussi à rétablir le service et comment vous connaissiez les mesures à prendre pour garantir la récupération. 

Selon le scénario, posez-vous les questions suivantes : comment améliorer le temps d'atténuation ? Comment auriez-vous pu réduire ce temps de moitié ?

Exemple :

Nous avons adopté une approche à trois volets pour la récupération du système : 

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME} 

Exemple : augmentation de la taille de l'ASG BuildEng EC3 afin d'augmenter le nombre de nœuds disponibles pour assumer la charge de travail et réduire la probabilité de planification sur des nœuds sursouscrits.

• Désactivation de la mise à l'échelle automatique d'Escalator pour empêcher toute réduction agressive du cluster.

• Retour à la version précédente du planificateur Build Engineering.

Chronologie

Détaillez la chronologie de l'incident. Nous vous recommandons d'utiliser UTC pour normaliser les fuseaux horaires.

Indiquez tous les événements antérieurs, tout début d'activité, le premier impact connu et les remontées. Notez les décisions prises ou les changements apportés, la date à laquelle l'incident a pris fin, ainsi que tout événement survenu après l'impact. 

Exemple :

Toutes les heures correspondent au fuseau UTC.

11 h 48 - Mise à niveau K8S 1.9 du plan de contrôle terminée 

12 h 46 - Fin de la mise à niveau vers la V1.9, y compris la mise à l'échelle automatique du cluster et l'instance du planificateur BuildEng 

14 h 20 - Build Engineering signale un problème au KITT Disturbed

14 h 27 - KITT Disturbed commence à enquêter sur les pannes d'une instance EC2 spécifique (ip-203-153-8-204) 

14 h 42 - KITT Disturbed isole le nœud spécifique 

14 h 49 - BuildEng signale que le problème affecte plusieurs nœuds. 86 instances du problème montrent que les pannes sont plus systémiques 

15 h 00 - KITT Disturbed suggère de passer au planificateur standard 

15 h 34 - BuildEng signale la panne de 200 pods 

16 h 00 - BuildEng arrête tous les builds défaillants avec des rapports OutOfCpu 

16 h 13 - BuildEng signale que les pannes sont récurrentes avec les nouvelles versions et ne sont pas seulement transitoires. 

16 h 30 - KITT reconnaît les pannes comme un incident et les gère en tant que tel. 

16 h 36 - KITT désactive la mise à l'échelle automatique d'Escalator pour l'empêcher de retirer de la capacité de calcul afin de résoudre le problème.

16 h 40 - KITT confirme qu'ASG est stable, que la charge du cluster est normale et que l'impact sur le client est résolu.

MODÈLE :

XX h XX UTC : ACTIVITÉ D'INCIDENT ; ACTION MENÉE

XX h XX UTC : ACTIVITÉ D'INCIDENT ; ACTION MENÉE

XX h XX UTC : ACTIVITÉ D'INCIDENT ; ACTION MENÉE

Identification de la cause profonde : les « Cinq pourquoi »

Les « Cinq pourquoi » constituent une technique d'identification de la cause profonde. Voici comment l'appliquer :

• Commencez par décrire l'impact et demandez-vous pourquoi il s'est produit. 

• Notez l'impact de l'incident.  

• Demandez-vous pourquoi l'incident s'est produit et pourquoi il a eu l'impact qui en a résulté. 

• Ensuite, continuez à vous demander « pourquoi » jusqu'à trouver une cause profonde.

Consignez les « pourquoi » dans votre documentation post-mortem.

Exemple :

1. L'app a subi une panne parce que la base de données a été verrouillée

2. La base de données s'est verrouillée en raison d'un trop grand nombre d'écritures

3. Parce que nous avons pushé un changement vers le service et ne nous attendions pas au nombre élevé d'écritures

4. Parce que nous ne disposons pas d'un processus de développement établi pour les changements de test de charge

5. Parce que nous n'avons jamais pensé que les tests de charge étaient nécessaires jusqu'à ce que nous ayons atteint ce niveau d'évolutivité.

Cause profonde

Notez la cause profonde définitive de l'incident, l'élément identifié à modifier afin d'éviter que cette catégorie d'incident ne se reproduise.

Exemple :

Un bug dans

Vérification du backlog

Examinez votre backlog d'ingénierie pour savoir si des tâches imprévues auraient pu prévenir cet incident, ou du moins en réduire l'impact ? 

Une évaluation claire du backlog aide à clarifier les décisions passées en matière de priorité et de risque.

Exemple :

Aucun élément spécifique du backlog qui aurait pu améliorer ce service. Une note concerne les améliorations apportées au typage des flux. Il s'agissait de tâches en cours comportant des workflows.  

Des tickets ont été soumis pour améliorer les tests d'intégration, mais sans succès pour l'instant.

Récurrence

Maintenant que vous connaissez la cause profonde, pouvez-vous réfléchir pour déterminer si d'autres incidents pourraient avoir la même cause profonde ? Si oui, notez les mesures d'atténuation qui ont été prises suite à ces incidents et demandez-vous pourquoi l'incident s'est de nouveau produit.

Exemple :

La même cause profonde a provoqué les incidents HOT-13432, HOT-14932 et HOT-19452.

Enseignements

Discutez de ce qui s'est bien passé lors de la réponse aux incidents, de ce qui aurait pu être amélioré et des possibilités d'amélioration.

Exemple :

• Besoin d'un test unitaire pour vérifier que le limiteur de vitesse pour le travail a été correctement entretenu

• Les charges de travail en vrac atypiques par rapport au fonctionnement normal doivent être examinées

• Les opérations en bloc devraient démarrer lentement et être surveillées, augmentant lorsque les indicateurs de service semblent faibles

Actions correctives

Décrivez les actions correctives ordonnées pour prévenir cette catégorie d'incident à l'avenir. Notez qui est responsable, quand il doit terminer le travail et à quel niveau ce dernier fait l'objet d'un suivi.

Exemple :

1. Limite de taux de mise à l'échelle automatique manuelle mise en place temporairement pour limiter les défaillances

2. Test unitaire et réintroduction de la limitation du taux d'emploi

3. Introduction d'un mécanisme secondaire pour collecter des informations sur les taux distribués à travers le cluster afin de guider les effets de mise à l'échelle