技能介绍

先解决什么问题

事故响应中最麻烦的不是缺少单点告警，而是缺少一条可回放的时间线。PagerDuty 记录触发与升级，Datadog Monitors 反映监控状态变化，Slack 保留值班沟通与人工决策，部署系统又记录变更窗口。这些证据分散后，工程师往往要手工复制时间戳、对齐不同 ID、确认某次告警到底对应哪次发布。本技能的目标是把这类机械劳动收敛成一条结构化事件流，用于事后定位根因。

技能如何工作

核心流程可以拆成四步：

拉取源数据：从 PagerDuty Events API v2 读取事件与告警，从 Datadog Monitors API 读取监控相关状态，从 Slack message archives 读取沟通记录。
归一化与排序：统一时间字段、时区和来源标识，把告警、确认、注释、部署变更等事件按发生时间重排，避免只看到“最后一条”结论。
关联部署事件：将告警出现窗口与部署事件对齐，标记二者是否存在时间重叠或顺序关系，为根因分析提供候选链路。
输出复盘输入：形成可用于复盘的有序时间线，突出最早异常、关键转折点和可能的变更引入点。

适用边界与注意点

它适合已有清晰 API 凭证、日志保留和服务间可对齐 ID 的环境。源系统若缺少 monitor id、incident id、slack message ts 或部署 commit 映射，关联会退化为弱推断，不能替代完整的可观测性接入。数据保留窗口、分页限制和权限范围也会影响回溯长度。若写入 Notion 工作区，连接必须由用户显式授权访问相应页面与数据库；访问令牌、内部连接和公共连接的可见性也需要按 Notion 文档确认。