Post-mortems des incidents

Qu'est-ce qu'un post-mortem ?

Un post-mortem est un rapport écrit d'un incident qui décrit :

• L'impact de l'incident.
• Les actions prises pour réduire ou résoudre l'incident.
• La cause profonde de l'incident.
• Les actions de suivi prises pour éviter une ré-occurrence de l'incident.

Chez Atlassian, nous suivons tous les post-moderns avec des tickets Jira pour nous assurer qu'ils sont complétés et approuvés. Si vos besoins sont moins complexes, vous pouvez décider d'utiliser un système plus simple, comme une page Confluence pour chaque post-mortem.

Pourquoi réalisons-nous des post-mortems ?

Les objectifs d'un post-mortem sont de comprendre toutes les causes profondes, de documenter l'incident pour référence future et identification de modèles, et de mettre en place des actions préventives efficaces pour réduire la probabilité ou l'impact d'une récurrence de l'incident.

Pour que les post-mortems parviennent efficacement à réduire la répétition d'incidents, le processus de révision doit inciter les équipes à identifier les causes profondes et à les résoudre. La méthode exacte dépend de la culture de votre équipe. Chez Atlassian, nous avons trouvé une combinaison de méthodes qui fonctionnent pour nos équipes de réponse aux incidents :

• Les réunions en face à face aident à conduire une analyse appropriée et à aligner l'équipe sur les points qui nécessitent une résolution.
• Des approbations de post-mortems par les responsables des équipes de livraison et des opérations incitent les équipes à les mener à bien.
• Les « actions prioritaires » désignées ont un objectif de niveau de services convenu, soit 4 ou 8 semaines, selon le service, avec des rappels et des rapports pour s'assurer qu'elles sont mises en œuvre.

Participer à ce processus et s'assurer de son efficacité nécessite un engagement à tous les niveaux de l'organisation. Nos responsables directeurs de l'ingénierie ont décidé des approbateurs et des objectifs de niveau de services pour la résolution des problèmes dans leurs domaines. Ce système encode et essaie d'appliquer leurs décisions.

Quand un post-mortem est-il requis ?

Nous réalisons des post-mortems pour les incidents de gravité 1 et 2. Autrement, ils sont facultatifs.

Pendant ou peu après la résolution du ticket, le propriétaire du post-mortem crée un nouveau ticket de post-mortem.

Qui réalise un post-mortem ?

L'équipe de livraison du service qui a rencontré un problème (l'équipe propriétaire du « service défectueux » sur le ticket de l'incident) est responsable de la réalisation du post-mortem. Cette équipe sélectionne le responsable du post-mortem et lui attribue le ticket du post-mortem.

• Le responsable du post-mortem gère le post-mortem par le biais de la rédaction et de l'approbation, jusqu'à sa publication. Il est responsable de la réalisation du post-mortem.
• Un ou deux approbateurs de post-mortems passent en revue et approuvent le post-mortem, et doivent prioriser les actions de suivi dans leur backlog.

Nous avons une page Confluence qui répertorie les approbateurs de post-mortems (obligatoires et facultatifs) par groupe de service, lequel correspond généralement à un produit Atlassian (p. ex., Bitbucket Cloud).

Comment sont suivies les actions d'un post-mortem ?

Pour chaque action tirée du post-mortem, nous :

• Créez un ticket Jira dans le backlog de l'équipe qui en est responsable. Toutes les actions de post-mortem doivent être suivies dans Jira.
• Associez-les depuis le ticket du post-mortem en tant qu'« action prioritaire » (pour les correctifs de cause profonde) ou en tant qu'« action d'amélioration » (pour les améliorations qui ne concernent une cause profonde).

Nous avons créé des rapports personnalisés à l'aide des API REST de Jira pour déterminer le nombre d'incidents de chaque gravité dont les causes profondes n'ont pas été corrigées par les actions prioritaires dans le post-mortem. Les responsables en ingénierie de chaque service passent régulièrement cette liste en revue.

Processus de post-mortem

L'exécution du processus de post-mortem comprend la création d'un ticket de post-mortem, l'organisation d'une réunion de post-mortem, la capture d'actions, l'obtention de l'approbation et (éventuellement) la communication du résultat.

Le responsable du post-mortem est chargé de l'exécution de ces tâches :

1. Créez un post-mortem et associez-le à l'incident.
2. Modifiez le ticket du post-mortem, lisez les descriptions des champs et complétez-les.
3. Pour déterminer la cause profonde de l'incident, utilisez la technique des « cinq pourquoi » afin de parcourir la chaîne causale jusqu'à ce que vous trouviez une cause véritable.
4. Planifiez la réunion du post-mortem. Invitez l'équipe de livraison, les équipes impactées et les parties prenantes, à l'aide du modèle d'invitation à la réunion.
5. Réunissez l'équipe et parcourez les points des réunions ci-dessous.
6. Effectuez un suivi avec les responsables du développement en charge pour obtenir l'engagement de mesures spécifiques qui préviendront ce type d'incident.
7. Créez un ticket Jira pour chaque action dans les backlogs des équipes qui en sont responsables. Associez-les depuis le ticket du post-mortem en tant qu'« action prioritaire » (pour les correctifs de cause profonde) ou en tant qu'« action d'amélioration » (pour les autres améliorations).
8. Recherchez les approbateurs appropriés dans Confluence et ajoutez-les au champ « Approbateurs » du post-mortem.
9. Sélectionnez la transition « Demande d'approbation » pour demander l'approbation des approbateurs désignés. L'automatisation commentera le ticket avec des instructions pour les approbateurs.
10. Effectuez un suivi au besoin jusqu'à ce que le post-mortem soit approuvé.
11. Lorsque le post-mortem est approuvé, nous disposons d'une fonction automatique de création d'un brouillon de blog relatif au post-mortem dans Confluence pour que vous puissiez le modifier et le publier. Publier des articles de blog relatifs aux post-mortems vous permet de partager les leçons durement acquises, ce qui multiplie leur valeur.

Une fois le processus de post-mortem terminé, les actions sont priorisées en fonction de l'équipe de développement dans le cadre de leur backlog normal, conformément aux objectifs de niveau de services de l'équipe.

Réunions de post-mortem

Nous constatons que réunir l'équipe pour discuter des apprentissages permet d'affiner l'analyse des causes profondes. Cela se fait souvent par vidéoconférence en raison de la distance physique qui sépare nos équipes et parfois par groupes lorsque des incidents impliquent de grands groupes de personnes.

Notre proposition de programme :

1. Rappelez à l'équipe que les post-mortems se font sans reproche et pourquoi
2. Confirmez la chronologie des événements
3. Confirmez les causes profondes
4. Générer des actions en utilisant la « réflexion ouverte » : « Que pourrions-nous faire pour empêcher cette classe d'incident à l'avenir ? »
5. Demandez à l'équipe : « Qu'est-ce qui s'est bien passé ? / Qu'est-ce qui aurait pu aller mieux ? / Où avons-nous eu de la chance ? »

Modèle de proposition de réservation de calendrier :

Joignez-vous à moi pour un post-mortem sans reproche de , où nous .

Les objectifs d'un post-mortem sont de comprendre toutes les causes profondes, de documenter l'incident pour référence future et identification de modèles, et de mettre en place des actions préventives efficaces pour réduire la probabilité ou l'impact d'une récurrence de l'incident.

Lors de cette réunion, nous essayerons de déterminer les causes profondes et de décider de mesures pour les réduire.

Si les responsables du développement en charge ne sont pas présents, évitez de vous engager pour des mesures spécifiques lors de la réunion, car le contexte est peu propice aux décisions de priorisation. Les gens se sentiront obligés de s'engager et ne disposent pas de toutes les informations. Réalisez plutôt un suivi avec les responsables après la réunion pour qu'ils s'engagent à entreprendre les mesures prioritaires identifiées.

Champs d'un ticket de post-mortem

Notre ticket de post-mortem comporte une série de champs destinés à la collecte de tous les détails importants sur l'incident avant la réunion de post-mortem. Voici quelques exemples de la façon dont nous remplissons ces champs.

Causes directes et profondes

Lorsque vous rédigez ou lisez une autopsie, il est nécessaire de faire la distinction entre les causes immédiates et les causes profondes.

• Les causes immédiates sont des raisons qui ont conduit directement à cet incident.
• Les causes profondes sont des raisons à l'endroit optimal dans la chaîne d'événements où tout changement empêchera toute cette classe d'incidents.

Un post-mortem cherche à découvrir les causes profondes et à déterminer la meilleure façon de les atténuer. Trouver la place optimale dans la chaîne d'événements est le véritable art du post-mortem. Utilisez une technique comme les Cinq pourquoi pour « remonter la chaîne » et identifier des causes profondes.

Voici quelques exemples de causes immédiates et profondes :

Catégories de cause profonde et leurs actions

Nous utilisons ces catégories pour regrouper les causes profondes et discuter des actions appropriées pour chacune.

Causes profondes avec dépendances

Lorsque votre service rencontre un incident suite à une défaillance de dépendance, l'emplacement de la défaillance et sa cause profonde varient selon que la dépendance est interne à Atlassian ou à une tierce partie, et en fonction des attentes raisonnables de performances de la dépendance.

S'il s'agit d'une dépendance interne, cherchez à savoir « quels sont les objectifs de niveau de services de la dépendance ? » :

• La dépendance a-t-elle violé ses objectifs de niveau de service ?
  • La panne est liée à la dépendance, et cette dernière doit augmenter sa fiabilité.
• Votre service a-t-il rencontré un problème alors même que la dépendance respectait ses objectifs de niveau de service ?
  • Votre service doit augmenter sa résilience.
• La dépendance n'a-t-elle pas d'objectif de niveau de service ?
  • Il lui en faut !

S'il s'agit d'une dépendance tierce, cherchez à savoir « Quelles sont les attentes* que nous pouvons raisonnablement avoir concernant la disponibilité/latence/etc. de la dépendance d'un tiers ? »

• La dépendance du tiers a-t-elle dépassé nos attentes (de manière négative) ?
  • Nos attentes n'étaient pas appropriées.
    • Sommes-nous convaincus que cela ne se reproduira plus ? Par exemple, nous examinons et sommes d'accord avec leur analyse des causes profondes. Le cas échéant, l'action est leur analyse des causes profondes.
    • Ou devons-nous revoir nos attentes ? Dans ce cas, les actions doivent accroître notre résilience et ajuster nos attentes.
    • Nos attentes ajustées sont-elles inacceptables ? Dans ce cas, nous devons résoudre le problème de l'écart entre les exigences et la solution, par exemple en trouvant un autre fournisseur.
• Votre service a-t-il rencontré un problème alors même que la dépendance respectait nos attentes ?
  • Le cas échéant, votre service doit augmenter sa résilience.
• N'avons-nous pas vraiment d'attentes ?
  • Le propriétaire de la dépendance tierce doit en établir et les partager avec les équipes afin qu'elles connaissent le niveau de résilience dont elles ont besoin pour intégrer les services dépendants.

* Pourquoi des « attentes » ? N'avons-nous pas des SLA avec des tiers ? En réalité, les SLA contractuels avec des tiers sont trop bas pour être utiles dans la détermination des fautes et des mesures d'atténuation. Par exemple, AWS ne publie presque aucun SLA pour EC2. Par conséquent, lorsque nous dépendons d'un service tiers, nous devons décider du niveau de fiabilité, de disponibilité, de performance ou de tout autre indicateur clé que nous en attendons.

Actions de post-mortem

Sue Lueder et Betsy Beyer de Google ont réalisé une excellente présentation et un brillant article sur les éléments d'action post-mortem, auxquelles nous soumettons l'équipe chez Atlassian.

Répondez aux questions ci-dessous pour vous assurer que la revue post-incident (PIR) couvre des correctifs à court et à long terme :

« Atténuer les futurs incidents » et « Prévenir les futurs incidents » sont vos sources d'actions les plus probables pour résoudre la cause profonde. Assurez-vous d'en mettre en place au moins une.

Approbations de post-mortem

Atlassian utilise un workflow Jira avec étape d'approbation pour garantir l'approbation des post-mortems. Les approbateurs sont généralement des responsables de service ou d'autres responsables chargés de la gestion d'un service. L'approbation d'un post-mortem indique ce qui suit :

• Accord sur les résultats de la revue post-incident, notamment sur la nature de la cause profonde ; et
• Accord sur le fait que les « actions prioritaires » associées constituent une bonne façon de traiter la cause profonde.

Souvent, nos approbateurs exigeront des actions supplémentaires ou identifieront un certain lien de causalité non traité par les actions proposées. De cette façon, nous constatons que les approbations ajoutent une forte valeur ajoutée à notre processus post-mortem chez Atlassian.

Dans les équipes rencontrant moins d'incidents ou utilisant une infrastructure moins complexe, les approbations post-mortems ne sont pas forcément nécessaires.

Post-mortems sans reproche

Quand les choses tournent mal, rechercher un bouc-émissaire est une tendance humaine naturelle. Cependant, Atlassian a tout intérêt à éviter ce scénario. C'est pourquoi lorsque vous exécutez un post-mortem, vous devez expressément combattre cette tendance. Nous prêtons de bonnes intentions à notre personnel et nous ne blâmons jamais les personnes pour leurs erreurs. Le post-mortem doit examiner honnêtement et objectivement les circonstances qui ont entraîné l'erreur, de sorte à trouver la ou les véritables causes profondes et les traiter. Blâmer les personnes met à mal cette approche pour les raisons suivantes :

• Lorsque les personnes sentent le risque que leur image soit ternie aux yeux de leurs collègues ou que leurs perspectives de carrière soient bouchées, ce risque prend le pas sur « les meilleurs intérêts de mon employeur » dans leur hiérarchie personnelle. C'est à ce moment-là qu'ils dissimuleront la vérité afin de protéger leurs besoins fondamentaux.
• Même si une personne a exécuté une action qui a causé un incident, nous ne devons pas nous demander « pourquoi l'individu x a fait ce qu'il fait », mais plutôt « pourquoi le système lui a-t-il permis de le faire, ou lui a-t-il laissé entendre que c'était la meilleure chose à faire ».
• Blâmer les individus est rude et, en cas de répétitions fréquentes, créera une culture empreinte de peur et de méfiance.

Dans nos post-mortems, nous utilisons ces techniques pour garantir la sécurité personnelle de tous les participants :

• Ouvrez la réunion de post-mortem en indiquant qu'il s'agit d'un post-mortem sans reproches et en expliquant pourquoi
• Adressez-vous aux individus par leur rôle (p. ex., « l'ingénieur des widgets d'astreinte ») au lieu de leur nom (tout en restant clair et sans ambiguïté quant aux faits)
• Assurez-vous que le calendrier post-mortem, la chaîne causale et les atténuations sont encadrés dans le contexte des systèmes, des processus et des rôles, et non des individus.

Notre inspiration pour les post-mortems sans reproche et le concept utile de « second stories » nous vient de l'article phare de John Allspaw.