技能介绍

要解决的具体问题

当 CloudWatch 告警数量增长到几十、上百条时，运维同学面对的往往是一堆静态字符串：AlarmName、StateValue、Reason。它们告诉我们“什么出了问题”，却很少告诉我们“问题可能出在哪”“应该先处理哪个”“历史上类似指标长什么样”。人工翻看 Console、切换到 CloudTrail 查事件、再打开内部 Wiki 找 Runbook，这一整套动作在高峰期会迅速消耗掉排障时间。

核心能力与关键步骤

这个技能把上述流程拆成三段可组合的能力：

告警读取与结构化：通过 DescribeAlarms 拉取当前所有 alarm 的状态、阈值、维度和标注，形成可分诊的告警集合。
历史指标分析：调用 GetMetricData 拉取与告警关联的指标时间序列，识别抖动、漂移、尖刺等形态，为判断是否为误报或持续性故障提供依据。
根因关联：使用 CloudTrail LookupEvents 在告警时间窗口内检索 API 调用，尝试把“指标异常”映射到“某个具体的 API 动作或资源变更”。

在拿到这三份数据后，技能会根据告警影响的资源范围做优先级排序，并输出一份贴近操作层面的修复手册。手册会明确指向需要恢复的服务、需要回滚的配置、需要确认的资源状态，而不是停留在“请检查网络”这一层。

使用边界与注意点

需要正确的权限配置：运行环境需要允许 cloudwatch:DescribeAlarms、cloudwatch:GetMetricData 和 cloudtrail:LookupEvents。缺少任何一个都会导致对应的能力静默降级。
历史数据窗口依赖请求参数：GetMetricData 的起始时间和周期需要合理设置，太短会错过上下文，太长会增加噪音并带来 API 成本。
CloudTrail 事件有保留期：如果目标动作发生在保留期之外，LookupEvents 不会返回结果，根因关联只能基于告警本身。
不替代监控架构：它处理的是“已触发”的告警，不负责指标采集、告警规则制定或通知分发。
建议搭配 CI/CD 或 ITSM 流程使用：当修复手册需要触发自动化动作时，应由调用方负责执行，技能本身只负责分类和建议。