Examen des Cas de Support
Utilisez cette compétence lorsque vous enquêtez sur un incident et que vous devez examiner les cas de support AWS — que ce soit le cas actuel associé à l'incident ou des cas historiques pouvant contenir un contexte pertinent, des symptômes similaires ou des étapes de correction éprouvées.
Quand Utiliser Cette Compétence
- Un incident actuel partage des symptômes avec des problèmes résolus précédemment.
- Vous devez vérifier si un cas de support similaire a été déposé au cours des 24 derniers mois.
- Vous souhaitez corréler l'incident actuel avec des événements de service AWS connus.
- Vous devez récupérer les communications et les détails de résolution d'un cas antérieur.
- Vous souhaitez identifier des schémas récurrents sur plusieurs cas de support.
Prérequis
- Le compte AWS doit avoir un plan Business Support+, Enterprise Support ou Unified Operations (requis pour l'API AWS Support).
- L'agent doit avoir les autorisations pour appeler les actions
support:DescribeCasesetsupport:DescribeCommunicationsdans le compte cible. - Les données des cas de support sont disponibles pendant 24 mois après leur création. Les cas de plus de 24 mois ne peuvent pas être récupérés via l'API.
Étape 1 : Identifier le Contexte de l'Incident Actuel
Avant de rechercher des cas de support, rassemblez les informations clés sur l'incident actuel :
- Services AWS affectés (par exemple, EC2, RDS, Lambda, ELB).
- Messages ou codes d'erreur observés dans les journaux ou les alarmes.
- Période de l'incident (heure de début, durée).
- Ressources affectées (ID d'instance, ARN, noms de points de terminaison).
- Symptômes (pics de latence, erreurs 5xx, délais d'attente de connexion, limitation).
Utilisez ces détails comme critères de recherche lors du filtrage des cas de support.
Étape 2 : Rechercher des Cas de Support Connexes
Utilisez l'API AWS Support pour récupérer les cas pouvant être pertinents.
Récupérer tous les cas récents (ouverts et résolus)
aws support describe-cases \
--include-resolved-cases \
--include-communications \
--after-time "<ISO-8601-start>" \
--before-time "<ISO-8601-end>" \
--language "en"
Filtrer par ID de cas spécifiques (si connu)
aws support describe-cases \
--case-id-list "case-123456789010-muen-2024" \
--include-communications
Stratégies de filtrage clés
| Stratégie | Comment l'appliquer |
|---|---|
| Par fenêtre de temps | Utilisez --after-time et --before-time pour limiter les cas à la période pertinente (par exemple, les 30 derniers jours, ou autour d'une date d'incident précédente), car les cas récents sont plus susceptibles de refléter l'état actuel de l'infrastructure. |
| Par service | Examinez le champ serviceCode dans les cas retournés pour correspondre au service affecté (par exemple, amazon-elastic-compute-cloud, amazon-rds), car le même service présente souvent des schémas de défaillance récurrents. |
| Par sévérité | Vérifiez le champ severityCode — concentrez-vous sur les cas urgent et critical pour les incidents majeurs, car les cas de sévérité plus élevée ont tendance à contenir une analyse des causes racines plus détaillée de la part du support AWS. |
| Par statut | Utilisez --include-resolved-cases pour inclure les cas fermés, car les cas résolus contiennent la cause racine et les étapes de correction qui sont les plus utiles pour corréler avec l'incident actuel. |
| Par mots-clés du sujet | Analysez le champ subject des cas retournés pour trouver des mots-clés correspondant aux symptômes de l'incident actuel, car des symptômes similaires partagent souvent des causes sous-jacentes communes. |
Étape 3 : Examiner les Communications du Cas
La réponse de describe-cases avec includeCommunications: true renvoie les communications les plus récentes pour chaque cas dans le champ recentCommunications (jusqu'à 5 messages). Étant donné que l'analyse des causes racines et les étapes de résolution se trouvent généralement dans les derniers messages d'un cas résolu, cela est généralement suffisant.
Si le champ recentCommunications inclut un nextToken, le cas contient des messages plus anciens supplémentaires. Ne paginez avec describe-communications que si les messages récents ne contiennent pas de cause racine ou de résolution claire — par exemple, si les derniers messages sont des questions de suivi plutôt qu'une réponse finale.
aws support describe-communications \
--case-id "case-123456789010-muen-2024" \
--max-results 10 \
--next-token "<nextToken-from-recentCommunications>"
Lors de l'examen des communications, recherchez :
- Déclarations de cause racine — Les ingénieurs du support AWS résument souvent la cause racine dans leur réponse finale.
- Étapes de correction — Actions spécifiques entreprises pour résoudre le problème (par exemple, "augmentation de max_connections", "application d'une règle de groupe de sécurité", "augmentation du type d'instance").
- Recommandations de configuration — Bonnes pratiques ou suggestions d'optimisation fournies par AWS.
- Notes d'escalade — Si le cas a été escaladé, recherchez une analyse technique plus approfondie de la part d'équipes spécialisées.
Étape 4 : Corréler les Résultats avec l'Incident Actuel
Après avoir examiné les cas pertinents, corrélez les résultats :
Liste de vérification de correspondance de schémas
- Les cas passés partagent-ils le même service et le même type de ressource affectés ?
- Les messages ou codes d'erreur sont-ils identiques ou similaires ?
- Les incidents passés se sont-ils produits à une heure ou un jour de la semaine similaire (indiquant des schémas de charge) ?
- La cause racine était-elle un problème de configuration qui pourrait encore être présent ?
- La résolution était-elle une solution de contournement temporaire qui a depuis expiré ou a été annulée ?
- AWS a-t-il identifié un problème côté service qui pourrait se reproduire ?
Notation de la pertinence
Évaluez chaque cas historique pour sa pertinence par rapport à l'incident actuel :
| Score | Critères |
|---|---|
| Élevé | Même service, même erreur, même type de ressource, période similaire |
| Moyen | Même service, erreur différente mais symptômes connexes |
| Faible | Service différent mais schéma architectural ou mode de défaillance similaire |
Étape 5 : Résumer les Résultats
Fournissez un résumé structuré incluant :
- Nombre de cas connexes trouvés — Combien de cas passés correspondent aux critères de recherche.
- Cas le(s) plus pertinent(s) — ID du cas, sujet, statut et date de création des meilleures correspondances.
- Causes racines historiques — Ce qui a causé des problèmes similaires dans le passé.
- Résolutions passées — Quelles étapes de correction ont été appliquées et si elles étaient des correctifs permanents ou des solutions de contournement temporaires.
- Recommandations — Sur la base des schémas historiques, suggérez des pistes d'investigation ou des étapes de correction pour l'incident actuel.
- Alerte de schéma récurrent — Si le même problème s'est produit plusieurs fois, signalez-le comme un problème récurrent nécessitant un correctif permanent ou un changement architectural.
Arbre de Décision : Stratégie de Recherche de Cas
Y a-t-il un ID de cas connu associé à l'incident actuel ?
├── OUI → Récupérez ce cas spécifique et ses communications (Étape 2, filtre par ID de cas)
└── NON → Continuez ci-dessous
Le service AWS affecté est-il connu ?
├── OUI → Recherchez les cas des 90 derniers jours pour ce service, puis élargissez à 12 mois si nécessaire
└── NON → Recherchez tous les cas des 30 derniers jours et filtrez par mots-clés d'erreur
Des cas historiques pertinents ont-ils été trouvés ?
├── OUI → Examinez les communications (Étape 3), corrélez les résultats (Étape 4), résumez (Étape 5)
└── NON → Élargissez les critères de recherche :
- Élargissez la fenêtre de temps
- Recherchez par services connexes (par exemple, si ELB est affecté, vérifiez également les cas EC2 et Target Group)
- Recherchez par code d'erreur ou mots-clés de symptômes dans les sujets des cas
Conseils pour un Examen Efficace des Cas
- Commencez par des filtres précis, puis élargissez : Débutez avec des filtres spécifiques (service + fenêtre de temps) et n'élargissez que si aucun cas pertinent n'est trouvé.
- Vérifiez les cas résolus : Les informations les plus utiles proviennent souvent des cas résolus où la cause racine et le correctif sont documentés.
- Notez les schémas de sévérité des cas : Si les cas passés pour le même problème ont été déposés avec une sévérité
critical, l'incident actuel peut justifier une urgence similaire. - Recoupez avec les déploiements : Si un cas passé a été causé par un déploiement, vérifiez si un déploiement similaire a eu lieu avant l'incident actuel.