# PagerDuty 功能拆解与复刻需求

## 1. 文档目标

本文档用于基于 PagerDuty 公开产品资料，系统梳理其在以下三个方向的核心能力：

- 事件编排（Event Orchestration）
- 值班排班与升级（On-call / Escalation）
- 事件复盘与改进闭环（Post-Incident Review / Postmortem）

目标不是逐字复述官网，而是把 PagerDuty 的能力整理成一份适合产品设计和功能复刻的需求文档，便于后续回答两个问题：

1. 如果先复刻一个 PagerDuty 风格的 Incident Management 平台，MVP 应该包含哪些功能。
2. 在完成基础 Incident Management 后，AIOps 应该再叠加哪些智能化能力。

说明：

- 本文基于 PagerDuty 官方公开页面与帮助文档整理，不代表其内部 PRD。
- 文中“建议复刻”表示适合纳入你的产品规划，不代表必须完全 1:1 实现。

## 2. PagerDuty 的产品定位

PagerDuty 本质上不是一个单纯“发告警”的工具，而是一套面向生产故障响应的运行管理平台。它解决的问题链路是完整的：

1. 从监控系统、日志系统、CI/CD、云平台接收事件。
2. 对事件进行路由、降噪、抑制、富化和分派。
3. 将事件转化为 `Incident`，并自动通知当前值班人。
4. 在响应过程中组织协同人员、角色、任务和沟通。
5. 在恢复后形成复盘、行动项、分析报表和改进闭环。

因此，PagerDuty 的核心价值不是“消息通知”，而是“面向 Incident 生命周期的编排系统”。

## 3. 复刻 PagerDuty 之前先明确的对象模型

如果要复刻 PagerDuty，首先需要定义稳定的领域对象。否则后续编排、升级、复盘都会缺少统一模型。

建议优先抽象以下核心对象：

| 对象 | 含义 | 说明 |
| --- | --- | --- |
| `Event` | 外部系统送入的原始事件 | 来自监控、日志、变更、邮件、Webhook 等 |
| `Alert` | 平台内部标准化后的告警 | 可被抑制、分组、去重、转 Incident |
| `Incident` | 需要协同处理的问题实体 | 有状态、负责人、升级链路、时间线 |
| `Service` | 技术服务或受监控对象 | Incident 通常挂在某个 service 上 |
| `Business Service` | 业务服务 | 用于对外状态同步、业务影响展示 |
| `EscalationPolicy` | 升级策略 | 定义未响应时如何升级 |
| `Schedule` | 值班表 | 定义谁在什么时间值班 |
| `Responder` | 响应人 | 当前参与某个 Incident 的人 |
| `Stakeholder` | 干系人/订阅人 | 接收状态更新，但不一定参与处理 |
| `IncidentRole` | 事件角色 | 如 Incident Commander、沟通负责人 |
| `IncidentTask` | 事件任务 | 响应过程中需要被跟踪的具体事项 |
| `PostIncidentReview` | 复盘实体 | 用于复盘、分析、行动项沉淀 |
| `ActionItem` | 改进行动项 | 复盘后的工程任务、流程任务、会议任务 |

PagerDuty 的很多功能之所以可扩展，关键就在于这些对象之间关系稳定，例如：

- `Service -> EscalationPolicy -> Schedule -> On-call User`
- `Event -> Alert -> Incident`
- `Incident -> Responders / Subscribers / Roles / Tasks / Timeline`
- `Incident -> PostIncidentReview -> ActionItems`

## 4. 功能全景

从复刻角度看，PagerDuty 可以拆成 6 个能力域：

1. 事件接入与标准化
2. 事件编排与路由
3. 值班排班与升级通知
4. Incident 协同处理
5. 复盘与改进闭环
6. 分析报表与运营洞察

下面逐块展开。

## 5. 事件接入与标准化能力

### 5.1 多入口事件接入

PagerDuty 支持从多种来源触发 Incident 或导入事件，典型入口包括：

- 第三方监控集成
- Events API
- REST API
- Email Integration
- Slack / Mobile / Web 手工声明 Incident

对应你的产品，MVP 至少应支持：

- Webhook / Events API 接入
- 手工创建 Incident
- 邮件或 IM 触发可以后置

### 5.2 统一事件模型

PagerDuty 在编排前会把事件转为统一字段模型，可理解为平台内部标准事件格式。这样后续规则就不需要适配每个监控源的异构字段。

建议你的平台在事件接入层完成：

- 原始事件落库
- 标准字段抽取
- 原始 payload 保留
- 常用字段标准化，如：
  - 标题
  - 来源
  - 服务名
  - 主机/实例
  - 严重级别
  - 环境
  - 标签
  - 去重键 `dedup_key`

### 5.3 告警与 Incident 的区分

PagerDuty 明确区分 `Alert` 与 `Incident`：

- `Alert` 是事件处理后的告警记录。
- `Incident` 是需要人介入的处理单元。

这个设计非常关键，因为并不是所有事件都应该立刻通知人。很多事件只需要被记录、抑制、合并或等待进一步判断。

建议你的系统也采用二层模型：

- `Event -> Alert -> Incident`

这样后续做降噪、关联和 AIOps 会更自然。

## 6. 事件编排能力

事件编排是 PagerDuty 最值得优先复刻的部分之一。它本质上是“事件进入平台后，如何按规则被处理”的能力中心。

### 6.1 单入口统一接入

PagerDuty 的 Event Orchestration 支持将事件统一打到一个入口，再由平台按规则决定：

- 路由到哪个 `Service`
- 是否触发 Incident
- 是否仅保留为 suppressed alert
- 是否变更优先级、字段或升级策略

这个能力的价值在于：

- 上游系统不用知道最终具体通知谁
- 规则集中管理，不散落在各个服务里
- 后续可以逐步演化更复杂的自动化逻辑

### 6.2 编排层级

PagerDuty 的编排规则可分成三层理解：

- 全局编排规则：进入平台后的统一预处理
- 路由规则：决定流向哪个服务
- 服务级编排规则：到达服务后再做细分处理

你的产品复刻时建议采用类似分层：

1. `global_orchestration`
2. `routing_rules`
3. `service_orchestration`

### 6.3 路由规则能力

PagerDuty 的路由规则支持基于事件内容进行服务分发。需要复刻的关键点包括：

- 条件匹配路由
- 无条件默认路由
- catch-all 兜底规则
- 动态路由
  - 从事件字段提取服务名或服务 ID
  - 用正则提取目标值
- 时间条件路由
- 日期范围路由
- 频次条件路由

这意味着规则引擎至少需要支持以下条件类型：

- 字段等于/不等于
- 包含/不包含
- 正则匹配
- 数值比较
- 时间窗口
- 频率阈值

### 6.4 编排动作能力

PagerDuty 在规则命中后可以执行多个动作。这里是最核心的复刻清单。

#### 6.4.1 事件与 Incident 控制动作

- 触发 Incident
- 暂停通知一段时间后再触发
- 抑制告警，不创建 Incident
- 丢弃事件并停止处理
- 设置 Incident Priority
- 动态覆盖 Escalation Policy
- 向 Incident 自动写入说明 note

这是 PagerDuty 从“收事件”升级为“事件处理编排平台”的关键。

#### 6.4.2 字段富化与转换

PagerDuty 支持把原始事件字段转为统一字段，或覆盖已有字段。复刻时应支持：

- 字段映射
- 模板赋值
- 正则提取
- 自定义变量
- 构造 `dedup_key`
- 写入 `custom_details`
- 补充上下文信息

这类能力对后续 AIOps 非常重要，因为它直接决定事件数据质量。

#### 6.4.3 Incident 自定义字段填充

PagerDuty 允许把事件字段或变量写入 Incident Custom Fields。这个能力非常适合你的产品复刻，因为它能把结构化上下文贯穿到整个响应链路。

建议支持：

- 静态值填充
- 动态字段映射
- 模板变量填充
- 多种字段类型
  - 文本
  - 单选
  - 多选
  - 标签
  - 时间
  - 整数/小数
  - 布尔值

### 6.5 去重与聚合前置能力

PagerDuty 的编排可以直接设置 `dedup_key`。这意味着：

- 相同问题不会不断创建新的 Incident
- 后续事件可以进入同一个 Alert / Incident 生命周期

这部分建议作为 MVP 必须能力，因为没有去重，值班系统会非常吵。

### 6.6 Catch-all 与未命中处理

PagerDuty 对未命中规则的事件提供兜底行为：

- 不进入服务，也不创建 Incident
- 或统一路由到一个默认服务

这看似是小功能，实际上对线上运行非常重要。你的平台也需要支持：

- 明确的兜底规则
- 兜底规则审计
- 未命中事件可观测

### 6.7 自动化触发点

PagerDuty 的编排规则可以进一步触发：

- Webhook
- Automation Actions
- Incident Workflows

这说明其编排层不仅能“判定”，还能“驱动动作”。

你的产品可以先做两级：

- MVP：规则命中后调用内部工作流/外部 Webhook
- 后续：对接 Runbook、审批流、自动修复动作

## 7. 值班、排班与升级能力

这是 PagerDuty 的第二根主线，也是最容易形成产品闭环的模块。

### 7.1 值班排班 `Schedule`

PagerDuty 的值班排班不是简单名单，而是一个完整的时间覆盖系统。核心能力包括：

- 创建排班表
- 设置时区
- 设置轮转方式
  - 日轮转
  - 周轮转
  - 自定义轮转
- 设置交接时间
- 调整人员顺序
- 多层排班 `layer`
- 限定值班时间窗口
  - 按天固定时间段
  - 按周不同时间段
- 支持 follow-the-sun 场景
- 预览最终排班结果

建议你的产品在设计时把 `Schedule` 视为一等对象，而不是附属配置。

### 7.2 排班层 `Schedule Layer`

PagerDuty 支持一个排班中有多个 layer，后创建的 layer 优先级更高。这个设计可以支持很多复杂场景：

- 平日/周末双层排班
- 全球时区覆盖
- 白班/夜班覆盖
- 节假日特殊层覆盖正常层

如果你想做企业级值班系统，`layer` 是很值得复刻的设计。

### 7.3 覆盖缺口与约束

PagerDuty 明确告诉用户：如果值班表限制了时间，就可能出现 coverage gap。若无人值班，Incident 甚至不会被创建。

这给你的产品一个重要启示：

- 值班系统必须可计算“当前是否有人值班”
- 覆盖缺口必须可见
- 触发失败要给明确原因

建议必须支持：

- 当前 on-call 查询
- 未来值班预览
- 覆盖缺口检测
- 无值班人告警

### 7.4 升级策略 `Escalation Policy`

PagerDuty 的升级策略连接 `Service`、`Schedule` 和 `User`。核心功能包括：

- 多级升级规则
- 每级指定用户或值班表
- 每级超时时间 `escalation timeout`
- 未响应时自动升级到下一级
- 可重复整条升级策略多次
- 多人并行通知
- 支持 round robin
- 可关联到 team

这个模块建议你按“规则链”建模，不要只做“主值班人 + 备份值班人”两层固定结构。

### 7.5 升级行为细节

PagerDuty 在升级行为上有几个关键设计，非常值得复刻：

- 一旦有人 `acknowledge`，升级停止
- 如果当前层无人值班，则跳到下一层
- Incident 使用的是触发当时的升级策略快照
- 修改升级策略不会影响已经打开的 Incident

这几点会极大减少线上歧义。建议你的系统也保留：

- 升级快照
- 升级轨迹
- 每次通知记录
- 每次升级原因

### 7.6 通知方式与个人通知规则

PagerDuty 通知不只由升级策略决定，还受用户个人通知规则影响。支持渠道包括：

- Push
- Phone
- SMS
- Email
- Slack 等集成渠道

你的产品至少需要区分两层：

- 平台层决定“应该通知谁”
- 用户层决定“怎么通知他”

### 7.7 On-call Handoff

PagerDuty 提供值班交接通知，支持在上岗前最多 48 小时提醒。这类功能虽然不是 MVP 必需，但对真实值班体验非常重要。

建议纳入第二阶段：

- 值班前提醒
- 值班交接摘要
- 当前/下一班值班人可视化

## 8. Incident 协同响应能力

PagerDuty 并不止于“谁被通知”，它还覆盖了响应过程中的组织与协同。

### 8.1 Incident 生命周期

PagerDuty 的 Incident 具有明确状态：

- `triggered`
- `acknowledged`
- `resolved`

并支持：

- 手工声明 Incident
- API 触发 Incident
- 重新打开 Incident
- 取消 acknowledge
- redaction（敏感信息擦除）

建议你的产品至少实现：

- 新建
- 确认接手
- 解决
- 重开
- 状态时间线

### 8.2 Incident Timeline

PagerDuty 的 Timeline 是非常关键的基础能力，它记录：

- 状态变更
- 通知发送
- 升级动作
- 响应人加入/拒绝
- 备注
- 工作流执行结果

这不只是审计日志，也是复盘的数据源。

建议你的产品从第一版就做统一 Timeline，而不是把日志散落在多个页面。

### 8.3 手工声明与覆盖分派

PagerDuty 支持手工创建 Incident 时：

- 指定受影响服务
- 指定优先级与紧急度
- 直接覆盖默认升级策略
- 指定用户或升级策略作为 assignee
- 添加额外响应人
- 添加会议桥接信息

这意味着手工声明不是“简单建单”，而是“一次完整的事件动员动作”。

### 8.4 添加响应人 `Add Responders`

PagerDuty 支持在 Incident 已经打开后继续加入响应人，包括：

- 单个用户
- 整个升级策略
- 手工加入
- 通过 Incident Workflow 自动加入

响应人可接受、拒绝或待处理，平台会记录状态。

建议你的系统复刻：

- 主负责人
- 额外响应人
- 响应邀请状态
- 升级策略作为 responder group

### 8.5 Incident Roles

PagerDuty 有专门的 Incident Roles，而不是只靠备注描述角色。能力包括：

- 预定义角色
- 自定义角色
- 给响应人分配角色
- 一个用户可承担多个角色
- 同一角色同一时刻只指向一个负责人
- Slack / Teams / Workflow 内都可操作

这是非常值得借鉴的企业级设计。

建议 MVP 支持至少两个默认角色：

- `Incident Commander`
- `Communications Lead`

### 8.6 Incident Tasks

PagerDuty 允许在响应过程中创建任务，既可以 ad-hoc，也可以由工作流预定义。任务可包括：

- 任务名称
- 描述
- 状态
- 指派人

这类能力有助于把“协同处理”从聊天工具中结构化出来。

建议在你的产品第二阶段加入：

- Incident 下挂任务列表
- 任务指派
- 任务状态流转
- 与工作流联动

### 8.7 会议与协作入口

PagerDuty 支持会议桥接信息，例如：

- Conference number
- Meeting URL

这说明 Incident 页不仅是状态页，也是协作入口页。

你的产品建议预留：

- 会议链接
- Chat channel 链接
- Runbook 链接
- Dashboard 链接

## 9. 干系人沟通与状态更新能力

PagerDuty 另一个很强的点，是把“故障处理”和“故障通报”明确分开。

### 9.1 订阅人 `Subscribers`

PagerDuty 支持给 Incident 增加订阅人：

- 用户
- 团队
- 业务服务订阅者
- 工作流自动订阅

而且订阅本身是 silent 的，不会立即打扰订阅者，只有后续状态更新才会通知。这是很成熟的设计。

### 9.2 状态更新 `Status Updates`

PagerDuty 支持响应人主动发布状态更新，典型内容包括：

- 当前影响面
- 当前处理进展
- 预计恢复时间
- 下一次更新时间

更新可通过：

- Web
- Mobile
- API
- Incident Workflow

### 9.3 多渠道发布

PagerDuty 的状态更新可发到：

- Push
- Email
- SMS
- Internal Status Page

这意味着平台要区分：

- 响应者通知
- 干系人状态通知

这两个不是一回事。

### 9.4 模板化沟通

PagerDuty 提供 `Status Update Templates`，支持：

- 模板名称和描述
- 标准消息模板
- Email 标题和正文模板
- 变量字段引用
- Liquid 模板语言
- 条件渲染
- 自定义字段带入

这类能力非常有价值，因为很多企业故障通报的难点不在“能发消息”，而在“内容是否规范一致”。

建议你的产品至少支持：

- 状态更新模板
- 变量占位符
- 富文本邮件模板可以后置

## 10. 复盘与事件学习能力

PagerDuty 通过 Jeli 把复盘做成了独立能力域，而不是只留一段文字备注。

### 10.1 复盘入口

PagerDuty 支持从已解决 Incident 创建 Post-Incident Review。也支持传统 Postmortem 报告模式。

这意味着：

- 复盘对象应与 Incident 绑定
- 一个 Incident 可以触发一个正式复盘流程

### 10.2 复盘状态流转

Jeli 提供明确的复盘阶段：

1. `Unassigned`
2. `Assigned`
3. `In Progress`
4. `In Review`
5. `Completed`

这个设计非常适合你复刻，因为它让“复盘有没有做”变成可管理对象，而不是靠口头推动。

### 10.3 复盘报告结构

PagerDuty 的 Post-Incident Review Report 不是单一表单，而是一组结构化标签页，核心包括：

- Overview
- Summary
- Key Roles
- Imported Data Sources
- Tags
- Related Reviews
- Narrative
- People
- Takeaways
- Action Items
- Attached Resources
- Export Report

对于你的产品，这说明复盘需要覆盖三类内容：

- 事实数据
- 叙事分析
- 改进行动

### 10.4 Narrative Builder

这是 Jeli 很有特色的能力。它不是简单时间线，而是“基于证据构建事故叙事”。核心点包括：

- 导入 Slack 等原始数据
- 通过 Event Marker 组织叙事
- Marker 类型包括：
  - Detection
  - Diagnosis
  - Repair
  - Key Moment
- 每个 Marker 可包含：
  - 摘要
  - Supporting Evidence
  - Supplemental Evidence
  - Notes
  - 时间点或时间范围
- 支持按参与者、来源、标签检索证据
- 支持复盘会议时直接展示和讲解

这个能力对于 AIOps 非常重要，因为它让“故障经过”变成结构化知识，而不是散落在聊天记录里。

### 10.5 Key Roles 与参与人分析

Jeli 在复盘里单独强调：

- 关键角色是谁
- 谁在什么阶段参与了 Incident
- 谁承担了调查者/指挥者/沟通者职责

这对组织学习和流程优化很有价值。

### 10.6 Takeaways 与 Action Items

PagerDuty 把复盘结论分成两个层面：

- `Takeaways`：经验、发现、主题
- `Action Items`：后续必须落实的动作

Action Items 既可以是：

- 纯文本 quick items
- 也可以对接 Jira 创建或绑定工单

这一点非常值得直接复刻。很多平台停留在“写复盘文档”，但没有把行动项拉通到工程系统。

### 10.7 复盘附件与导出

PagerDuty 支持：

- 上传 PDF、TXT、VTT 等附件
- 导出 PDF 报告
- 自定义导出章节顺序

这类能力不是 MVP 必需，但对企业交付和审计非常重要。

## 11. 分析报表与管理洞察

PagerDuty 提供 `Insights`，主要面向管理和运营改进，包含：

- Incident Activity
- Service Performance
- Responder
- Team
- Escalation Policy
- Business Impact

这意味着系统不仅服务一线值班人，还服务管理者。

建议你的产品在基础版本至少统计：

- Incident 数量
- MTTA / MTTR
- 升级次数
- 值班命中率
- 服务级故障分布
- 响应人工作量

后续可以扩展到：

- 团队维度表现
- 升级策略合理性分析
- 业务服务影响分析

## 12. 按复刻优先级给出的产品范围建议

下面是更适合你当前阶段的拆分方式。

### 12.1 第一阶段：先复刻 PagerDuty 的基础闭环

这是最值得先做的范围。

#### 必须有

- 事件接入 API
- 统一事件模型
- `Event -> Alert -> Incident` 基础链路
- 路由规则
- 去重 `dedup_key`
- 抑制/暂停/默认兜底策略
- `Service`
- `Schedule`
- `EscalationPolicy`
- 当前 on-call 计算
- 多渠道通知基础能力
- Incident 状态流转
- Incident Timeline
- 手工声明 Incident
- 添加响应人
- 订阅人与状态更新
- 基础复盘记录
- 基础统计报表

#### 第一阶段最好有

- 自定义字段
- 模板化状态更新
- 角色分配
- 工作流触发点
- 复盘行动项

### 12.2 第二阶段：补齐 PagerDuty 的企业级体验

- 多层排班 `layer`
- 覆盖缺口检测
- round robin
- handoff 通知
- Incident Roles 全量能力
- Incident Tasks
- Internal Status Page
- Postmortem 模板
- 导出 PDF 报告
- Jira / ITSM 双向集成

### 12.3 第三阶段：进入 AIOps 增强

当基础 Incident Management 稳定后，再叠加 AIOps 更合理。建议的 AIOps 增强点包括：

- 智能告警聚合
- 相似 Incident 检索
- Probable Origin / 可能根因推荐
- 关联近期变更
- 告警降噪与异常检测
- 自动填充 Incident 摘要和状态更新
- 自动生成复盘初稿
- 自动提取行动项建议
- 自动推荐 responder / escalation policy
- 自动运行诊断工作流

换句话说，AIOps 应建立在以下基础能力之上：

- 结构化事件
- 结构化 Incident
- 可靠时间线
- 历史复盘数据
- 服务拓扑与变更数据

如果没有这些底座，AIOps 只会变成“会说话的告警页面”。

## 13. 建议你优先复刻的功能清单

如果你现在要做一个“先像 PagerDuty，再逐步进化到 AIOps”的产品，我建议优先级如下：

### P0

- 事件接入
- 编排路由
- 去重与抑制
- 服务管理
- 值班排班
- 升级策略
- 多渠道通知
- Incident 生命周期
- Timeline

### P1

- 添加响应人
- Incident 角色
- 干系人订阅
- 状态更新
- 模板化通报
- 基础复盘
- 行动项跟踪

### P2

- 复杂排班 layer
- 任务系统
- 复盘叙事构建
- 复盘阶段流转
- 报表洞察
- Slack / Teams / Jira 深度联动

### P3

- 智能聚合
- 智能根因建议
- 智能状态更新生成
- 智能复盘初稿
- 自动化诊断与修复编排

## 14. 对 AIOps 设计的直接启发

PagerDuty 给你的最大启发，不是某个单点功能，而是产品层次顺序：

1. 先把 Incident Management 做扎实。
2. 再把 Automation 接上。
3. 最后再把 AIOps 做成增强层，而不是替代底层模型。

因此你的 AIOps 平台设计更合理的路径应是：

- 第一层：事件接入与标准化
- 第二层：编排、值班、升级、协同
- 第三层：复盘、知识沉淀、行动项闭环
- 第四层：AIOps 智能增强

这比一上来就强调“AI Agent 自动处理故障”更容易真正落地。

## 15. 结论

如果把 PagerDuty 的核心功能提炼成一句话，它不是“告警平台”，而是“围绕 Incident 生命周期的编排与协作平台”。

对于你的产品路线，最合理的做法是：

1. 先复刻它的基础闭环：事件编排、值班升级、Incident 协同、复盘沉淀。
2. 再在这些结构化数据之上叠加 AIOps：聚合、关联、根因、推荐、自动化。

如果继续往下做，我建议下一份文档直接接这个主题，写成：

- `PagerDuty_MVP_产品需求清单.md`

里面把本文件再进一步收敛成：

- MVP 必做功能
- 页面清单
- 核心对象模型
- 后端服务拆分建议
- AIOps 二期能力边界

## 16. 参考来源

以下内容主要参考 PagerDuty 官方公开资料：

- Event Orchestration
- Incidents
- Schedule Basics
- Escalation Policy Basics
- Add Responders
- Communicate with Stakeholders
- Status Update Templates
- Incident Roles
- Incident Tasks
- Jeli Post-Incident Reviews and Postmortems
- Post-Incident Review Report
- Post-Incident Review Stages
- Collect Action Items
- Narrative Builder
- Insights