Utilisation de l'analyse des 5 raisons dans les rapports d'incidents - Amazon CloudWatch

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de l'analyse des 5 raisons dans les rapports d'incidents

Lors de la génération de rapports d'incidents, les CloudWatch enquêteurs peuvent effectuer une analyse des 5 causes profondes afin d'identifier systématiquement les causes sous-jacentes des problèmes opérationnels. Cette approche structurée améliore vos rapports d'incidents grâce à des informations plus approfondies et à des mesures correctives exploitables.

Cette fonctionnalité utilise Amazon Q pour proposer un chat conversationnel. L'utilisateur connecté au AWS Management Console doit disposer des autorisations suivantes :

{ "Sid" : "AmazonQAccess", "Effect" : "Allow", "Action" : [ "q:StartConversation", "q:SendMessage", "q:GetConversation", "q:ListConversations", "q:UpdateConversation", "q:DeleteConversation", "q:PassRequest" ], "Resource" : "*" }

Vous pouvez ajouter ces autorisations directement, ou en associant la politique AIOpsOperatorAccessgérée AIOpsConsoleAdminPolicyou la politique gérée à l'utilisateur ou au rôle.

Qu'est-ce que l'analyse des 5 pourquoi ?

The 5 Whys est une technique d'analyse des causes fondamentales qui demande « pourquoi » à plusieurs reprises afin de passer des symptômes des incidents aux causes fondamentales. Chaque réponse devient la base de la question suivante, créant ainsi une chaîne logique qui révèle la véritable cause plutôt que de simples symptômes superficiels.

Lors de la génération des rapports d'incident, les CloudWatch enquêtes utilisent cette méthode pour analyser les résultats des enquêtes et fournir une analyse structurée des causes profondes qui va au-delà des défaillances techniques immédiates pour identifier les problèmes de processus, de configuration ou systémiques.

Avantages du signalement des incidents

L'inclusion de l'analyse des 5 raisons dans les rapports d'incidents présente plusieurs avantages :

  • Identification complète des causes profondes : va au-delà des causes techniques immédiates pour identifier les problèmes sous-jacents au processus ou au système

  • Plans de remédiation exploitables : fournit des actions spécifiques et ciblées pour empêcher la récurrence plutôt que des correctifs temporaires

  • Apprentissage organisationnel - Documente la chaîne causale complète pour référence future et partage des connaissances en équipe

  • Analyse structurée - Garantit une investigation systématique plutôt que la résolution de problèmes ad hoc

Exemples de scénarios dans les rapports d'incidents

Incident de connexion à la base de

Incident initial : 500 erreurs généralisées dans une application de commerce électronique

  1. Pourquoi 1 : Pourquoi les utilisateurs reçoivent-ils 500 erreurs ? L'application ne peut pas se connecter à la base de données principale.

  2. Pourquoi 2 : Pourquoi l'application ne parvient-elle pas à se connecter à la base de données ? L'instance de base de données n'avait plus de connexions disponibles.

  3. Pourquoi 3 : Pourquoi la base de données n'a-t-elle plus de connexions ? Une tâche de traitement par lots a ouvert de nombreuses connexions sans les fermer correctement.

  4. Pourquoi 4 : Pourquoi le traitement par lots n'a-t-il pas correctement fermé les connexions ? La gestion des erreurs de la tâche n'inclut pas le nettoyage de la connexion dans les scénarios d'échec.

  5. Pourquoi 5 : Pourquoi la gestion appropriée des erreurs n'a-t-elle pas été mise en œuvre ? Le processus de révision du code n'inclut pas de vérifications spécifiques pour les modèles de gestion des ressources.

Cause première : normes de révision du code inadéquates pour la gestion des ressources

Actions recommandées : mise à jour de la liste de vérification du code, mise en œuvre de la surveillance du regroupement des connexions, ajout d'une détection automatique des fuites de ressources

Incident de dégradation des performances

Incident initial : les temps de réponse des API sont passés de 200 ms à 5 000 ms lors d'un pic de trafic

  1. Pourquoi 1 : Pourquoi les temps de réponse ont-ils augmenté ? L'utilisation du processeur a atteint 100 % sur toutes les instances de l'application.

  2. Pourquoi 2 : Pourquoi l'autoscaling n'a-t-il pas ajouté d'autres instances ? La mise à l'échelle automatique a été déclenchée, mais les nouvelles instances ont échoué aux tests de santé.

  3. Pourquoi 3 : Pourquoi les nouvelles instances ont-elles échoué aux tests de santé ? Le processus de démarrage de l'application prend 8 minutes, soit plus que le délai d'expiration du bilan de santé.

  4. Pourquoi 4 : Pourquoi le démarrage prend-il autant de temps ? L'application télécharge de gros fichiers de configuration depuis S3 à chaque démarrage.

  5. Pourquoi 5 : Pourquoi ce délai de démarrage n'a-t-il pas été pris en compte dans la configuration du dimensionnement automatique ? Les tests de performance ont été effectués avec des instances préchauffées, et non avec des démarrages à froid.

Cause première : la méthodologie de test des performances ne reflète pas les scénarios de mise à l'échelle automatique de la production

Actions recommandées : inclure des tests de démarrage à froid, optimiser le démarrage des applications, ajuster les délais de vérification de l'état, implémenter la mise en cache de la configuration

Incident complexe avec analyse des succursales

Incident initial : les clients OpenSearch sans serveur ont connu une baisse de disponibilité de 48,3 % pendant 11 heures

Chaîne d'analyse principale :

  1. Pourquoi 1 : Pourquoi les clients ont-ils constaté une dégradation du service ? La disponibilité du service est tombée à 48,3 % en raison d'un dimensionnement incorrect de l'ingester.

  2. Pourquoi 2 : Pourquoi le dimensionnement de l'ingester a-t-il été incorrect ? CortexOperator a réduit le nombre d'investisseurs de 223 à 174 en raison d'une erreur de calcul du solde AZ.

  3. Pourquoi 3 : Pourquoi avez-vous CortexOperator mal calculé le solde AZ ? Le code n'a pas pu traiter les nouveaux formats d'étiquette Kubernetes après la mise à niveau de la version 1.17.

  4. Pourquoi 4 (Branche A - Technique) : Pourquoi le code ne traitait-il pas les nouveaux formats d'étiquettes ? Le code attendait « failure-domain.beta.kubernetes ». io/zone' labels but Kubernetes 1.17 changed to 'topology.kubernetes.io/zone'.

  5. Pourquoi 5 (Branche A) : Pourquoi la rétrocompatibilité n'a-t-elle pas été implémentée ? Le changement de format d'étiquette n'a pas été documenté dans les notes de mise à niveau examinées lors de la planification du déploiement.

Branche B - Analyse des processus :

  1. Pourquoi 4 (Branche B - Processus) : Pourquoi cela n'a-t-il pas été détecté lors des tests ? Les tests d'intégration ont utilisé des clusters préconfigurés avec d'anciens formats d'étiquette.

  2. Pourquoi 5 (Branche B) : Pourquoi les tests n'ont-ils pas inclus la validation du format des étiquettes ? La configuration de l'environnement de test ne reflétait pas la séquence de mise à niveau de la version de production de Kubernetes.

Causes fondamentales identifiées :

  • Technique : rétrocompatibilité manquante pour les modifications du format d'étiquette Kubernetes

  • Processus : la méthodologie de test ne valide pas les impacts de la mise à niveau des versions

Plan de correction intégré : implémentez une logique de détection du format d'étiquette, améliorez les procédures de test de mise à niveau, ajoutez une validation automatique de compatibilité et établissez un processus d'évaluation de l'impact des modifications de version.

Utilisation du flux de travail guidé des 5 pourquoi

CloudWatch investigations propose un flux de travail d'analyse guidé des 5 raisons pour vous aider à corriger les informations manquantes et à renforcer vos rapports d'incidents. Cette fonctionnalité apparaît sous forme de flux de travail suggéré lorsque le système identifie des opportunités pour améliorer l'analyse des causes profondes.

Expérience d'analyse interactive

L'analyse des 5 raisons des CloudWatch enquêtes utilise une approche interactive basée sur le chat qui vous guide tout au long du processus d'enquête. Cette méthode conversationnelle permet de garantir une analyse complète tout en maintenant le flux logique entre les questions.

Principales caractéristiques de l'expérience interactive :

  • Initialisation basée sur les faits : le système présente les faits pertinents issus de votre enquête dès le départ, en les utilisant pour préremplir les réponses évidentes et indiquer clairement les suggestions basées sur des faits par opposition aux suggestions basées sur des inférences

  • Analyse guidée - Pour chaque question « pourquoi », le système suggère des réponses basées sur les faits disponibles, demande un contexte supplémentaire spécifique et vous guide pour prendre en compte les aspects importants avant de poursuivre

  • Gestion des succursales - Lorsque plusieurs facteurs contributifs sont identifiés, le système présente clairement les options qui s'offrent aux succursales, explique les relations entre les succursales et aide à hiérarchiser les enquêtes parallèles

  • Validation progressive - Pour chaque réponse, le système reformule les réponses pour plus de clarté, cherche à obtenir une confirmation, met en évidence les informations clés et relie les résultats à un contexte plus large

Cette approche garantit que vous collectez toutes les informations pertinentes tout en vous concentrant sur les relations causales les plus critiques.

Accès au flux de travail guidé :

  1. Lors de la génération du rapport d'incident, consultez la section Faits nécessitant une attention particulière dans le panneau de droite.

  2. Recherchez la suggestion d'analyse guidée des 5 raisons sous Flux de travail suggéré.

  3. Choisissez Guidez-moi pour démarrer le processus interactif des 5 pourquoi.

  4. Suivez les instructions pour répondre systématiquement à chaque question « pourquoi », en établissant une chaîne causale complète allant des symptômes à la cause première.

Le flux de travail guidé vous permet de recueillir des informations complètes sur les causes profondes en vous expliquant chaque étape de la méthodologie des 5 pourquoi. Les résultats de l'analyse sont automatiquement intégrés dans votre rapport d'incident, fournissant une documentation structurée pour les examens post-incident et l'apprentissage organisationnel.

Vous pouvez également demander une analyse des 5 pourquoi via l'interface de chat en posant des questions telles que « Effectuez une analyse des 5 pourquoi de cet incident » ou « Quelle est la cause première à l'aide de la méthodologie des 5 pourquoi ? »

Gestion d'incidents complexes aux causes multiples

Certains incidents impliquent de multiples facteurs contributifs qui nécessitent des voies d'analyse parallèles. CloudWatch les enquêtes soutiennent l'analyse des succursales afin de garantir que toutes les causes importantes sont identifiées et traitées.

Lorsque l'analyse des branches est nécessaire :

  • Plusieurs défaillances indépendantes se sont produites simultanément

  • Les différents composants du système ont contribué au même impact sur le client

  • Les défaillances techniques et de processus ont joué un rôle important

  • Les défaillances en cascade ont créé de multiples chaînes causales

Processus d'analyse des succursales :

  1. Identification des branches - Le système identifie les points où plusieurs causes convergent ou divergent

  2. Enquête parallèle - Chaque branche est analysée à l'aide de la méthodologie complète des 5 pourquoi

  3. Cartographie des connexions - Les relations entre les branches sont documentées pour montrer comment elles interagissent

  4. Résolution intégrée : les plans de remédiation abordent toutes les causes profondes identifiées et leurs interactions

Cette approche globale garantit que les incidents complexes font l'objet d'une analyse approfondie et que tous les facteurs contributifs sont pris en compte dans le plan de remédiation final.

Les meilleures pratiques pour une analyse efficace des 5 raisons

Pour optimiser l'efficacité de l'analyse des 5 raisons dans vos rapports d'incidents, suivez ces meilleures pratiques issues de l'expérience opérationnelle :

Directives pour la formulation des questions

  • Commencez par l'impact sur le client - Commencez chaque analyse par le problème rencontré par le client afin de rester concentré sur l'impact commercial

  • Améliorez progressivement la profondeur technique : passez de l'impact commercial aux détails techniques au fur et à mesure que vous répondez aux questions

  • Maintenir la continuité logique - Assurez-vous que chaque réponse mène naturellement à la question suivante sans lacunes logiques

  • Incluez des preuves à l'appui : faites référence à des indicateurs, à des journaux ou à des événements chronologiques spécifiques pour valider chaque réponse

Validation des analyses

Validez votre analyse des 5 pourquoi à l'aide de ces critères :

  • Flux logique : progression claire des symptômes à la cause première, sans aucune étape manquante

  • Précision technique : terminologie correcte, descriptions précises du comportement du système et interactions valides entre les composants

  • Exhaustivité - L'analyse explique tous les symptômes observés et identifie une cause fondamentale qui, si elle est traitée, empêcherait la récurrence

  • Actionnabilité - La cause première identifiée conduit à des mesures correctives spécifiques et réalisables

Les pièges courants à éviter

  • S'arrêter aux symptômes : ne concluez pas l'analyse à la première défaillance technique ; continuez jusqu'à ce que vous trouviez les causes systémiques ou liées au processus

  • Analyse axée sur le blâme : concentrez-vous sur les défaillances du système et des processus plutôt que sur les actions individuelles

  • Pensée à voie unique - Tenez compte de multiples facteurs contributifs et utilisez l'analyse des branches le cas échéant

  • Preuves insuffisantes - Assurez-vous que chaque réponse est étayée par des données concrètes issues de votre enquête

Intégration aux sections des rapports d'incidents

L'analyse des 5 raisons s'intègre aux autres sections de votre rapport d'incident pour fournir une documentation complète :

  • Corrélation chronologique - Chaque question « pourquoi » peut faire référence à des événements chronologiques spécifiques, fournissant un contexte temporel pour les relations causales

  • Validation des métriques - Les réponses sont étayées par des métriques et des graphiques illustrant les comportements techniques décrits

  • Alignement de l'évaluation d'impact - Le premier « pourquoi » est directement lié aux indicateurs d'impact client documentés dans la section d'évaluation d'impact

  • Fondement des leçons apprises - Les causes profondes identifiées grâce à l'analyse des 5 raisons éclairent directement les sections sur les leçons apprises et les mesures correctives

Cette intégration garantit la cohérence de votre rapport d'incident et fournit aux parties prenantes un récit complet et cohérent, des premiers symptômes à la cause première, en passant par les plans de résolution.