Ce principe du pilier de fiabilité du Google Cloud framework Well-Architected fournit des recommandations pour vous aider à effectuer des post-mortem efficaces après des échecs et des incidents.
Ce principe s'applique au domaine d'apprentissage Fiabilité.
Présentation des principes
Un post-mortem est un compte-rendu écrit d'un incident, de son impact, des mesures prises pour l'atténuer ou le résoudre, des causes premières et des actions de suivi permettant d'éviter que l'incident ne se reproduise. L'objectif d'un post-mortem est d'apprendre de ses erreurs, et non de chercher des responsables.
Le schéma suivant illustre le workflow d'une autopsie :
Le workflow d'une autopsie comprend les étapes suivantes :
- Créer un post-mortem
- Rassembler les faits
- Identifier et analyser les causes racines
- Planifier l'avenir
- Exécuter le plan
Effectuez des analyses post-mortem après des événements majeurs et non majeurs, comme les suivants :
- Indisponibilités ou dégradations visibles par les utilisateurs au-delà d'un certain seuil.
- Les pertes de données de quelque nature que ce soit.
- Interventions des ingénieurs d'astreinte, comme un rollback de version ou un reroutage du trafic.
- Temps de résolution supérieurs à un seuil défini.
- Échecs de surveillance, qui impliquent généralement une découverte manuelle des incidents.
Recommandations
Définissez des critères de post-mortem avant qu'un incident ne se produise afin que tout le monde sache quand un post-mortem est nécessaire.
Pour effectuer des analyses post-mortem efficaces, tenez compte des recommandations des sous-sections suivantes.
Effectuer des analyses post-mortem non accusatoires
Les post-mortem efficaces se concentrent sur les processus, les outils et les technologies, et ne blâment pas les personnes ni les équipes. L'objectif d'une analyse post-mortem est d'améliorer votre technologie et votre avenir, et non de trouver le coupable. Tout le monde fait des erreurs. L'objectif doit être d'analyser les erreurs et d'en tirer des leçons.
Les exemples suivants illustrent la différence entre les commentaires qui attribuent la responsabilité et ceux qui ne le font pas :
- Commentaires qui attribuent la responsabilité : "Nous devons réécrire l'intégralité du système backend complexe ! Il y a des problèmes chaque semaine depuis trois trimestres. Je suis sûr que nous en avons tous marre de corriger les choses au coup par coup. Sérieusement, si je reçois encore une notification, je vais le réécrire moi-même…"
- Commentaires sans blâme : "Une tâche consistant à réécrire l'ensemble du système backend pourrait en fait empêcher ces pages de continuer à se produire. Le manuel de maintenance de cette version est assez long et il est vraiment difficile de se former complètement. Je suis sûr que nos futurs ingénieurs d'astreinte nous remercieront !"
Rendre le rapport post-mortem lisible par toutes les audiences cibles
Pour chaque information que vous prévoyez d'inclure dans le rapport, évaluez si elle est importante et nécessaire pour aider le public à comprendre ce qui s'est passé. Vous pouvez déplacer les données et explications supplémentaires dans une annexe du rapport. Les examinateurs qui ont besoin d'informations supplémentaires peuvent les demander.
Éviter les solutions complexes ou surdimensionnées
Avant de commencer à explorer des solutions à un problème, évaluez son importance et la probabilité qu'il se reproduise. Ajouter de la complexité au système pour résoudre des problèmes qui ne se reproduiront probablement plus peut entraîner une instabilité accrue.
Partagez le post-mortem aussi largement que possible
Pour vous assurer que les problèmes ne restent pas sans solution, publiez les résultats de l'autopsie auprès d'une large audience et obtenez l'aide de la direction. La valeur d'une autopsie est proportionnelle à l'apprentissage qui a lieu après l'autopsie. Plus les utilisateurs tirent des enseignements des incidents, moins il est probable que des échecs similaires se reproduisent.