877 lines
23 KiB
Markdown
877 lines
23 KiB
Markdown
# 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_Product_Requirements.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
|