Modèle de post-mortem d'incident

Une documentation claire est essentielle pour garantir l'efficacité d'un processus de post-mortem d'incident. De nombreuses équipes utilisent un modèle complet pour recueillir des informations cohérentes lors de chaque revue post-mortem. 

Voici un exemple de modèle de post-mortem d’incident basé sur le post-mortem décrit dans notre manuel de gestion des incidents. Vous pouvez le couper et le coller pour documenter vos propres post-mortems.

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