# PagerDuty MVP 产品需求清单

## 1. 文档目标

本文档基于 `PagerDuty_Feature_Breakdown_and_Replication_Requirements.md`，
进一步收敛出一个可执行的 PagerDuty 风格 Incident Management MVP 范围。

本文档重点回答四个问题：

1. 第一版产品到底做什么。
2. 哪些能力必须在 MVP 就做。
3. 哪些能力可以推迟到第二阶段。
4. 产品、设计、研发在实现时要围绕哪些核心对象和页面展开。

适用对象：

- 产品经理
- 架构师
- 后端开发
- 前端开发
- 测试人员

## 2. MVP 定位

### 2.1 产品定义

该 MVP 是一个面向生产故障响应场景的 Incident Management 平台，
目标是先复刻 PagerDuty 的基础闭环，而不是一步到位做成完整 AIOps 平台。

第一阶段核心定位：

- 接收事件
- 基于规则路由和编排事件
- 找到当前值班人并完成升级通知
- 驱动 Incident 响应过程
- 形成基础复盘与数据沉淀

### 2.2 MVP 不追求的事情

以下能力不建议放入第一版硬做：

- 智能根因分析
- 智能告警聚合
- AI 自动生成完整 RCA
- 自动化修复闭环
- 复杂跨系统编排中心
- 高复杂度企业门户与多租户计费

这些都应建立在基础事件与 Incident 模型稳定之后。

## 3. 目标用户

### 3.1 一线响应角色

- 值班工程师
- SRE / 运维工程师
- 平台工程师
- 应用负责人

核心诉求：

- 告警不要漏
- 告警不要太吵
- 能快速知道该谁处理
- 能快速进入处理过程

### 3.2 管理与协调角色

- 团队负责人
- Incident Commander
- 值班经理
- 产品/业务干系人

核心诉求：

- 事件是否有人接手
- 升级是否及时
- 当前影响如何
- 整体响应效率如何

### 3.3 平台管理员

- 运维平台管理员
- 规则配置管理员
- 值班表管理员

核心诉求：

- 可维护服务目录
- 可维护升级策略
- 可维护事件路由规则
- 配置变更可审计

## 4. MVP 成功标准

MVP 交付后，至少应满足以下业务结果：

1. 新事件可以通过统一接入入口进入平台。
2. 平台可以根据规则把事件路由到正确的 `Service`。
3. 平台可以根据值班表和升级策略通知到正确人员。
4. 平台可以形成完整 Incident 时间线。
5. 响应人可以更新状态、补充说明并完成关闭。
6. 平台可以输出基础运营指标，例如事件数、响应时延、恢复时长。

建议定义以下核心指标：

| 指标 | 说明 | MVP 目标 |
| --- | --- | --- |
| 事件接入成功率 | 外部事件被平台成功接收比例 | 高于 99.9% |
| 路由命中率 | 事件被正确分发到目标服务的比例 | 高于 95% |
| 值班命中率 | 通知命中当前 on-call 的比例 | 高于 99% |
| MTTA | 平均确认接手时间 | 可被统计 |
| MTTR | 平均恢复时间 | 可被统计 |
| 升级有效性 | 超时后自动升级是否生效 | 可被审计 |

## 5. 范围边界

### 5.1 MVP 必须范围

- 统一事件接入
- 基础事件标准化
- 路由与编排规则
- 去重与抑制
- 服务管理
- 值班表 `Schedule`
- 升级策略 `EscalationPolicy`
- 用户与团队管理基础能力
- 多渠道通知基础能力
- Incident 生命周期管理
- 响应人与订阅人管理
- 状态更新时间线
- 基础复盘记录
- 基础分析报表

### 5.2 MVP 可选增强

- Incident 自定义字段
- 状态更新模板
- Incident 角色
- 复盘行动项
- Webhook 回调

### 5.3 明确不在 MVP

- 智能聚合
- 复杂工单双向同步
- Narrative Builder
- 复盘导出 PDF
- Internal Status Page
- 自动修复编排
- 多层级权限中心
- 复杂多组织隔离

## 6. 核心对象模型

MVP 必须稳定实现以下对象。

| 对象 | 关键字段 | 说明 |
| --- | --- | --- |
| `Event` | source, title, severity, payload, dedup_key | 外部输入原始事件 |
| `Alert` | status, fingerprint, service_id | 平台内部标准告警 |
| `Incident` | title, service_id, status, priority, assignee | 需要响应的问题实体 |
| `Service` | name, description, escalation_policy_id | 服务目录对象 |
| `Schedule` | timezone, layers, participants | 值班表 |
| `EscalationPolicy` | rules, repeat_count, targets | 升级规则链 |
| `User` | contact_methods, notification_rules | 用户对象 |
| `Team` | name, members | 团队对象 |
| `Responder` | user_id, incident_id, response_status | 响应关系 |
| `Subscriber` | user_id/team_id, incident_id | 订阅关系 |
| `StatusUpdate` | incident_id, message, channels | 状态更新 |
| `PostIncidentReview` | incident_id, summary, owner, stage | 复盘对象 |

## 7. MVP 功能需求

## 7.1 事件接入

### 7.1.1 接入方式

系统应支持：

- Events API / Webhook 接入
- Web 控制台手工创建 Incident

建议暂不支持：

- 邮件入口
- IM 命令入口

### 7.1.2 接入字段要求

最小事件字段建议如下：

- `summary`
- `source`
- `severity`
- `timestamp`
- `dedup_key`
- `component`
- `group`
- `class`
- `custom_details`

### 7.1.3 验收标准

1. 外部事件可通过 API 成功写入。
2. 原始 payload 可审计。
3. 标准字段和原始字段都能查看。
4. 非法请求能返回明确错误。

## 7.2 事件编排与路由

### 7.2.1 规则模型

MVP 应支持以下规则能力：

- 条件匹配
- 顺序命中
- 默认兜底规则
- 启用/停用规则
- 规则优先级排序

### 7.2.2 条件类型

- 等于
- 不等于
- 包含
- 不包含
- 正则匹配
- 数值比较

### 7.2.3 动作类型

- 路由到指定 `Service`
- 触发 `Incident`
- 抑制事件
- 丢弃事件
- 变更优先级
- 写入说明 note
- 设置/覆盖 `dedup_key`
- 写入自定义上下文字段

### 7.2.4 验收标准

1. 能创建、修改、排序和禁用规则。
2. 事件命中后能查看命中规则轨迹。
3. 未命中事件有明确兜底行为。
4. 被抑制或丢弃的事件可审计。

## 7.3 服务目录 `Service`

### 7.3.1 服务能力

每个 `Service` 至少支持：

- 名称
- 描述
- 所属团队
- 默认升级策略
- 当前状态概览
- 最近 Incident 列表

### 7.3.2 验收标准

1. 管理员可创建服务。
2. 服务可绑定升级策略。
3. 事件可路由到服务。
4. 服务维度可查看历史 Incident。

## 7.4 值班表 `Schedule`

### 7.4.1 MVP 能力

- 创建值班表
- 设置时区
- 设置轮值人
- 设置轮转周期
- 设置开始时间
- 预览当前和未来 on-call

### 7.4.2 第一版简化策略

第一版可以先不做复杂 `layer` 模型，但必须保留后续扩展空间。

建议第一版先支持：

- 单层排班
- 顺序轮转
- 基础 override

### 7.4.3 验收标准

1. 系统可计算任意时间点 on-call 用户。
2. 当前 on-call 在 UI 中可直接查看。
3. 排班修改后，新触发事件使用最新排班。
4. 可对单个时段进行临时替班。

## 7.5 升级策略 `EscalationPolicy`

### 7.5.1 MVP 能力

- 多级升级链
- 每级目标可配置为用户或值班表
- 每级升级等待时间可配置
- 未响应自动升级
- 有人确认后停止升级

### 7.5.2 行为要求

- Incident 在触发时生成升级快照
- 已打开 Incident 不受后续策略修改影响
- 每次升级动作进入 Timeline

### 7.5.3 验收标准

1. 可配置至少 3 级升级规则。
2. 到达超时阈值后自动通知下一级。
3. 响应后升级停止。
4. 每一级通知结果可追踪。

## 7.6 通知能力

### 7.6.1 渠道范围

MVP 建议支持：

- Email
- Web / Push 站内通知
- Webhook 回调

SMS / Phone 可以第二阶段接入。

### 7.6.2 通知规则

- 平台决定通知目标
- 用户配置接收方式
- 每次通知有发送状态
- 失败重试可配置

### 7.6.3 验收标准

1. 触发 Incident 后可通知到正确用户。
2. 通知日志可查。
3. 失败有重试和失败记录。

## 7.7 Incident 管理

### 7.7.1 状态流转

MVP 至少支持：

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

### 7.7.2 Incident 页面最小能力

- 查看标题、服务、优先级、当前状态
- 查看 assignee / responders
- 查看订阅人
- 查看状态更新时间线
- 追加 note
- 手工变更状态

### 7.7.3 Timeline

以下动作必须进入统一时间线：

- 事件触发
- 规则命中
- 路由结果
- 通知发送
- 升级动作
- 响应确认
- 状态更新
- 备注添加
- 解决与重开

### 7.7.4 验收标准

1. Incident 可以被手工创建和自动创建。
2. Incident 详情页能展示完整时间线。
3. 状态流转被审计。
4. 重开 Incident 后保留历史轨迹。

## 7.8 响应人与订阅人

### 7.8.1 响应人

MVP 应支持：

- 增加响应人
- 移除响应人
- 查看响应状态

### 7.8.2 订阅人

MVP 应支持：

- 增加用户订阅人
- 增加团队订阅人
- 订阅人接收状态更新

### 7.8.3 验收标准

1. Incident 可以追加响应人。
2. Incident 可以追加订阅人。
3. 响应人与订阅人的通知语义有区分。

## 7.9 状态更新

### 7.9.1 状态更新能力

- 发布状态更新
- 查看历史状态更新
- 选择通知渠道
- 标记下一次更新时间

### 7.9.2 验收标准

1. 响应人可主动发布状态更新。
2. 订阅人可收到状态更新通知。
3. 状态更新进入 Incident Timeline。

## 7.10 基础复盘

### 7.10.1 MVP 能力

- 从已解决 Incident 创建复盘记录
- 记录 Summary
- 指定复盘负责人
- 维护复盘状态
- 记录 Takeaways
- 记录 Action Items

### 7.10.2 第一版简化

第一版不需要 Narrative Builder，但要保证复盘至少不是一段自由文本。

建议保留字段：

- Incident summary
- What happened
- Impact
- What worked well
- What was confusing
- Action items

### 7.10.3 验收标准

1. 已解决 Incident 可创建复盘。
2. 复盘有负责人和状态。
3. 行动项可记录和追踪状态。

## 7.11 分析报表

### 7.11.1 MVP 指标面板

至少提供以下维度：

- Incident 总量趋势
- 服务维度 Incident 分布
- MTTA
- MTTR
- 升级次数
- 响应人工作量

### 7.11.2 验收标准

1. 数据可按时间范围筛选。
2. 数据可按服务筛选。
3. 数据口径可解释。

## 8. 非功能要求

### 8.1 审计要求

以下操作必须审计：

- 规则变更
- 升级策略变更
- 值班表变更
- Incident 状态变更
- 复盘状态变更

### 8.2 权限要求

MVP 建议先支持三类角色：

- 平台管理员
- 团队管理员
- 普通响应用户

### 8.3 可用性要求

- 事件接入链路高可用
- 通知链路失败可重试
- 核心查询接口响应可接受

### 8.4 可扩展性要求

技术设计上应为以下二期能力预留扩展：

- 智能聚合
- AI 总结
- 自动化工作流
- 更多通知渠道
- 多层排班模型

## 9. 推荐的首批页面

MVP 至少应有以下页面：

1. 登录页
2. 事件/Incident 总览页
3. Incident 详情页
4. 服务列表页
5. 服务详情页
6. 值班表列表页
7. 值班表详情页
8. 升级策略列表页
9. 升级策略详情页
10. 事件编排规则页
11. 用户与团队页
12. 分析报表页
13. 复盘列表页
14. 复盘详情页

## 10. 二期建议

MVP 稳定后，建议优先进入以下二期能力：

1. 多层排班与 follow-the-sun
2. Incident Roles
3. Status Update Templates
4. Jira 集成
5. 更强的复盘模块
6. AIOps 智能增强

## 11. 结论

PagerDuty 风格产品的第一版，不应该被定义成“告警通知系统”，而应该定义成“从事件进入到事件关闭的基础响应平台”。

对 MVP 来说，最重要的是把下面四个闭环打通：

1. 事件进入
2. 规则路由
3. 值班升级
4. Incident 响应与沉淀

只要这四个闭环稳定，后续加自动化、AIOps、根因分析才有真正的落点。