View a markdown version of this page

Utilisation de l'analyse des 5 pourquoi 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 pourquoi dans les rapports d'incidents

Lors de la génération de rapports d'incidents, les CloudWatch enquêteurs peuvent effectuer une analyse des causes profondes des 5 pourquoi 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 fournir un chat conversationnel. L'utilisateur connecté au Console de gestion AWS 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 AIOpsConsoleAdminPolicy ou la politique AIOpsOperatorAccess gérée à l'utilisateur ou au rôle.

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

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

Lors de la génération des rapports d'incidents, 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 de processus ou de système sous-jacents

  • Plans de remédiation exploitables - Fournit des actions spécifiques et ciblées pour éviter 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 ponctuelle de problèmes

Exemples de scénarios dans les rapports d'incidents

Incident d'échec de connexion à la

Incident initial : E-commerce l'application rencontre 500 erreurs généralisées

  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 une gestion des erreurs appropriée 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 principale : normes de révision de code inadéquates pour la gestion des ressources

Actions recommandées : mettre à jour la liste de contrôle de révision du code, mettre en œuvre la surveillance du pool de connexions, ajouter une détection automatique des fuites de ressources

Incident de dégradation des performances

Incident initial : les temps de réponse de l'API sont passés de 200 ms à 5 000 ms en cas de 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 la mise à l'échelle automatique n'a-t-elle pas ajouté d'autres instances ? La mise à l'échelle automatique a été déclenchée mais les nouvelles instances ont échoué aux contrôles de santé.

  3. Pourquoi 3 : Pourquoi les nouvelles instances ont-elles échoué aux bilans 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 si longtemps ? L'application télécharge des fichiers de configuration volumineux 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 de la mise à l'échelle automatique ? Les tests de performance ont été effectués sur des instances préchauffées, et non sur des démarrages à froid.

Cause principale : la méthodologie des tests de performance 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 de l'application, ajuster les délais de vérification de l'état, implémenter la mise en cache de configuration

Incident complexe avec analyse des succursales

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

Chaîne d'analyse principale :

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

  2. Pourquoi 2 : Pourquoi la mise à l'échelle de l'ingestion était-elle incorrecte ? CortexOperator réduction du nombre d'ingestions de 223 à 174 en raison d'une erreur de calcul du solde AZ.

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

  4. Pourquoi 4 (Branche A - Technique) : Pourquoi le code ne gère-t-il pas les nouveaux formats d'étiquettes ? Le code s'attendait à « failure-domain.beta.kubernetes ». io/zone' labels mais Kubernetes 1.17 a été remplacé par « 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'étiquettes.

  2. Pourquoi 5 (branche B) : Pourquoi les tests n'ont-ils pas inclus la validation du format d'étiquette ? 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 profondes 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 de compatibilité automatisée et établissez un processus d'évaluation de l'impact des changements de version.

Utilisation du flux de travail guidé en 5 raisons

CloudWatch investigations propose un flux de travail d'analyse guidé en 5 raisons pour vous aider à corriger les faits manquants et à renforcer vos rapports d'incidents. Cette fonctionnalité apparaît sous la forme d'un 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 pourquoi 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 un flux logique entre les questions.

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

  • Fact-based initialisation - Le système présente les faits pertinents de votre enquête dès le départ, en les utilisant pour pré-remplir les réponses évidentes et en indiquant clairement les suggestions basées sur les faits par rapport aux suggestions basées sur des inférences

  • Sondage guidé - Pour chaque question « pourquoi », le système propose des réponses en fonction des 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 des succursales, explique les relations entre les succursales et permet de 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 à les confirmer, met en évidence les informations clés et relie les résultats à un contexte plus large

Cette approche garantit que vous capturez 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 pourquoi 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, 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 à 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 discussion en posant des questions telles que « Effectuer une analyse des 5 pourquoi pour cet incident » ou « Quelle en est la cause première en utilisant la méthodologie des 5 pourquoi ? »

Gestion d'incidents complexes aux causes multiples

Certains incidents impliquent de multiples facteurs qui nécessitent des voies d'analyse parallèles. CloudWatch les enquêtes soutiennent l'analyse des branches afin de s'assurer 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

  • Différents composants du système ont contribué au même impact sur les clients

  • 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 branches :

  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 traitent de toutes les causes profondes identifiées et de 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.

Meilleures pratiques pour une analyse efficace des 5 pourquoi

Pour optimiser l'efficacité de l'analyse des 5 pourquoi dans vos rapports d'incidents, suivez ces bonnes 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 continuer à vous concentrer sur l'impact commercial

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

  • Maintenez une 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 mesures, à des journaux ou à des événements chronologiques spécifiques pour valider chaque réponse

Validation des analyses

Validez votre analyse des 5 pourquoi en utilisant 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 permet d'identifier une cause fondamentale qui, si elle était traitée, empêcherait leur récurrence

  • Possibilité d'action  : la cause première identifiée conduit à des mesures correctives spécifiques et réalisables

Pièges courants à éviter

  • Arrêt en cas de symptômes - Ne terminez pas l'analyse à la première défaillance technique ; continuez jusqu'à ce que vous obteniez des causes systémiques ou liées au processus

  • Blame-focused analyse - Concentrez-vous sur les défaillances du système et des processus plutôt que sur les actions individuelles

  • Single-path réflexion - 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 à d'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 qui illustrent les comportements techniques décrits

  • Harmonisation de l'évaluation d'impact  : le premier « pourquoi » est directement lié aux indicateurs d'impact sur les clients documentés dans la section sur l'é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 symptômes initiaux aux plans de remédiation en passant par la cause première.