Support Case Review
Verwenden Sie diesen Skill, wenn Sie einen Incident untersuchen und AWS-Supportfälle prüfen müssen – entweder den aktuellen Fall, der mit dem Incident verbunden ist, oder historische Fälle, die relevanten Kontext, ähnliche Symptome oder bewährte Abhilfemaßnahmen enthalten können.
Wann dieser Skill verwendet werden sollte
- Ein aktiver Incident weist Symptome auf, die mit zuvor behobenen Problemen übereinstimmen.
- Sie müssen prüfen, ob in den letzten 24 Monaten ein ähnlicher Supportfall eingereicht wurde.
- Sie möchten den aktuellen Incident mit bekannten AWS-Serviceereignissen korrelieren.
- Sie müssen Kommunikationen und Lösungsdetails aus einem früheren Fall abrufen.
- Sie möchten wiederkehrende Muster über mehrere Supportfälle hinweg identifizieren.
Voraussetzungen
- Das AWS-Konto muss einen Business Support+, Enterprise Support oder Unified Operations Plan haben (erforderlich für die AWS Support API).
- Der Agent muss Berechtigungen haben, um
support:DescribeCasesundsupport:DescribeCommunicationsim Zielkonto aufzurufen. - Supportfalldaten sind 24 Monate nach Erstellung verfügbar. Fälle, die älter als 24 Monate sind, können nicht über die API abgerufen werden.
Schritt 1: Kontext des aktuellen Incidents ermitteln
Sammeln Sie vor der Suche nach Supportfällen die wichtigsten Details aus dem aktuellen Incident:
- Betroffene AWS-Services (z. B. EC2, RDS, Lambda, ELB).
- Fehlermeldungen oder Fehlercodes, die in Logs oder Alarms beobachtet wurden.
- Zeitrahmen des Incidents (Startzeit, Dauer).
- Betroffene Ressourcen (Instanz-IDs, ARNs, Endpunktnamen).
- Symptome (Latenzspitzen, 5xx-Fehler, Verbindungs-Timeouts, Drosselung).
Verwenden Sie diese Details als Suchkriterien beim Filtern von Supportfällen.
Schritt 2: Nach verwandten Supportfällen suchen
Verwenden Sie die AWS Support API, um Fälle abzurufen, die relevant sein könnten.
Alle aktuellen Fälle abrufen (offen und gelöst)
aws support describe-cases \
--include-resolved-cases \
--include-communications \
--after-time "<ISO-8601-start>" \
--before-time "<ISO-8601-end>" \
--language "en"
Nach bestimmten Fall-IDs filtern (falls bekannt)
aws support describe-cases \
--case-id-list "case-123456789010-muen-2024" \
--include-communications
Wichtige Filterstrategien
| Strategie | Anwendung |
|---|---|
| Nach Zeitfenster | Verwenden Sie --after-time und --before-time, um Fälle auf den relevanten Zeitraum zu beschränken (z. B. die letzten 30 Tage oder um ein früheres Incident-Datum), da aktuelle Fälle eher den aktuellen Infrastrukturzustand widerspiegeln. |
| Nach Service | Überprüfen Sie das Feld serviceCode in den zurückgegebenen Fällen, um den betroffenen Service zu identifizieren (z. B. amazon-elastic-compute-cloud, amazon-rds), da derselbe Service oft wiederkehrende Fehlermuster aufweist. |
| Nach Schweregrad | Prüfen Sie das Feld severityCode – konzentrieren Sie sich bei schwerwiegenden Incidents auf Fälle mit urgent und critical, da Fälle mit höherem Schweregrad tendenziell detailliertere Ursachenanalysen vom AWS Support enthalten. |
| Nach Status | Verwenden Sie --include-resolved-cases, um geschlossene Fälle einzuschließen, da gelöste Fälle die Ursache und Abhilfemaßnahmen enthalten, die für die Korrelation mit dem aktuellen Incident am wertvollsten sind. |
| Nach Betreff-Schlüsselwörtern | Durchsuchen Sie das Feld subject der zurückgegebenen Fälle nach Schlüsselwörtern, die den Symptomen des aktuellen Incidents entsprechen, da ähnliche Symptome oft auf gemeinsame Ursachen hinweisen. |
Schritt 3: Fallkommunikation prüfen
Die Antwort von describe-cases mit includeCommunications: true gibt die aktuellsten Kommunikationen für jeden Fall im Feld recentCommunications zurück (bis zu 5 Nachrichten). Da Ursachenanalyse und Lösungsschritte typischerweise in den letzten Nachrichten eines gelösten Falls stehen, ist dies normalerweise ausreichend.
Wenn das Feld recentCommunications einen nextToken enthält, hat der Fall weitere ältere Nachrichten. Verwenden Sie describe-communications nur dann zum Paginieren, wenn die aktuellen Nachrichten keine klare Ursache oder Lösung enthalten – zum Beispiel, wenn die letzten Nachrichten Folgefragen und keine endgültige Antwort sind.
aws support describe-communications \
--case-id "case-123456789010-muen-2024" \
--max-results 10 \
--next-token "<nextToken-from-recentCommunications>"
Achten Sie bei der Prüfung der Kommunikation auf:
- Ursachenaussagen – AWS Support Engineers fassen die Ursache oft in ihrer letzten Antwort zusammen.
- Abhilfemaßnahmen – Konkrete Maßnahmen zur Behebung des Problems (z. B. „max_connections erhöht“, „Sicherheitsgruppenregel angewendet“, „Instanztyp hochskaliert“).
- Konfigurationsempfehlungen – Best Practices oder Optimierungsvorschläge von AWS.
- Eskalationsvermerke – Falls der Fall eskaliert wurde, prüfen Sie auf tiefergehende technische Analysen spezialisierter Teams.
Schritt 4: Ergebnisse mit dem aktuellen Incident korrelieren
Nach der Prüfung relevanter Fälle korrelieren Sie die Ergebnisse:
Checkliste für Musterabgleich
- Teilen vergangene Fälle denselben betroffenen Service und Ressourcentyp?
- Sind die Fehlermeldungen oder -codes identisch oder ähnlich?
- Traten frühere Incidents zu einer ähnlichen Tageszeit oder an einem ähnlichen Wochentag auf (was auf Lastmuster hindeutet)?
- War die Ursache ein Konfigurationsproblem, das möglicherweise noch besteht?
- War die Lösung eine temporäre Problemumgehung, die inzwischen abgelaufen oder rückgängig gemacht wurde?
- Hat AWS ein serverseitiges Problem identifiziert, das möglicherweise wiederholt auftritt?
Relevanzbewertung
Bewerten Sie jeden historischen Fall nach Relevanz für den aktuellen Incident:
| Bewertung | Kriterien |
|---|---|
| Hoch | Gleicher Service, gleicher Fehler, gleicher Ressourcentyp, ähnlicher Zeitrahmen |
| Mittel | Gleicher Service, anderer Fehler, aber verwandte Symptome |
| Niedrig | Anderer Service, aber ähnliches Architekturmuster oder Fehlermodus |
Schritt 5: Ergebnisse zusammenfassen
Erstellen Sie eine strukturierte Zusammenfassung mit:
- Anzahl der gefundenen relevanten Fälle – Wie viele vergangene Fälle den Suchkriterien entsprachen.
- Relevanteste(r) Fall/Fälle – Fall-ID, Betreff, Status und Erstellungsdatum der besten Treffer.
- Historische Ursachen – Was ähnliche Probleme in der Vergangenheit verursacht hat.
- Frühere Lösungen – Welche Abhilfemaßnahmen angewendet wurden und ob es sich um dauerhafte Korrekturen oder temporäre Problemumgehungen handelte.
- Empfehlungen – Basierend auf historischen Mustern schlagen Sie Untersuchungspfade oder Abhilfemaßnahmen für den aktuellen Incident vor.
- Wiederkehrendes Muster erkennen – Wenn dasselbe Problem mehrfach aufgetreten ist, markieren Sie es als wiederkehrendes Problem, das eine dauerhafte Korrektur oder architektonische Änderung erfordert.
Entscheidungsbaum: Fallsuchstrategie
Ist eine bekannte Fall-ID mit dem aktuellen Incident verknüpft?
├── JA → Rufen Sie diesen spezifischen Fall und seine Kommunikation ab (Schritt 2, Filter nach Fall-ID)
└── NEIN → Fahren Sie unten fort
Ist der betroffene AWS-Service bekannt?
├── JA → Durchsuchen Sie Fälle der letzten 90 Tage nach diesem Service, erweitern Sie ggf. auf 12 Monate
└── NEIN → Durchsuchen Sie alle Fälle der letzten 30 Tage und filtern Sie nach Fehlerschlüsselwörtern
Wurden relevante historische Fälle gefunden?
├── JA → Kommunikation prüfen (Schritt 3), Ergebnisse korrelieren (Schritt 4), zusammenfassen (Schritt 5)
└── NEIN → Suchkriterien erweitern:
- Zeitfenster vergrößern
- Nach verwandten Services suchen (z. B. wenn ELB betroffen ist, auch EC2- und Target-Group-Fälle prüfen)
- Nach Fehlercode oder Symptom-Schlüsselwörtern in Fallbetreffen suchen
Tipps für eine effektive Fallprüfung
- Beginnen Sie eng, dann erweitern: Verwenden Sie zunächst spezifische Filter (Service + Zeitfenster) und erweitern Sie diese nur, wenn keine relevanten Fälle gefunden werden.
- Prüfen Sie gelöste Fälle: Die wertvollsten Informationen stammen oft aus gelösten Fällen, in denen Ursache und Lösung dokumentiert sind.
- Beachten Sie Muster beim Schweregrad: Wenn frühere Fälle für dasselbe Problem mit
criticaleingestuft wurden, kann der aktuelle Incident eine ähnliche Dringlichkeit rechtfertigen. - Querverweis mit Deployments: Wenn ein früherer Fall durch ein Deployment verursacht wurde, prüfen Sie, ob vor dem aktuellen Incident ein ähnliches Deployment stattfand.