add workflow planning docs

2026-03-30 18:01:34 +08:00
parent 32c7c7840d
commit 4c16118712
7 changed files with 1236 additions and 8 deletions
--- a/pagerduty/PagerDuty_MVP_Product_Requirements.md
+++ b/pagerduty/PagerDuty_MVP_Product_Requirements.md
@@ -0,0 +1,551 @@
+# 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、根因分析才有真正的落点。