支援案例審查 是做什麼的？
在調查事件且需要審查 AWS 支援案例時使用此技能 — 無論是與目前事件相關的活躍案例，或是可能包含相關背景、類似症狀或經過驗證的解決步驟的歷史案例。
使用時機
- 活躍事件與先前已解決的問題共享症狀。
- 您需要檢查過去 24 個月內是否提交過類似的支援案例。
- 您想將目前事件與已知的 AWS 服務事件關聯起來。
- 您需要從先前的案例中擷取通訊記錄和解決方案詳細資訊。
- 您想要識別跨多個支援案例的反覆出現模式。
先決條件
- AWS 帳戶必須具備 Business Support+、Enterprise Support 或 Unified Operations 方案（AWS Support API 的必要條件）。
- Agent 必須擁有在目標帳戶中呼叫
support:DescribeCases和support:DescribeCommunications的許可權限。 - 支援案例資料在建立後可保留 24 個月。超過 24 個月的案例無法透過 API 擷取。
步驟 1：識別目前事件背景
在搜尋支援案例之前，請先收集目前事件的關鍵詳細資訊：
- 受影響的 AWS 服務（例如 EC2、RDS、Lambda、ELB）。
- 在日誌或警報中觀察到的錯誤訊息或錯誤代碼。
- 事件的時間範圍（開始時間、持續時間）。
- 受影響的資源（執行個體 ID、ARN、端點名稱）。
- 症狀（延遲尖峰、5xx 錯誤、連線逾時、節流）。
將這些詳細資訊作為篩選支援案例時的搜尋條件。
步驟 2：搜尋相關支援案例
使用 AWS Support API 來擷取可能相關的案例。
擷取所有最近的案例（開啟和已解決）
aws support describe-cases \
--include-resolved-cases \
--include-communications \
--after-time "<ISO-8601-start>" \
--before-time "<ISO-8601-end>" \
--language "en"
依特定案例 ID 篩選（如果已知）
aws support describe-cases \
--case-id-list "case-123456789010-muen-2024" \
--include-communications
關鍵篩選策略
| 策略 | 如何應用 |
|---|---|
| 依時間範圍 | 使用 --after-time 和 --before-time 將案例限定在相關期間（例如過去 30 天或先前事件日期前後），因為最近的案例更能反映目前的基礎設施狀態。 |
| 依服務 | 檢查回傳案例中的 serviceCode 欄位以比對受影響的服務（例如 amazon-elastic-compute-cloud、amazon-rds），因為相同的服務通常會顯現重複的故障模式。 |
| 依嚴重等級 | 檢查 severityCode 欄位 — 針對重大事件，專注於 urgent 和 critical 案例，因為較高等級的案例通常包含來自 AWS Support 的更詳細根本原因分析。 |
| 依狀態 | 使用 --include-resolved-cases 來包含已關閉的案例，因為已解決的案例包含與目前事件相關聯時最有價值的根本原因和補救步驟。 |
| 依主旨關鍵字 | 掃描回傳案例的 subject 欄位，尋找與目前事件症狀相符的關鍵字，因為相似的症狀通常共享根本原因。 |
步驟 3：審查案例通訊記錄
在啟用 includeCommunications: true 的情況下的 describe-cases 回應，會在 recentCommunications 欄位中傳回每個案例的最新通訊記錄（最多 5 則訊息）。由於根本原因分析和解決步驟通常出現在已解決案例的最後幾則訊息中，因此這通常已足夠。
如果 recentCommunications 欄位包含 nextToken，表示該案例有更多較舊的訊息。僅在最近的訊息未包含明確的根本原因或解決方案時（例如，如果最後的訊息是後續問題而非最終答案），才使用 describe-communications 進行分頁。
aws support describe-communications \
--case-id "case-123456789010-muen-2024" \
--max-results 10 \
--next-token "<nextToken-from-recentCommunications>"
審查通訊記錄時，請尋找：
- 根本原因陳述 — AWS Support 工程師通常會在其最終回應中總結根本原因。
- 補救步驟 — 為解決問題所採取的具體行動（例如「增加 max_connections」、「套用安全群組規則」、「擴展執行個體類型」）。
- 組態建議 — AWS 提供的最佳實務或調整建議。
- 升級備註 — 如果案例已升級，請檢查來自專業團隊的更深入技術分析。
步驟 4：將發現與目前事件關聯
審查相關案例後，將發現進行關聯：
模式比對檢查清單
- 過去的案例是否共享相同的受影響服務和資源類型？
- 錯誤訊息或代碼是否相同或相似？
- 過去的事件是否發生在相似的一天中的時間或一週中的某一天（表示負載模式）？
- 根本原因是否是可能仍然存在的組態問題？
- 解決方案是否是已到期或已還原的暫時性解決方法？
- AWS 是否識別出可能重複發生的服務端問題？
相關性評分
根據與目前事件的相關性對每個歷史案例進行評分：
| 分數 | 標準 |
|---|---|
| 高 | 相同的服務、相同的錯誤、相同的資源類型、相似的時間範圍 |
| 中 | 相同的服務、不同的錯誤但相關的症狀 |
| 低 | 不同的服務但相似的架構模式或故障模式 |
步驟 5：總結發現
提供結構化摘要，包括：
- 找到的相關案例數量 — 有多少過去的案例符合搜尋條件。
- 最相關的案例 — 最符合項目的案例 ID、主旨、狀態和建立日期。
- 歷史根本原因 — 過去導致類似問題的原因。
- 過去的解決方案 — 採取了哪些補救步驟，以及它們是永久修正還是暫時性解決方法。
- 建議 — 根據歷史模式，為目前事件建議調查方向或補救步驟。
- 重複模式警報 — 如果相同問題已發生多次，請將其標記為需要永久修正或架構變更的重複問題。
決策樹：案例搜尋策略
是否有與目前事件相關的已知案例 ID？
├── 是 → 擷取該特定案例及其通訊記錄（步驟 2，依案例 ID 篩選）
└── 否 → 繼續以下步驟
受影響的 AWS 服務是否已知？
├── 是 → 搜尋過去 90 天內該服務的案例，如有需要再擴展至 12 個月
└── 否 → 搜尋過去 30 天內的所有案例，並依錯誤關鍵字篩選
是否找到相關的歷史案例？
├── 是 → 審查通訊記錄（步驟 3），關聯發現（步驟 4），總結（步驟 5）
└── 否 → 放寬搜尋條件：
- 擴展時間範圍
- 依相關服務搜尋（例如，如果 ELB 受影響，也檢查 EC2 和目標群組案例）
- 依案例主旨中的錯誤代碼或症狀關鍵字搜尋
有效案例審查的技巧
- 從狹窄開始，再擴大範圍：從特定的篩選器（服務 + 時間範圍）開始，僅在未找到相關案例時才擴大範圍。
- 檢查已解決的案例：最有價值的資訊通常來自已記錄根本原因和修正的已解決案例。
- 注意案例嚴重等級模式：如果過去相同問題的案例是以
critical嚴重等級提交的，則目前事件可能也需要類似的緊急處理。 - 與部署交叉參考：如果過去的案例是由部署引起的，請檢查在目前事件之前是否發生了類似的部署。