aiops-docs/pagerduty/PagerDuty_MVP_产品需求清单.md

PagerDuty MVP 产品需求清单

1. 文档目标

本文档基于 PagerDuty_功能拆解与复刻需求.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、根因分析才有真正的落点。