Close

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

Page d'accueil de gestion des incidents

Post-mortems des incidents

Chez Atlassian, nous pratiquons les post-mortems sans reproche pour veiller à comprendre et à corriger la cause profonde de chaque incident dont le niveau de gravité est 2 ou plus. Voici une version résumée de notre documentation interne décrivant la façon dont nous réalisons les post-mortems chez Atlassian.

Manuel de gestion des incidents

Obtenir le manuel en version imprimée ou au format PDF

Nous disposons d'un nombre limité de versions imprimées de notre manuel de gestion des incidents que nous fournissons gratuitement. Vous pouvez également télécharger la version PDF.


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.

Champ

Instructions

Exemple

Résumé de l'incident

Résumez l'incident en quelques phrases. Incluez sa gravité, les raisons et la durée de l'impact.

Entre le , clients ont été confrontés à . L'événement a été déclenché par un déploiement à . Le déploiement contenait un changement de code pour . Le bug dans le déploiement a provoqué .

L'événement a été détecté par . Nous avons réduit l'impact de l'événement en .

Cet incident de niveau a affecté X % des clients.

ont été créé(e)(s) au sujet de cet incident.

Prémices

Décrivez les circonstances qui ont entraîné l'incident, par exemple, changements antérieurs qui a introduit des bugs latents.

À le , (), un changement a été apporté à pour… . Le changement a provoqué… .

Panne

Décrivez ce qui n'a pas fonctionné comme prévu. Joignez des captures d'écran des données ou des graphiques pertinents sur la panne.

réponses ont par erreur été envoyées à X % des demandes durant .

Impact

Décrivez ce que les clients internes et externes ont vu lors de l'incident. Incluez le nombre de cas de support créés.

Pour entre le , a été constaté.

Ceci a affecté clients (X % de tous les clients ), qui ont constaté .

ont été créés.

Détection

Comment et quand Atlassian a-t-il détecté l'incident ?

Comment le temps de détection pourrait-il être amélioré ? À titre d'exercice de réflexion, comment réduiriez-vous ce temps de moitié ?

L'incident a été détecté lorsque le a été déclenché et que <équipe ou personne appelée> a été appelée. Cette personne ou équipe a ensuite dû appeler , car elle ne possédait pas le service d'écriture sur le disque, retardant la réponse de .

sera définie par <équipe responsable de l'amélioration> pour que .

Réponse

Qui a répondu, quand et comment ? Y a-t-il eu des retards ou des obstacles à notre réponse ?

Après avoir été appelé à 14 h 34 (UTC), l'ingénieur KITT s'est connecté à 14 h 38 dans le groupe de discussion sur l'incident. Cependant, l'ingénieur d'astreinte n'avait pas suffisamment d'informations sur la mise à l'échelle automatique d'Escalator ; une autre alerte a donc été envoyée à 14 h 50 et un ingénieur KITT de haut niveau a rejoint le groupe à 14 h 58.

Récupération

Décrivez comment et quand le service a été rétabli. Comment en êtes-vous arrivé au stade où vous avez compris comment réduire l'impact ?

Questions supplémentaires à poser en fonction du scénario : Comment améliorer le temps d'atténuation ? À titre d'exercice de réflexion, comment réduiriez-vous ce temps de moitié ?

La reprise était une réponse à trois volets :

  • Augmentation de la taille de l'ASG BuildEng EC2 afin d'augmenter le nombre de nœuds disponibles pour traiter 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

Fournissez une chronologie détaillée des incidents horodatée avec les fuseaux horaires.

Indiquez toutes les prémices ; début de l'impact ; temps de détection ; remontées, décisions et changements ; et fin de l'impact.

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 de Goliath 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 300 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, la charge du cluster est normale et l'impact sur le client est résolu.

Cinq pourquoi

Utilisez la technique d'identification de la cause profonde.

Commencez par l'impact et cherchez pourquoi l'incident s'est produit et pourquoi il a eu cet impact. Continuez à chercher pourquoi jusqu'à ce que vous arriviez à la cause profonde.

Documentez vos « pourquoi » sous forme de liste ici ou dans un diagramme joint au ticket.

  1. Le service a été interrompu, car la base de données était verrouillée

  2. Parce que le nombre d'écritures dans les bases de données était trop important

  3. Parce qu'un changement a été apporté au service et que l'augmentation n'était pas prévue

  4. Parce que nous n'avons pas de processus de développement configuré pour les moments où nous devons charger les changements de test

  5. Nous n'avons jamais effectué de test de charge et atteignons de nouveaux niveaux d'échelle

Cause profonde

Quelle était la cause profonde ? C'est ce qui doit changer pour empêcher que cette classe d'incident ne se reproduise.

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

Un élément de votre backlog aurait-il pu empêcher l'incident ou réduire son impact ? Si oui, pourquoi n'a-t-il pas été exécuté ?

Ici, une évaluation honnête aide à clarifier les décisions passées en matière de priorité et de risque.

Pas spécifiquement. Les améliorations apportées au typage des flux étaient des tâches en cours connues pour lesquelles des rituels étaient en place (par exemple, ajouter des types de flux lorsque vous changez/créez un fichier). Des tickets de réparation des tests d'intégration ont été créés, mais n'ont pas eu les résultats attendus

Récurrence

Cet incident (ou un autre incident avec la même cause profonde) s'est-il déjà produit auparavant ? Le cas échéant, pourquoi s'est-il de nouveau produit ?

La même cause profonde a provoqué les incidents HOT-13432, HOT-14932 et HOT-19452.

Enseignements

Qu'en avons-nous appris ?

Discutez de ce qui s'est bien passé, de ce qui aurait pu aller mieux et des possibilités d'amélioration que nous avons eu la chance de trouver.

  1. Besoin d'un test unitaire pour vérifier que le limiteur de vitesse pour le travail a été correctement entretenu

  2. Les charges de travail en vrac atypiques par rapport au fonctionnement normal doivent être examinées

  3. Les opérations en bloc devraient démarrer lentement et être surveillées, augmentant lorsque les indicateurs de service semblent faibles

Actions correctives

Qu'allons-nous faire pour nous assurer que cette classe d'incident ne se reproduise plus ? Qui va prendre les mesures et quand ?

Créer des liens de ticket « Action prioritaire » vers les tickets de suivi de chaque action.

  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

  4. Les migrations volumineuses doivent être coordonnées, car AWS ES n'effectue pas automatiquement la mise à l'échelle.

  5. Vérifiez que la recherche Stride est toujours classée comme Tier-2

  6. Créez un ticket sur pf-directory-service pour une panne partielle au lieu d'une panne complète lorsque xpsearch-chat-searcher échoue.

  7. Alerte Cloudwatch pour identifier un problème d'E/S élevé sur le cluster ElasticSearch


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 :

Scénario Cause immédiate et action Cause profonde Atténuation des causes profondes

Les services de l'équipe Stride « Red Dawn » ne disposaient pas de moniteurs Datadog et d'alertes d'astreinte pour leurs services, ou ils n'étaient pas correctement configurés.

Les membres de l'équipe n'ont pas configuré la surveillance et les alertes pour les nouveaux services.

Configurez-les pour ces services.

Il n'existe pas de processus pour créer de nouveaux services, notamment de surveillance et d'alerte.

Créez un processus de mise en place de nouveaux services et apprenez à l'équipe à le suivre.

Stride inutilisable sur IE11 en raison d'une mise à niveau vers Fabric Editor qui ne fonctionne pas sur cette version du navigateur.

La mise à niveau d'une dépendance.

Annulez la mise à niveau.

Absence de test de compatibilité entre navigateurs.

Automatisez les tests de compatibilité entre navigateurs en continu.

Les journaux de Micros EU ne parvenaient pas au service de journalisation.

Le rôle fourni aux micros pour envoyer des journaux était incorrect.

Corrigez le rôle.

Nous ne pouvons pas savoir quand la journalisation depuis un environnement ne fonctionne pas.

Ajoutez la surveillance et les alertes sur les journaux manquants pour tous les environnements.

Déclenchés par un incident AWS antérieur, les nœuds Confluence Vertigo ont épuisé leur pool de connexions à Media, entraînant des erreurs intermittentes de pièces jointes et de médias pour les clients.

Panne AWS.

Récupérez le post-mortem AWS.

Un bug dans la gestion du pool de connexions Confluence a entraîné une fuite de connexions lors de la panne, ainsi qu'un manque de visibilité sur l'état des connexions.

Corrigez le bug et ajoutez une surveillance qui détectera les situations similaires futures avant qu'elles aient un impact.


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.

Catégorie

Définition

Que devriez-vous faire à ce sujet ?

Bug

Un changement de code réalisé par Atlassian (il s'agit d'un type de changement spécifique)

Test. Canari. Effectuez des déploiements incrémentiels et surveillez-les. Utilisez des flags de fonctionnalité. Parlez à votre ingénieur de la qualité.

Changement

Un changement apporté par Atlassian (autre qu'au code)

Améliorez la façon dont vous apportez les changements, par exemple, vos examens des changements ou vos processus de gestion des changements. Tout ce qui se rapproche d'un « bug » s'applique également ici.

Évolutivité

Échec de la mise à l'échelle (p. ex., ignorance des contraintes liées aux ressources ou manque de planification des capacités)

Quelles sont les contraintes liées aux ressources de votre service ? Sont-elles surveillées et contrôlées par des alertes ? Si vous ne disposez pas d'un plan des capacités, faites-en un. Si vous en avez un, quelle nouvelle contrainte devez-vous prendre en compte ?

Architecture

Mauvais alignement de la conception avec les conditions opérationnelles

Révisez votre conception. Devez-vous changer de plateforme ?

Dépendance

Panne de service tiers (non fourni par Atlassian)

Gérez-vous les risques de panne tierce ? Avons-nous pris la décision métier d'accepter un risque ou devons-nous élaborer des mesures d'atténuation ? Reportez-vous à « Causes profondes avec dépendances » ci-dessous.

Inconnu

Indéterminable (une action consiste à augmenter la capacité de diagnostic)

Améliorez l'observabilité de votre système en ajoutant des fonctionnalités de journalisation, de surveillance, de débogage et d'autres fonctions similaires.


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.

Catégorie Question à poser Exemples

Examiner cet incident

« Qu'est-ce qui a provoqué cet incident et pourquoi ? » Déterminer les causes profondes est votre but ultime.

Analyses de journaux, schématisation du parcours de la requête, examen des heap dumps

Atténuer cet incident

« Quelles actions immédiates avons-nous entreprises pour résoudre et gérer cet événement spécifique ? »

Annulation d'un changement, sélection, apport de changements à des configurations, communication avec les utilisateurs concernés

Réparer les dommages causés par cet incident

« Comment réparer les dommages directs ou collatéraux causés par cet incident ? »

Restauration des données, réparation des machines, suppression des réacheminements du trafic

Détecter les incidents futurs

« Comment réduire le délai nécessaire pour détecter précisément un incident similaire ? »

Surveillance, alerte, contrôles de vraisemblance sur les entrées/sorties

Réduire le nombre d'incidents futurs

« Comment limiter la gravité et/ou la durée des incidents similaires futurs ? »

« Comment réduire le pourcentage d'utilisateurs affectés par cette classe d'incident lors de la prochaine occurrence ? »

Dégradation progressive, abandon des résultats non critiques, authentification sans mot de passe, augmentation des pratiques actuelles avec des tableaux de bord ou des playbooks, changements apportés aux processus d'incident

Prévenir les incidents futurs

« Comment éviter la récurrence de ce type d'incident ? »

Améliorations de la stabilité de la base de code, tests unitaires plus approfondis, validation des entrées et résistance aux erreurs, changements apportés au provisionnement

Nous suivons aussi les conseils de Sue Lueder et de Betsy Beyer sur la manière de formuler nos actions post-mortems.

Formulation des actions post-mortems :

La formulation adaptée pour une action post-mortem peut faire la différence entre une exécution simple et un délai indéfini dû à une impossibilité ou à la procrastination. Une action post-mortem bien conçue devrait présenter ces propriétés :

Exploitable : indiquez chaque action sous forme de phrase commençant par un verbe. L'action doit donner un résultat utile, et non un processus. Par exemple, « Énumérez la liste des dépendances critiques » est une action adaptée, alors que « Examinez les dépendances » n'en est pas une.

Spécifique : définissez la portée de chaque action le plus précisément possible, en clarifiant ce qui est compris ou non dans le travail.

Limité : formulez chaque action pour expliquer comment indiquer qu'elle est finie, par opposition à laisser l'action ouverte ou en cours.

De… À…

Examinez la surveillance pour ce scénario.

(Exploitable) Ajoutez une alerte pour tous les cas où ce service renvoie plus de 1 % d'erreurs.

Corrigez l'erreur qui a entraîné la panne.

(Spécifique) Gérez le code postal non valide dans le formulaire d'adresse de l'utilisateur en toute sécurité.

Assurez-vous que l'ingénieur vérifie que le schéma de base de données peut être analysé avant la mise à jour.

(Limité) Ajoutez une vérification automatisée avant la soumission pour les changements de schéma.


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.

Restez calme et poursuivez…

Vous êtes arrivé au bout de notre manuel de gestion des incidents. Nous vous remercions de l'avoir lu.

Pour nous faire part de votre feedback ou de vos suggestions, écrivez-nous à l'adresse suivante : incident-handbook@atlassian.com.