PagerDuty 事件编排运行手册

解决的问题

监控渠道增多之后，告警未必按预期顺序到达。同一条 PagerDuty 事件可能来自不同服务、不同严重级别，也可能只是噪声；如果每次都靠值班人员临时判断该查哪、该升级给谁、该补哪些上下文，处理结果会因人而异，交接也会散落在聊天窗口和邮件里。

工作方式

这个运行手册围绕 PagerDuty 的三类能力组织：Events API v2 用于接收和归一化告警，Incidents API 用于把外部信号落成可跟踪的事件，Response Plays 用于把常见响应固化成可重复执行的动作。

典型路径是：先按告警来源和严重度做分类，再向事件补充服务、owner、链接、关联变更等上下文；随后匹配 Response Play，决定是自动评论、更新状态、调用集成，还是升级给下一个人；最后把处理结论和后续动作写回事件，保证接手人能看到一致的时间线。

边界与注意点

它适合把已有 PagerDuty 流程转写成 Agent 可执行的 runbook，不适合替代对业务优先级的最终判断。规则写得越细，越要关注权限范围、API 速率限制、敏感信息是否被带入评论或外部调用；涉及生产系统升级时，应先在小范围验证分类、匹配和交接是否符合当前 on-call 约定。