Modèle de post-mortem d'incident

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 {intervalle de temps de l'incident, p. ex. 15 h 45 et 16 h 35} le {DATE}, {NOMBRE} utilisateurs ont rencontré {SYMPTÔMES DE L'ÉVÉNEMENT}.

L'événement a été déclenché par {CHANGEMENT} à {HEURE DU CHANGEMENT QUI A CAUSÉ L'ÉVÉNEMENT}.

{CHANGEMENT} impliquait {DESCRIPTION OU RAISON DU CHANGEMENT, tel qu'un changement au niveau du code pour mettre à jour un système}.

Un bug dans ce code a entraîné {DESCRIPTION DU PROBLÈME}.

L'événement a été détecté par {SYSTÈME DE SURVEILLANCE}. L'équipe a commencé à travailler sur l'événement en {MESURES DE RÉSOLUTION ADOPTÉES}.

Cet incident de niveau {NIVEAU DE GRAVITÉ} a affecté {X %} des utilisateurs.

Il y a eu d'autres répercussions, comme mentionné dans {p. ex. NOMBRE DE TICKETS DE SUPPORT SOUMIS, MENTIONS SUR LES RÉSEAUX SOCIAUX, APPELS AUX CHARGÉS DE COMPTE} en lien avec 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 :

À {16 h 00} le {JJ/MM/AA}, ({NOMBRE DE JOURS AVANT L'IMPACT SUR LE CLIENT, p. ex. 10 jours avant l'incident en question}), un changement a été apporté à {PRODUIT OU SERVICE} pour {CHANGEMENTS QUI ONT ENTRAÎNÉ L'INCIDENT}.

Ce changement a entraîné {DESCRIPTION DE L'IMPACT DU CHANGEMENT}.

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 :

{NOMBRE} réponses ont été envoyées par erreur pour {XX %} des demandes. Cela a duré {PÉRIODE}.

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 :

Pendant {XX h, XX minutes} entre {XX h XX UTC et XX h XX UTC} le {JJ/MM/AA}, {RÉSUMÉ DE L'INCIDENT} nos utilisateurs ont rencontré cet incident.

Cet incident a affecté {XX} clients (X % DES UTILISATEURS DE {SYSTÈME OU SERVICE}). Ils ont rencontré {DESCRIPTION DES SYMPTÔMES}.

{XX TICKETS DE SUPPORT ET XX MESSAGES SUR LES RÉSEAUX SOCIAUX} ont été envoyés.

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 l'alerte {TYPE D'ALERTE} a été déclenchée et que {ÉQUIPE/PERSONNE} a été appelée.

Ensuite, {DEUXIÈME PERSONNE} a été appelée, car {PREMIÈRE PERSONNE} ne pouvait pas écrire sur le disque, retardant la réponse de {XX MINUTES/HEURES}.

{DESCRIPTION DE L'AMÉLIORATION} sera définie par {ÉQUIPE RESPONSABLE DE L'AMÉLIORATION} pour que {AMÉLIORATION PRÉVUE}.

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é appelé à {XX h XX UTC}, {INGÉNIEUR D'ASTREINTE} était en ligne à {XX h XX UTC} dans {SYSTÈME SUR LEQUEL LES INFORMATIONS SUR L'INCIDENT SONT CAPTURÉES}.

Cet ingénieur était peu familier avec {SYSTÈME AFFECTÉ}, de sorte qu'une deuxième alerte a été envoyée à {XX h XX UTC} à {INGÉNIEUR D'ASTREINTE EN CHARGE DES REMONTÉES} qui est entré dans la pièce à {XX h 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 :

{DESCRIPTION DE L'ACTION QUI A ATTÉNUÉ LE PROBLÈME, LES RAISONS DE CETTE ACTION ET LE RÉSULTAT}

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 la gestion du pool de connexions a entraîné une fuite de connexions lors de la panne, ainsi qu'un manque de visibilité sur l'état des connexions.

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