Guide de documentation post-mortem

Si les incidents et les pannes sont une réalité dans le monde de la technologie, ils offrent également de précieuses opportunités de croissance et d'amélioration, tout en restant un problème coûteux. Selon des données récentes, les incidents ayant un impact sur les clients ont augmenté de 43 % au cours de la dernière année. coûtant près de 800 000 $ Bien que ces moments puissent être difficiles tant pour les clients que pour les équipes, les actions entreprises pendant et après un incident peuvent faire toute la différence pour renforcer les systèmes et prévenir les problèmes futurs.

C’est là qu’une analyse post-mortem bien conçue devient un outil essentiel. Il est cependant crucial de prendre le temps, par la suite, d’analyser ce qui s’est passé, la solution apportée et la manière d’aller de l’avant. Dans cette ressource, nous détaillerons le processus de création d’une analyse post-mortem efficace afin d’aider les équipes à améliorer la gestion des incidents, à tirer des enseignements, à s’adapter et à progresser en continu.

Qu'est-ce qu'une autopsie ?

Une autopsie est un processus structuré qui suit un incident. Parfois appelée incident post-mortem ou analyse post-incident, elle comprend un examen détaillé de ce qui s'est passé, pourquoi cela s'est produit, comment cela a été résolu et ce qu'il faut faire pour éviter que des incidents similaires ne se reproduisent.

Les analyses post-mortem permettent aux équipes de comprendre ce qui fonctionne bien, ce qui pourrait être amélioré et comment éviter de reproduire les mêmes erreurs. Une analyse post-mortem approfondie, accompagnée d'une documentation détaillée, aide les équipes à tirer des leçons de leurs erreurs et à améliorer leurs systèmes et processus.

Les analyses post-incident sont essentielles après un incident et aident les membres de l'équipe à réfléchir et à identifier les pistes d'amélioration.

Questions post-mortem du projet

Les analyses post-mortem ne sont pas seulement bénéfiques après un incident ; elles peuvent également constituer de précieux outils d'apprentissage après la réalisation d'un projet. Ce type d'analyse post-mortem donne aux équipes de projet l'occasion d'évaluer ce qui a bien fonctionné et ce qui peut être amélioré.

Voici quelques questions à se poser lors d'une analyse post-mortem d'un projet :

• Quels étaient les objectifs du projet ? Ces objectifs ont-ils été atteints ?
• Quels ont été les succès/les réussites du projet ?
• L'équipe a-t-elle bien collaboré ? Y a-t-il eu des obstacles (par exemple, des problèmes de communication, de délais, etc.) ?
• Les exigences étaient-elles clairement définies pour les membres de l'équipe ?
• L'équipe estimait-elle disposer des ressources suffisantes pour mener à bien le projet ?
• Quels problèmes l'équipe a-t-elle rencontrés ?
• Le projet a-t-il respecté le budget et le calendrier ?
• Quels ont été les principaux enseignements tirés de ce projet ? Comment ces enseignements peuvent-ils être appliqués à des projets futurs ?
• Quelles lacunes en matière de compétences, mises en évidence par ce projet, doivent être comblées ?

Comment rédiger un rapport post-mortem

La rédaction d'un rapport d'autopsie est essentielle pour documenter les incidents, identifier les facteurs contributifs et mettre en place des actions visant à prévenir leur récurrence et à apporter un soutien. amélioration continue .

Le rapport d'incident doit être détaillé et inclure un résumé de l'incident, sa chronologie, ses causes profondes, son impact et les actions à entreprendre afin d'aider les équipes à déterminer la cause de l'incident et les mesures à prendre pour éviter qu'il ne se reproduise. Vous trouverez ci-dessous les sections et informations essentielles à inclure dans un rapport d'incident.

Aperçu

Décrivez brièvement ce qui s'est passé. Précisez les équipes impliquées (par exemple, IT, DevOps, Support) et présentez les principales étapes de l'incident (par exemple, détection, confinement, résolution). Incluez un bref aperçu de l'impact de l'incident sur l'activité et les utilisateurs afin d'aider les parties prenantes à en comprendre rapidement la portée. Cette section doit inclure un résumé de l'incident, précisant ses causes profondes, sa chronologie et son impact.

Ce qui s'est passé?

Veuillez fournir une brève description du déroulement de l'incident.

Inclure des détails sur :

• Quelles parties de l'infrastructure ont été touchées, et détaillez les services ou fonctions spécifiques qui ont été perturbés.
• Signalez tout impact sur l'utilisateur, comme des ralentissements, des problèmes d'accès ou l'indisponibilité de fonctionnalités, afin de clarifier comment les utilisateurs ont été affectés.
• Qui a participé à l'intervention ?
• Comment l'incident a-t-il été résolu ?

causes profondes

Dans cette section, veuillez énumérer toutes les conditions qui ont pu contribuer à l'incident/au problème.

• Décrivez tous les facteurs ayant pu contribuer à l'incident, tels que des modifications récentes du code, la charge du système ou des erreurs de configuration.
• Veuillez indiquer si l'équipe a tenté des solutions provisoires ou a escaladé le problème en interne avant que la cause profonde ne soit découverte.

N'oubliez pas de préciser si des actions ont aggravé la situation. Remplir cette section permettra aux membres de l'équipe de tirer des leçons des erreurs qui ont provoqué l'incident.

Résolution

Comment le problème a-t-il été résolu ? Quelles mesures ont été prises ?

Documentez séparément les solutions temporaires et la solution définitive. Incluez les solutions de contournement ou les interventions manuelles mises en œuvre lors de la résolution du problème. Fournissez un lien vers les manuels, guides ou procédures spécifiques afin que les intervenants puissent s'y référer en cas de récidive.

Impact

Quelles ont été les conséquences de cet incident ? Soyez très précis dans cette section et incluez tous les chiffres et autres détails.

Cette section devrait inclure :

• Chronologie: Décrivez les principales étapes, de la découverte à la résolution, en précisant la durée de chaque phase.
• Découverte des problèmes : Décrivez quand et comment le problème a été détecté pour la première fois, en précisant comment il a été découvert (par exemple, surveillance interne, signalements clients ou alertes automatisées).
• Gravité: Attribuez un niveau de gravité à l'incident, en détaillant les raisons de cette catégorisation et les critères spécifiques utilisés dans l'évaluation.
• Impact sur le client : Documentez le nombre de clients affectés et la durée de l'impact. Précisez le type d'impact subi (par exemple, interruptions de service, ralentissement des performances) et les éventuelles variations selon les segments d'utilisateurs.
• Impact sur les équipes internes et les partenaires : Décrivez l'impact de l'incident sur les équipes internes et les partenaires, en mentionnant tout retard, réaffectation de ressources ou surcharge de travail.
• Analyse d'impact finale : (Indicateurs clés de performance techniques et commerciaux) : Utilisez des indicateurs clés de performance pour quantifier l’impact technique et commercial. Par exemple, il peut s’agir de mesures de disponibilité, de non-respect des accords de niveau de service (SLA), de pertes de revenus ou du taux de désabonnement des utilisateurs.
• Résolution: Résumez les étapes suivies pour résoudre le problème, y compris les solutions provisoires et la solution finale basée sur l'analyse des causes profondes. Fournissez un lien vers la documentation technique détaillée, le cas échéant.
• Impacts futurs potentiels : Évaluer la probabilité que des incidents similaires se reproduisent à l'avenir et discuter des éventuelles conséquences à long terme pour le système ou l'entreprise.
• Leçons tirées et pistes d'amélioration continue : Analysez les enseignements tirés de cet incident et identifiez les axes d'amélioration précis concernant les processus, les outils ou la dynamique d'équipe. Notez les mesures de suivi à prendre pour éviter qu'il ne se reproduise.

Utilisez des indicateurs d'opportunité pertinents pour les équipes techniques et les parties prenantes commerciales afin de quantifier l'impact de l'incident. Il peut s'agir d'indicateurs tels que la soumission d'événements ou le délai de traitement.

Indicateurs supplémentaires à inclure :

• Délai de détection (TTD) : Permet aux équipes de comprendre la rapidité avec laquelle les systèmes de surveillance et d'alerte ont signalé l'incident.
• Délai de réponse (TTR) : Mesure la réactivité dans l'investigation et l'allocation des ressources.
• Délai de résolution (TTR) : L'équipe a-t-elle fait preuve d'une grande efficacité pour réagir et résoudre les problèmes ?
• Disponibilité/temps de fonctionnement du système : La durée pendant laquelle un système est opérationnel, indiquant sa fiabilité.

Chronologie

La chronologie doit documenter comment et quand l'incident s'est produit. Elle doit se limiter aux faits et ne pas s'attacher à évaluer ou analyser ce qui s'est passé.

Conseils pour créer la chronologie :

1. Commencez la chronologie avant l'incident et progressez jusqu'à sa résolution.
2. Consultez le journal des incidents sur Slack ou tout autre outil de communication d'équipe et identifiez les décisions et actions prises lors de la réponse.
3. Ajoutez les informations issues des journaux de surveillance et des déploiements des services concernés. Indiquez toute modification de l'état de l'incident.
4. Notez la date à laquelle les clients ont commencé à signaler le problème et celle à laquelle il a été découvert par les utilisateurs internes. Quel était l'écart temporel ?
5. Créez une métrique pour chaque élément de la chronologie ou de la page d'où proviennent les données, comme une recherche dans un journal, un tweet ou un graphique de surveillance.

Périodes à inclure :

• Le moment où l'impact a commencé
• Lorsque l'équipe a été informée
• Moment de toute action significative
• Le temps que l'impact se soit terminé

intervenants

Décrivez le rôle joué par les membres de l'équipe dans la résolution de l'incident.

Qui a documenté le problème ? Qui d’autre était impliqué ? Précisez les rôles et responsabilités de chaque intervenant, comme l’ingénieur d’astreinte, le responsable des communications et le support technique, ainsi que leurs principales contributions à la gestion de l’incident.

Mettez en évidence les actions spécifiques entreprises par les individus qui ont été cruciales pour résoudre l'incident.

Évaluation

Évaluer le processus de réponse afin de comprendre les points forts, les axes d'amélioration et les facteurs systémiques contributifs.

• Analysez les facteurs contributifs. Allez au-delà de l'incident immédiat pour identifier une combinaison de facteurs contributifs (organisationnels, humains, techniques).
• Évitez de blâmer les individus. Autopsies sans reproche Aider les équipes à progresser, à trouver des solutions et à identifier les pistes d'amélioration. Anonymiser les erreurs et reconnaître que les actions sont entreprises dans un contexte d'incertitude quant à leur issue.
• Examinez les données de surveillance relatives à l'incident, notamment les schémas inhabituels, et assurez-vous que des outils de surveillance sont en place pour prévenir tout problème futur.
• Posez-vous des questions essentielles. Demandez-vous si le problème s'inscrit dans une tendance, s'il reflète des problèmes anticipés ou inattendus, et si des décisions passées y ont contribué.
• Analysez les enseignements tirés de cet incident, en vous concentrant sur l'identification des schémas récurrents. Ces enseignements peuvent orienter les améliorations techniques et organisationnelles, notamment la conception de réponses automatisées. Les équipes devraient s'appuyer sur ces enseignements pour élaborer des stratégies de remédiation automatique, permettant ainsi au système de détecter et de résoudre les problèmes récurrents sans intervention manuelle.
• Analysez comment les processus de collaboration, de communication et d'examen ont influencé l'incident, dans le but d'améliorer les interventions futures.

Mentionnez ce qui a bien fonctionné et ce qui n'a pas fonctionné. Cela permettra de tirer des enseignements de cette expérience afin de prévenir de futurs incidents.

Prochaines étapes et actions à entreprendre

Après avoir relaté tous les détails, quelle est la prochaine étape ?

Identifier les actions à entreprendre pour prévenir toute récidive et réduire la probabilité ou l'impact de problèmes similaires.

Inclure des éléments tels que :

• Étapes prioritaires. Attribuez un niveau de priorité (élevé, moyen, faible) aux actions en fonction de leur urgence et de leur impact potentiel. Désignez également une équipe ou une personne responsable de chaque action afin de garantir la responsabilisation.
• Toute correction nécessaire pour éviter que le problème ne se reproduise.
• Envisager des améliorations en matière de surveillance, d'alerte et Réponse aux incidents pour détecter les problèmes et minimiser l'impact.
• Toute mesure préparatoire susceptible d’améliorer la détection et l’atténuation d’un problème similaire.
• Il s'agit de résoudre les problèmes de processus ou de flux de travail identifiés lors de l'analyse post-mortem, notamment les courriels internes, la mise à jour des pages d'état publiques, etc.
• Toute amélioration apportée au processus de réponse aux incidents.
• Précisez les échéances. Indiquez les dates cibles pour la réalisation de chaque action.

Consignez toutes les actions de suivi dans un outil de gestion des tâches, en étiquetant les tickets avec leur niveau de gravité et leur date pour un suivi facile.

Toutes les actions à entreprendre doivent être réalisables, spécifiques et assorties d'un délai précis afin de garantir qu'elles conduisent à des améliorations significatives et préviennent que des incidents similaires se reproduisent.

• Actionnable : Commencez par un verbe clair et directif pour indiquer à la personne responsable les actions à entreprendre. Soyez précis et utilisez des termes comme « mettre en œuvre » ou « documenter » plutôt que des expressions vagues.
• Spécifique: Définissez précisément le périmètre de chaque action afin d'éviter toute mauvaise interprétation ou ambiguïté. Indiquez les systèmes, processus ou équipes concernés et décrivez les étapes clés à suivre.
• Limité dans le temps : Fixez des échéances claires ou des dates cibles d'achèvement pour éviter les tâches sans date limite.

Messagerie

Il est également important d'inclure des directives concernant les messages de suivi destinés aux employés et les messages destinés aux clients.

Courriel interne

Suite à l'analyse post-incident, envoyez un courriel interne aux employés concernés. Ce courriel doit inclure un bref paragraphe résumant l'incident et un lien vers le rapport d'analyse complet.

Réfléchissez aux employés qui doivent recevoir ce message. En cas de panne majeure ou d'incident affectant toute l'entreprise, il peut être judicieux d'informer tous les employés par souci de transparence. Pour les incidents plus isolés, limitez la diffusion aux équipes ou services directement concernés.

Il convient d'adapter le message aux différents publics. Même après un incident majeur, les équipes directement touchées ou chargées du suivi post-incident peuvent avoir besoin d'instructions spécifiques, en plus de celles diffusées au reste de l'entreprise. Personnaliser la communication permet de s'assurer que chaque groupe comprenne les prochaines étapes et son rôle dans la prévention de futurs incidents.

Message externe

Cela apparaîtra sur le site web/ page d'état Pour les partenaires et les clients : déterminez les informations à communiquer, notamment ce qui s’est passé et les mesures prises. Reconnaissez le problème avec respect et faites preuve d’empathie envers les clients concernés.

Tout comme la communication interne, ce message peut varier en fonction de la gravité de l'incident et des personnes impliquées.

Il peut également être utile de disposer d'un cadre existant plutôt que de partir de zéro. Voici un exemple utile. modèle post-mortem .

Conseils pour rédiger un rapport post-mortem

Nous avons abordé le cadre de base pour la création d'un rapport post-mortem ; voici quelques bonnes pratiques à suivre.

Dos

• Soyez minutieux et précis, et documentez les événements et leurs conséquences avec la plus grande exactitude possible. Soyez honnête et décrivez les événements et leur déroulement.
• Discutez des solutions, pas seulement des problèmes. Autrement dit, faites la distinction entre ce qui s'est passé et comment y remédier.
• Rédigez des tâches de suivi concrètes.
• Définissez le langage et la terminologie. Sachez que certains participants ou lecteurs de la réunion post-mortem peuvent être novices ; assurez-vous donc que chacun soit familiarisé avec la terminologie et les acronymes utilisés.

Ce qu'il ne faut pas faire

• Blâmer les individus ou les équipes. Nommer ou humilier quelqu'un ne fera que le contrarier au lieu de lui offrir une occasion d'apprendre et de s'améliorer.
• Modifier les détails ou les événements pour sauver la face. Les analyses post-mortem ne sont efficaces que si elles incluent des données exactes.
• L'erreur humaine est souvent en cause. Plusieurs facteurs contribuent généralement à un incident. Il est essentiel d'identifier les causes sous-jacentes.

Qui est responsable de la rédaction du rapport d'autopsie ?

Le Commandant des opérations Un membre de l'équipe informatique ou DevOps, généralement désigné comme responsable de l'analyse post-mortem, doit choisir parmi les intervenants celui qui y contribuera. Bien que ce responsable puisse collaborer avec d'autres intervenants à la rédaction de l'analyse, il lui incombe essentiellement de veiller à sa réalisation.

Le propriétaire du véhicule après décès est responsable de :

• Enquête en cours pour déterminer les circonstances de l'incident.
• Créer le rapport d'autopsie et le tenir à jour avec les dernières informations.
• Mise à jour de la page web publique avec les informations pertinentes.
• Planifier la réunion d'autopsie dans un certain nombre de jours en fonction de la gravité de l'incident (dans un délai de trois jours calendaires pour un incident de gravité 1 et de cinq jours ouvrables pour un incident de gravité 2).

Une analyse post-mortem réussie est un outil stratégique pour la croissance, la résilience et l'amélioration continues. En analysant soigneusement chaque aspect d'un incident, de ses causes profondes à sa résolution et aux actions à entreprendre, les équipes peuvent transformer les difficultés en opportunités d'amélioration des systèmes et des processus. Comprendre les étapes et le processus de création d'une analyse post-mortem détaillée peut aider les équipes à faire des incidents des occasions d'apprentissage, de croissance et d'amélioration.

Découvrez comment PagerDuty aide les équipes à gérer les incidents avec confiance et à bâtir des opérations résilientes. Commencez votre essai gratuit de 14 jours dès aujourd'hui .