Ce principe du pilier de fiabilité du framework d'architecture Google Cloud fournit des recommandations pour vous aider à effectuer des analyses post-mortem efficaces après des échecs et des incidents.
Ce principe est pertinent pour la zone de concentration de l'apprentissage sur la 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 profondes et des mesures de suivi pour éviter que l'incident ne se reproduise. L'objectif d'une analyse post-mortem est de tirer des leçons des erreurs et non d'attribuer la faute.
Le diagramme suivant illustre le workflow d'une analyse post-mortem:
Le workflow d'une analyse post-mortem comprend les étapes suivantes:
- Créer une analyse post-mortem
- Recueillir les faits
- Identifier et analyser les causes profondes
- Planifier l'avenir
- Exécuter le plan
Effectuez des analyses post-mortem après des événements majeurs et non majeurs, comme les suivants:
- Temps d'arrêt ou dégradations visibles par l'utilisateur au-delà d'un certain seuil
- Perte de données de quelque nature que ce soit
- Interventions des ingénieurs de garde, telles qu'un rollback de version ou un réacheminement du trafic.
- Durée de résolution supérieure à un seuil défini
- Les échecs de surveillance, qui impliquent généralement la découverte manuelle des incidents.
Recommandations
Définissez des critères d'analyse post-mortem avant qu'un incident ne se produise afin que tout le monde sache quand une analyse post-mortem est nécessaire.
Pour effectuer des analyses post-mortem efficaces, tenez compte des recommandations des sous-sections suivantes.
Réaliser des analyses post-mortem irréprochables
Les analyses post-mortem efficaces se concentrent sur les processus, les outils et les technologies, et ne blâment pas les individus ni les équipes. L'objectif d'une analyse post-mortem est d'améliorer votre technologie et votre avenir, et non de déterminer qui est responsable. Tout le monde fait des erreurs. L'objectif doit être d'analyser les erreurs et d'en tirer des enseignements.
Les exemples suivants montrent la différence entre les commentaires qui attribuent la faute et ceux qui ne le font pas:
- Commentaires qui attribuent la faute: "Nous devons réécrire l'ensemble du système backend complexe. Il tombe en panne chaque semaine depuis les trois derniers trimestres, et je suis sûr que nous sommes tous fatigués de réparer les choses au coup par coup. Sérieusement, si je suis appelé une fois de plus, je vais le réécrire moi-même…"
- Feedback sans blâme: "Une action visant à réécrire l'ensemble du système backend pourrait empêcher ces pages de continuer à s'afficher. Le manuel de maintenance de cette version est assez long et très difficile à maîtriser. Je suis sûr que nos futurs ingénieurs de garde nous en seront reconnaissants !"
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 l'audience à 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 en demander.
Évitez les solutions complexes ou trop complexes
Avant de commencer à envisager 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 sont pas susceptibles de se reproduire peut entraîner une instabilité accrue.
Partagez le post-mortem aussi largement que possible
Pour vous assurer que les problèmes ne restent pas non résolus, publiez les résultats de l'analyse post-mortem auprès d'un large public et obtenez l'aide de la direction. La valeur d'une analyse post-mortem est proportionnelle à l'apprentissage qui se produit après l'analyse. Lorsque davantage de personnes tirent des enseignements des incidents, la probabilité de défaillances similaires se répétant est réduite.