552 lines
12 KiB
Markdown
552 lines
12 KiB
Markdown
|
# 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、根因分析才有真正的落点。
|