AWS CloudWatch 告警诊断

问题：告警触发之后，时间都花在"翻后台"上

凌晨一条 CloudWatch 告警把人叫醒：CPUUtilization 超过阈值，资源进入 ALARM 状态。控制台只告诉你"告警触发了"，不告诉你触发前后指标到底怎么波动、是不是正好有人做了变更、相关资源在 AWS Config 里有没有被动过。排查根因要在指标页、告警历史、Config 快照之间来回切换，手动把时间线拼起来。拖得越久，越难分清是"指标异常"还是"变更引发异常"。

工作方式：从告警信号到结构化事件摘要

这个技能针对的就是这一步排查，围绕已触发的告警展开，核心动作包括：

• 拉取 CloudWatch 指标：查看告警关联指标近期的数据点，确认异常形态（骤升、持续高位、周期尖峰）与发生窗口。
• 读取告警历史记录：定位状态迁移时间点，区分"新触发"与"反复在 OK/ALARM 间抖动"。
• 对照 AWS Config 资源快照：把资源属性变化与告警窗口对齐，找出时间上接近的变更。
• 关联并给出假设：将指标异常与最近的基础设施变更对应起来，产出候选根因假设，而不是武断下结论。
• 输出结构化摘要：整理成包含修复选项的事件摘要，可直接贴进事故记录或交接给下一班。

适用边界与注意点

• 产出的是根因假设，需要结合业务上下文人工确认，技能本身不保证因果成立。
• 诊断质量取决于数据留存：告警历史受保留期限制，Config 是否有对应资源快照、指标采样精度如何，都会影响关联效果。
• 运行环境需要对 CloudWatch 与 AWS Config 具备相应的读取权限，否则查询步骤无法完成。
• 附带的 SKILL.md 中混入了上游 SDK 文档的通用说明，与告警诊断流程无关；实际行为以诊断指令为准，使用前建议先通读一遍。