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.
# Générez des rapports d'incidents
Les rapports d'incident vous aident à rédiger plus rapidement et plus facilement un rapport sur votre enquête sur un incident. Vous pouvez utiliser ce rapport pour fournir des détails à la direction ou pour aider votre équipe à tirer les leçons de l'incident et à prendre des mesures pour empêcher que de tels événements ne se reproduisent à l'avenir. La structure du rapport est basée sur les normes du secteur pour ces types de rapports et peut être copiée dans d'autres référentiels pour une conservation à long terme.
Lorsque vous utilisez le AWS Management Console pour créer une *investigation group* ressource dans le cadre d' CloudWatch enquêtes, un rôle IAM est créé pour le groupe afin de lui donner accès aux ressources pendant l'enquête. La génération de rapports d'incidents liés aux CloudWatch enquêtes nécessite l'octroi d'autorisations supplémentaires à votre groupe d'enquête. La nouvelle politique gérée `AIOpsAssistantIncidentReportPolicy` fournit les autorisations requises et est automatiquement ajoutée aux groupes d'investigation créés AWS Management Console après le 10 octobre 2025. Pour de plus amples informations, veuillez consulter [AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy).
**Note**
Si vous utilisez le CDK ou le SDK, vous devez ajouter explicitement le rôle du groupe d'investigation et spécifier la politique du rôle ou les autorisations intégrées équivalentes sur le rôle. Pour plus de détails sur les autorisations, voir [Sécurité dans les CloudWatch enquêtes](Investigations-Security.md)
Ces rapports présentent les résultats des enquêtes, les causes profondes, les événements chronologiques et les mesures correctives recommandées dans un format structuré qui peut être facilement partagé avec les parties prenantes et utilisé pour l'apprentissage organisationnel.
La génération de rapports d'incident est incluse sans frais supplémentaires pour tous les utilisateurs CloudWatch des enquêtes et s'intègre parfaitement à votre flux de travail d'investigation.
**Comment fonctionnent les rapports d'incidents**
1. Menez une enquête sur votre incident.
1. Acceptez au moins une hypothèse. Chaque hypothèse que vous acceptez est prise en compte dans le rapport. L'hypothèse n'a pas besoin d'être précise à 100 %.
1. Choisissez **Rapport d'incident**. Au cours de l'enquête, l'IA a analysé les données collectées pour votre enquête et les faits dérivés. Les faits sont des informations atomiques sur votre incident qui constituent la base de la génération du rapport. L'extraction des faits peut prendre quelques minutes.
1. Lorsque l'extraction des faits est terminée, vous pouvez consulter les informations disponibles dans les domaines suivants :
1. **Vue d'ensemble de l'incident** : aperçu général de l'incident, notamment de sa gravité, de sa durée et de son hypothèse opérationnelle.
1. **Évaluation de l'impact** — Mesures et analyses liées à l'impact de l'incident sur les clients, la fonction de service et les opérations commerciales.
1. **Détection et réponse** : mesures et analyses relatives à la manière et au moment où l'incident a été détecté, ainsi qu'à la manière dont vous y avez répondu.
1. **Analyse des causes profondes** — Analyse détaillée des causes sous-jacentes basée sur des hypothèses d'investigation.
1. **Atténuation et résolution** — Mesures et analyses liées aux étapes d'atténuation et aux mesures de résolution, ainsi que la mesure du temps nécessaire à l'atténuation et à la résolution des incidents.
1. **Apprentissage et prochaines étapes** : liste d'actions recommandées à prendre en compte par votre équipe, générée automatiquement à partir des résultats de l'enquête. Ces recommandations peuvent inclure des mesures préventives contre des incidents similaires, ainsi que des suggestions d'amélioration de vos processus de surveillance et de réponse.
1. Après avoir examiné les faits, choisissez **Générer un rapport** pour créer une analyse complète de l'incident. Bien que les faits sélectionnés constituent des points de référence essentiels, le rapport s'appuie sur toutes les informations disponibles recueillies au cours de l'enquête. Ce processus peut prendre quelques minutes.
1. Après avoir généré le rapport, vous pouvez soit :
+ Utilisez le rapport tel quel :
+ Copiez-le pour le modifier dans votre éditeur externe si nécessaire
+ Sauvegardez-le pour référence ultérieure
+ Améliorez le rapport en ajoutant des données supplémentaires :
+ Choisissez **Ajouter des faits** (méthode recommandée) pour saisir du contenu textuel supplémentaire, tel que des tickets d'incident ou des récits personnalisés. L'IA analysera ce contenu pour compléter les faits existants ou en déduire de nouveaux.
+ Modifiez les faits directement (utilisez-les avec parcimonie) - Les faits modifiés manuellement peuvent créer des incohérences par rapport au calendrier de l'enquête. Cela ne doit être utilisé qu'en dernier recours lorsque **Add facts** n'atteint pas le résultat souhaité.
+ Choisissez **Régénérer le rapport** pour produire un nouveau rapport à l'aide des informations mises à jour.
**Topics**
+ [Comprendre les faits dérivés de l'IA dans les rapports d'incidents](Investigations-IncidentReports-ai-facts.md)
+ [Terminologie des rapports d'incidents](Investigations-IncidentReports-terms.md)
+ [Générer un rapport à partir d'une enquête](Investigations-IncidentReports-Generate.md)
+ [Utilisation de l'analyse des 5 raisons dans les rapports d'incidents](incident-report-5whys.md)
# Comprendre les faits dérivés de l'IA dans les rapports d'incidents
Les faits dérivés de l'IA constituent la base des CloudWatch enquêtes et des rapports d'incidents, représentant des informations que le système d'IA considère comme objectivement vraies ou hautement probables sur la base d'une analyse complète de votre environnement. AWS Ces faits apparaissent grâce à un processus sophistiqué qui combine la reconnaissance de modèles par apprentissage automatique à des méthodes de vérification systématiques, créant ainsi un cadre robuste pour l'analyse des incidents qui maintient la rigueur opérationnelle requise pour les environnements de production.
Comprendre comment les faits dérivés de l'IA sont développés vous permet d'évaluer leur fiabilité et de prendre des décisions éclairées lors de la réponse aux incidents. Le processus représente une approche hybride dans laquelle l'intelligence artificielle accroît l'expertise humaine plutôt que de la remplacer, garantissant ainsi que les informations générées sont à la fois complètes et fiables.
## Le processus de développement des faits dérivés de l'IA
Le passage des données de télémétrie brutes aux faits exploitables dérivés de l'IA commence par l'observation de modèles, au cours de laquelle l'IA d' CloudWatch investigation analyse de grandes quantités de données AWS télémétriques à l'aide d'algorithmes d'apprentissage automatique sophistiqués. L'IA examine simultanément vos CloudWatch métriques, vos journaux et vos traces dans plusieurs dimensions, afin d'identifier les modèles et les relations récurrents qui peuvent ne pas être immédiatement apparents pour les opérateurs humains. L'analyse inclut des modèles temporels qui révèlent le moment où les incidents se produisent généralement et leurs caractéristiques de durée, des corrélations entre les services qui montrent comment les différents AWS services interagissent lors de scénarios de défaillance, des anomalies métriques qui précèdent ou accompagnent les incidents, et des séquences d'événements de journal indiquant des modes de défaillance spécifiques.
Réfléchissez, par exemple, à la façon dont l'IA pourrait observer que, dans votre environnement, l'utilisation du processeur des instances Amazon EC2 atteint régulièrement plus de 90 % environ 15 minutes avant que les temps de réponse des applications ne dépassent les seuils acceptables. Cette relation temporelle, lorsqu'elle est observée à travers de multiples incidents, devient un modèle significatif qui mérite d'être étudié plus avant. L'IA ne se contente pas de noter la corrélation ; elle mesure la signification statistique de la relation et prend en compte divers facteurs de confusion susceptibles d'influencer le modèle.
À partir de ces modèles observés, l'IA passe à la génération d'hypothèses, formulant des explications potentielles pour les relations qu'elle a découvertes. Ce processus consiste à créer plusieurs hypothèses concurrentes et à les classer par probabilité en fonction de la solidité des preuves à l'appui. Lorsque l'IA constate que les pics du processeur précèdent la dégradation du temps de réponse, elle peut générer plusieurs hypothèses : épuisement des ressources dû à une capacité de calcul insuffisante, fuites de mémoire entraînant une augmentation de la charge du processeur ou algorithmes inefficaces déclenchés par des modèles d'entrée spécifiques. Chaque hypothèse reçoit un niveau de confiance préliminaire basé sur sa capacité à expliquer les données observées et à s'aligner sur les comportements de AWS service connus.
La vérification et la validation humaines de ces hypothèses garantissent que ces informations générées par l'IA répondent aux normes opérationnelles avant de devenir des faits dans vos rapports d'incidents. Ce processus implique de corréler les modèles dérivés de l'IA avec les modèles de comportement de AWS service établis, de vérifier la cohérence avec les meilleures pratiques du secteur en matière de réponse aux incidents et de les valider par rapport aux données historiques sur les incidents provenant d'environnements similaires. L'IA doit démontrer que ses résultats sont reproductibles à travers différentes méthodes d'analyse et périodes, répondre aux exigences de signification statistique pour la prise de décision opérationnelle, s'aligner sur des observations empiriques du comportement des AWS services et fournir des informations exploitables pour la résolution ou la prévention des incidents.
Tout au long de ce processus, l'IA est confrontée à plusieurs défis inhérents que vous devez comprendre lorsque vous interprétez des faits dérivés de l'IA. La distinction entre corrélation et causalité demeure un défi fondamental ; si l'IA peut identifier de fortes corrélations entre les pics de trafic réseau et la survenue d'un incident, l'établissement d'un lien de causalité direct nécessite des recherches supplémentaires et une expertise du domaine. Les variables cachées qui existent en dehors du champ de la AWS télémétrie, telles que les dépendances de services tiers ou les problèmes liés aux fournisseurs de réseaux externes, peuvent influencer les incidents sans être prises en compte dans l'analyse de l'IA. La qualité des faits dérivés de l'IA dépend entièrement de l'exhaustivité et de l'exactitude des CloudWatch données sous-jacentes, ce qui rend une couverture de surveillance complète essentielle pour obtenir des informations fiables.
Les nouveaux modèles d'incidents constituent un autre défi, car ils ne sont pas présents dans les données d'entraînement de l'IA et ont AIs souvent du mal à interpréter des modes de défaillance inconnus. Cette limite souligne l'importance de l'expertise humaine pour interpréter les faits dérivés de l'IA et les compléter par des connaissances du domaine et une compréhension contextuelle.
## Appliquer les faits dérivés de l'IA à la réponse aux incidents
L'IA excelle dans l'identification de modèles dans de grands ensembles de données qu'il serait difficile d'analyser manuellement pour les humains, fournissant ainsi des informations susceptibles d'accélérer considérablement le diagnostic et la résolution des incidents. L'IA fonctionne mieux lorsqu'elle est associée à une expertise humaine capable de fournir un contexte, de valider des conclusions et d'identifier les facteurs susceptibles de ne pas être capturés dans les données de télémétrie.
L'approche la plus efficace consiste à traiter les faits dérivés de l'IA comme des points de départ très éclairés pour une enquête plutôt que comme des conclusions définitives. Lorsque l'IA identifie un fait tel que « l'épuisement du pool de connexions à la base de données a précédé l'incident de 8 minutes », cela fournit une piste précieuse qui peut être rapidement vérifiée grâce à une analyse ciblée des métriques de la base de données et des journaux des applications. Cela vous donne un délai précis et la cause première potentielle à étudier, ce qui réduit considérablement le temps nécessaire pour identifier le problème par rapport à une recherche manuelle dans toutes les télémesures disponibles.
La qualité des données joue un rôle crucial dans la fiabilité des faits dérivés de l'IA. Une couverture CloudWatch de surveillance complète permet à l'IA d'accéder à des informations complètes et précises à des fins d'analyse. Les lacunes en matière de surveillance peuvent conduire à des informations incomplètes ou trompeuses, car l'IA ne peut fonctionner qu'avec les données dont elle dispose. Organisations qui utilisent des pratiques d'observabilité rigoureuses, notamment la collecte de métriques détaillées, la journalisation complète et le suivi distribué, sont plus susceptibles de présenter des informations précises et exploitables dérivées de l'IA dans leurs rapports d'incidents.
# Terminologie des rapports d'incidents
Les termes suivants sont utilisés dans les rapports d'incidents relatifs aux CloudWatch enquêtes :
Faits dérivés de l'IA
Une information ou une observation que le système d'IA considère comme objectivement vraie ou hautement probable sur la base des données disponibles, de la télémétrie, des journaux et des modèles historiques au sein des services. AWS Ces faits sont dérivés d'analyses algorithmiques et de modèles d'apprentissage automatique, et bien qu'ils soient considérés comme fiables par le système, ils doivent être soumis à une vérification humaine, en particulier dans les contextes décisionnels critiques. Les faits dérivés de l'IA peuvent inclure des corrélations entre des événements, des détections d'anomalies ou des inférences sur le comportement du système qui peuvent ne pas être immédiatement apparentes pour les opérateurs humains.
Actions correctives
Mesures spécifiques et réalisables recommandées par les CloudWatch enquêtes pour s'attaquer à la cause première d'un incident et empêcher qu'il ne se reproduise, sur la base des AWS meilleures pratiques et du contexte spécifique des ressources concernées.
Catégories de faits
Regroupements structurés d'informations relatives aux incidents, telles que les mesures d'impact, les détails de détection et les mesures d'atténuation, utilisés pour organiser les données en vue de la génération de rapports.
Évaluation d'impact
Évaluation quantitative et qualitative des effets d'un incident sur les performances du système, l'expérience utilisateur et les opérations commerciales, dérivée de CloudWatch mesures et d'autres données de AWS service ajoutées à l'enquête.
Génération de rapports d'incidents
Processus automatisé qui crée une documentation complète d'un incident opérationnel, y compris son calendrier, son impact, sa cause première et les étapes de résolution, sur la base des données collectées lors d'une enquête d' CloudWatch investigation.
Fil d'enquête
Affichage chronologique des observations acceptées, des hypothèses et des notes ajoutées par les utilisateurs dans le cadre d'une CloudWatch enquête, qui constitue le principal enregistrement des progrès et des conclusions de l'enquête.
Leçons apprises
Informations générées automatiquement et opportunités d'amélioration identifiées dans le cadre du processus d'enquête sur les incidents, dans le but d'améliorer la fiabilité du système, l'efficacité opérationnelle et les capacités de réponse aux incidents dans l'ensemble de l'organisation.
Évaluation du rapport
Une évaluation automatisée du rapport d'incident généré, identifiant les éventuelles lacunes dans les données ou les domaines nécessitant des informations supplémentaires pour améliorer l'exhaustivité et la qualité du rapport.
Analyse des causes profondes
Un processus systématique visant à identifier la raison fondamentale d'un problème opérationnel, en tirant parti des CloudWatch enquêtes, des hypothèses basées sur l'IA et des corrélations entre plusieurs services. AWS
onglet Suggestions
Fonctionnalité CloudWatch des enquêtes qui présente des observations et des hypothèses générées par l'IA concernant des causes potentielles ou des problèmes connexes, sur la base de l'analyse de la télémétrie et des journaux du système.
Chronologie des événements
Séquence chronologique des événements importants survenus au cours d'un incident, automatiquement extraite CloudWatch des journaux, des métriques et d'autres données de AWS service afin de fournir une vue d'ensemble claire de la progression de l'incident.
# Générer un rapport à partir d'une enquête
Vous pouvez générer des rapports d'incidents à partir d'enquêtes en cours ou terminées. Les rapports d'incident produits au début d'une enquête peuvent ne pas inclure des faits essentiels tels que les causes profondes et les mesures recommandées. Lorsque l'enquête est active, vous pouvez modifier les informations disponibles pour compléter l'enquête avec des informations supplémentaires. Une fois l'enquête terminée, vous ne pouvez pas modifier ou ajouter des faits à l'enquête.
**Conditions préalables**
Avant de générer un incident, vérifiez que les conditions suivantes sont remplies :
+ Assurez-vous que le groupe d'investigation utilise la clé KMS requise et dispose de politiques IAM appropriées associées à son rôle de déchiffrement des données des services. AWS Si vos AWS ressources sont chiffrées à l'aide de clés KMS gérées par le client, vous devez ajouter des déclarations de politique IAM au rôle du groupe d'investigation afin d'accorder à CloudWatch Investigations les autorisations nécessaires pour déchiffrer ces données et y accéder.
+ Le rôle du groupe d'investigation a reçu les autorisations suivantes :
+ `aiops:GetInvestigation`
+ `aiops:ListInvestigationEvents`
+ `aiops:GetInvestigationEvent`
+ `aiops:PutFact`
+ `aiops:UpdateReport`
+ `aiops:CreateReport`
+ `aiops:GetReport`
+ `aiops:ListFacts`
+ `aiops:GetFact`
+ `aiops:GetFactVersions`
**Note**
Vous pouvez ajouter ces autorisations en tant que politique intégrée au rôle du groupe d'investigation, ou associer une politique d'autorisation supplémentaire au rôle du groupe d'investigation. Pour plus d'informations, voir[Autorisations pour la génération de rapports d'incidents](Investigations-Security.md#Investigations-Security-IAM-IRG).
La nouvelle politique gérée `AIOpsAssistantIncidentReportPolicy` fournit les autorisations requises et est automatiquement ajoutée aux groupes d'investigation créés après le 10 octobre 2025. Pour de plus amples informations, veuillez consulter [AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy).
**Pour générer un rapport d'incident**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le volet de navigation de gauche, sélectionnez **AI Operations**, **Enquêtes**.
1. Choisissez le nom d'une enquête.
1. Sur la page d'investigation, sous **Feed**, acceptez toute hypothèse pertinente supplémentaire et ajoutez des notes supplémentaires à l'enquête.
**Note**
La génération de rapports nécessite une enquête avec au moins une hypothèse acceptée.
1. En haut de la page d'enquête, sélectionnez **Rapport d'incident**. Attendez que les faits pertinents de l'enquête soient collectés et synchronisés.
1. Sur la page **Rapport d'incident**, passez en revue les faits utilisés pour générer le rapport. Les informations sont disponibles dans le volet droit. Naviguez dans l'onglet des catégories de faits à l'aide des flèches gauche et droite, ou agrandissez le volet pour afficher toutes les catégories.
1. Choisissez **Modifier** dans un panneau d'informations pour ajouter ou modifier manuellement les données de cette catégorie.
1. Choisissez **Afficher les détails** sur un panneau d'informations pour voir les preuves à l'appui et l'historique des faits recueillis par l'assistant IA. Vous pouvez également sélectionner **Modifier** dans la fenêtre des détails des faits.
1. Choisissez **Ajouter des faits** si vous souhaitez fournir un contexte supplémentaire à l'enquête, tel que des événements extérieurs ou des circonstances atténuantes.
1. Choisissez **Générer un rapport**.
CloudWatch les enquêtes analyseront les données d'enquête et produiront un rapport structuré. Ce processus peut prendre un certain temps.
1. Passez en revue le rapport généré dans le volet d'aperçu. Le rapport comprendra :
+ Événements chronologiques extraits automatiquement
+ Analyse des causes profondes basée sur des hypothèses acceptées
+ Évaluation d'impact dérivée de la télémétrie des enquêtes
+ Mesures correctives recommandées et leçons apprises conformément aux AWS meilleures pratiques
1. Pour conserver une copie du rapport à un autre emplacement, vous pouvez choisir de copier le texte du rapport et de le coller à l'emplacement de votre choix.
1. Choisissez **Report assessment** pour consulter la liste des lacunes en matière de données dans le rapport. Vous pouvez utiliser ces informations pour collecter des données supplémentaires pour le rapport, puis mettre à jour les faits en conséquence et régénérer le rapport.
# 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 [AIOpsOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsOperatorAccess.html)gérée [AIOpsConsoleAdminPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsConsoleAdminPolicy.html)ou 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.
1. **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.
1. **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.
1. **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.
1. **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.
1. **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é.
1. **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é.
1. **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.
1. **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'une mauvaise mise à l'échelle de l'ingester.
1. **Pourquoi 2 :** Pourquoi le dimensionnement de l'ingester a-t-il été incorrect ? CortexOperator a réduit le nombre d'acheteurs de 223 à 174 en raison d'une erreur de calcul du solde AZ.
1. **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.
1. **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'.
1. **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.
1. **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.
1. Recherchez la suggestion d'**analyse guidée des 5 raisons** sous Flux de travail **suggéré**.
1. Choisissez **Guidez-moi** pour démarrer le processus interactif des 5 pourquoi.
1. 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
1. **Enquête parallèle** - Chaque branche est analysée à l'aide de la méthodologie complète des 5 pourquoi
1. **Cartographie des connexions** - Les relations entre les branches sont documentées pour montrer comment elles interagissent
1. **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.
## 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.