Close

La voie vers une meilleure gestion des incidents
débute ici

Création de rapports post-mortem

La collecte et la documentation des données sont essentielles au processus de post-mortem d'incident

Un post-mortem d'incident peut être divisé en deux artefacts distincts : la réunion qui a l'incident pour objet et le rapport post-mortem correspondant créé suite à cette réunion.

Ces deux activités, la réunion et le rapport, sont souvent utilisées de façon interchangeable lorsqu'il est question de « post-mortem ». Les employés peuvent parler de l'une ou de l'autre, ou des deux, lorsqu'ils utilisent le terme.

Vous voulez vous lancer avec un modèle de post-mortem ? Consultez nos modèles de post-mortem.

Mais il y a une différence entre la réunion post-mortem et le rapport écrit.

Chez Atlassian, nous utilisons généralement le terme « post-mortem » (ou post-mortem d'incident) pour décrire l'ensemble du processus d'analyse d'un incident et pour réaliser les tâches suivantes :

  • Exécuter une réunion de post-mortem d'incident
  • Capturer les actions et informations durant la réunion
  • Obtenir l'approbation sur les actions de suivi et communiquer les résultats de la réunion

Pour en savoir plus sur la manière dont Atlassian gère les post-mortems, consultez notre manuel de gestion des incidents.

Qu'est-ce qui caractérise un bon rapport sur un post-mortem d'incident ?

Invites claires et cohérentes

Un bon rapport devrait reposer sur un framework clair et cohérent. Les équipes efficaces utilisent un modèle de post-mortem qui permet aux participants de répondre à un ensemble de questions ou d'invites.

Cette approche garantit de ne pas omettre les informations clés. Elle renforce également la cohérence entre les incidents et aide l'équipe à identifier les modèles, les tendances et les possibilités d'amélioration. Vous pouvez itérer sur le framework et l'améliorer au fil du temps, mais tout changement devrait être intentionnel.

Données et détails riches

Dans les champs de post-mortem, il ne s'agit pas de lésiner sur les détails et de passer des événements sous silence. Au contraire, soyez très granulaire et spécifique. Ne dites pas que vous avez noté un pic de trafic, décrivez précisément la métrique qui a changé et dans quelle mesure. Ne dites pas que l'équipe était confuse, copiez-collez une citation exacte de l'historique du chat où quelqu'un a exprimé une certaine confusion.

Langage inclusif et sans reproches

Comme beaucoup d'équipes, Atlassian utilise les post-mortems sans reproches. Il faut éviter à tout prix de pointer les autres du doigt lors de la réunion et de l'analyse de l'incident. Appliquez aussi cette règle lorsque vous rédigez le rapport. Évitez d'utiliser un langage empreint de reproches ou qui désigne une personne en particulier.

Questions importantes à poser lors d'un rapport post-mortem

Voici les invites incluses dans la fonctionnalité de post-mortem d'Opsgenie :

  • Origine
    Décrivez les circonstances qui ont entraîné l'incident
  • Défaut
    Décrivez ce qui n'a pas fonctionné comme prévu
  • Détection
    Décrivez la détection de l'incident
  • Causes profondes
    Exécutez une analyse des « Cinq pourquoi » pour comprendre les véritables causes de l'incident
  • Atténuation et résolution
    Quelles mesures avez-vous prises pour résoudre cet incident ?
  • Leçons apprises
    Qu'est-ce qui s'est bien passé ? Qu'est-ce qui était perfectible ? Qu'avez-vous appris d'autre ?

Consultez notre article sur les modèles de post-mortem pour obtenir plus d'exemples de questions à inclure dans un rapport post-mortem.

Autres éléments à inclure dans un rapport post-mortem

  • Captures d'écran
    Joignez des captures d'écran pertinentes, en particulier celles que l'équipe d'intervention a prises pendant la panne. Quels changements avez-vous remarqués au niveau du produit ? Quel comportement du produit n'était pas prévu ?
  • Tickets
    Lien vers tous les tickets pertinents liés à l'incident.
  • Feedback des clients
    Avez-vous reçu un feedback des clients au sujet de l'incident ? Tout feedback peut être donné au centre d'assistance, par e-mail ou sur les réseaux sociaux. Vous n'êtes pas obligé d'inclure l'intégralité du message.
  • Graphiques et diagrammes
    Quelles visualisations de données permettent de montrer l'impact de l'incident ?
  • Données
    Existe-t-il d'autres données clés sur l'incident ou son impact ?
  • Discussions sur le chat
    Si l'équipe utilise un outil de chat tel que Slack pendant les efforts de réponse, envisagez d'inclure les messages ou échanges clés de l'historique du chat.
  • Chronologies
    Une chronologie claire de l'incident constitue un excellent outil pour analyser l'incident. Elle indique les événements clés de l'incident et leur horodatage.

Rapports post-mortem internes et externes

Bien que ce soit moins courant, certaines organisations choisissent de publier une version publique d'un post-mortem après un incident. Cette publication est particulièrement fréquente pour les services aux consommateurs à grande échelle qui rencontrent des pannes affectant de nombreux utilisateurs. Ils peuvent publier le rapport post-mortem complet, ou (plus probablement) une version abrégée du rapport interne. Il peut être nécessaire d'effacer certaines informations sensibles ou privées.

suivant
Meeting