支持案例审查 是做什么的？
在调查事件时，使用此技能审查AWS支持案例——无论是与当前事件关联的案例，还是可能包含相关上下文、类似症状或已验证修复步骤的历史案例。
何时使用此技能
- 当前事件与之前解决的问题有相似症状。
- 需要检查过去12个月内是否有类似支持案例。
- 希望将当前事件与已知的AWS服务事件关联。
- 需要获取先前案例的通信记录和解决方案详情。
- 希望识别多个支持案例之间的重复模式。
前提条件
- AWS账户必须拥有 Business Support+、Enterprise Support 或 Unified Operations 计划（AWS Support API 所需）。
- 代理必须具有在目标账户中调用
support:DescribeCases和support:DescribeCommunications的权限。 - 支持案例数据在创建后保留12个月。超过12个月的案例无法通过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 字段——重点关注紧急和严重案例以对应重大事件，因为高严重级别案例通常包含AWS支持团队更详细的根本原因分析。 |
| 按状态 | 使用 --include-resolved-cases 包含已关闭案例，因为已解决案例包含最宝贵的根本原因和修复步骤，可用于关联当前事件。 |
| 按主题关键字 | 扫描返回案例的 subject 字段，查找与当前事件症状匹配的关键字，因为相似的症状往往有共同的底层原因。 |
步骤 3：查看案例通信记录
describe-cases 响应中包含 includeCommunications: true 时，会在 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支持工程师通常会在最终回复中总结根本原因。
- 修复步骤——解决问题采取的具体操作（例如“增加了 max_connections”、“应用了安全组规则”、“升级了实例类型”）。
- 配置建议——AWS提供的推荐策略或调优建议。
- 升级记录——如果案例被升级，检查来自专门团队的技术分析。
步骤 4：将发现与当前事件关联
审查相关案例后，关联发现：
模式匹配检查清单
- 过去的案例是否涉及相同的受影响的服务和资源类型？
- 错误消息或错误码是否相同或相似？
- 过去的事件是否发生在类似的时间或星期几（暗示负载模式）？
- 根本原因是否是可能仍然存在的配置问题？
- 解决方案是否是已过期或已撤销的临时解决方法？
- AWS是否识别出可能重复出现的服务端问题？
相关性评分
对每个历史案例与当前事件的相关性进行评分：
| 分数 | 标准 |
|---|---|
| 高 | 相同服务、相同错误、相同资源类型、类似时间范围 |
| 中 | 相同服务、不同错误但症状相关 |
| 低 | 不同服务但架构模式或故障模式类似 |
步骤 5：总结发现
提供结构化摘要，包括：
- 找到的相关案例数量——有多少过去案例匹配搜索条件。
- 最相关的案例——最佳匹配的案例ID、主题、状态和创建日期。
- 历史根本原因——过去导致类似问题的原因。
- 过去的解决方案——应用了哪些修复步骤，是永久修复还是临时解决方法。
- 建议——基于历史模式，为当前事件建议调查路径或修复步骤。
- 重复模式警告——如果同一个问题发生多次，标记为需要永久修复或架构变更的反复性问题。
决策树：案例搜索策略
是否知道与当前事件关联的案例ID？
├── 是 → 检索该特定案例及其通信记录（步骤2，按案例ID过滤）
└── 否 → 继续往下
是否知道受影响的AWS服务？
├── 是 → 搜索该服务过去90天内的案例，必要时扩展到12个月
└── 否 → 搜索过去30天内所有案例，按错误关键字过滤
是否找到相关历史案例？
├── 是 → 查看通信记录（步骤3），关联发现（步骤4），总结（步骤5）
└── 否 → 扩大搜索条件：
- 扩大时间窗口
- 按相关服务搜索（例如，如果ELB受影响，也检查EC2和Target Group案例）
- 在案例主题中按错误码或症状关键字搜索
有效案例审查提示
- 先缩小范围，再扩大：从具体过滤器（服务+时间窗口）开始，仅在未找到相关案例时扩大。
- 查看已解决案例：最有价值的信息通常来自已解决案例，其中记录了根本原因和修复方法。
- 注意案例严重级别模式：如果过去针对同一问题的案例均以
严重级别提交，则当前事件可能也需同样紧急处理。 - 与部署记录交叉引用：如果过去的案例由部署引起，请检查当前事件之前是否发生了类似部署。