From 32c7c7840d628a0e28aa4700e1c4c9eefa9bf954 Mon Sep 17 00:00:00 2001
From: "guangfei.zhao" <guangfei.zhao@t-systems.com>
Date: Mon, 30 Mar 2026 16:52:54 +0800
Subject: [PATCH] add pagerduty planning docs

---
 pagerduty/PagerDuty_MVP_产品需求清单.md   | 551 ++++++++++++++
 pagerduty/PagerDuty_功能拆解与复刻需求.md | 876 ++++++++++++++++++++++
 pagerduty/PagerDuty_页面与信息架构设计.md | 665 ++++++++++++++++
 3 files changed, 2092 insertions(+)
 create mode 100644 pagerduty/PagerDuty_MVP_产品需求清单.md
 create mode 100644 pagerduty/PagerDuty_功能拆解与复刻需求.md
 create mode 100644 pagerduty/PagerDuty_页面与信息架构设计.md

diff --git a/pagerduty/PagerDuty_MVP_产品需求清单.md b/pagerduty/PagerDuty_MVP_产品需求清单.md
new file mode 100644
index 0000000..0f9e2b0
--- /dev/null
+++ b/pagerduty/PagerDuty_MVP_产品需求清单.md
@@ -0,0 +1,551 @@
+# 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、根因分析才有真正的落点。
diff --git a/pagerduty/PagerDuty_功能拆解与复刻需求.md b/pagerduty/PagerDuty_功能拆解与复刻需求.md
new file mode 100644
index 0000000..4276f81
--- /dev/null
+++ b/pagerduty/PagerDuty_功能拆解与复刻需求.md
@@ -0,0 +1,876 @@
+# 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_产品需求清单.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
diff --git a/pagerduty/PagerDuty_页面与信息架构设计.md b/pagerduty/PagerDuty_页面与信息架构设计.md
new file mode 100644
index 0000000..8c71afc
--- /dev/null
+++ b/pagerduty/PagerDuty_页面与信息架构设计.md
@@ -0,0 +1,665 @@
+# PagerDuty 页面与信息架构设计
+
+## 1. 文档目标
+
+本文档在 `PagerDuty_MVP_产品需求清单.md` 基础上，定义 PagerDuty 风格 Incident Management MVP 的页面结构、导航方式、核心信息组织方式和关键页面布局。
+
+目标是帮助产品、设计和研发统一以下内容：
+
+1. 整个产品有哪些主要页面。
+2. 这些页面如何通过导航组织起来。
+3. 每个页面最重要的信息模块是什么。
+4. 用户完成关键任务时会经过哪些页面。
+
+## 2. 信息架构设计原则
+
+### 2.1 以 Incident 为中心
+
+系统中的大部分操作最终都应回到 `Incident`：
+
+- 事件进来是为了产生或更新 Incident
+- 值班和升级是为了找到 Incident 的处理人
+- 状态更新和订阅是围绕 Incident 协同
+- 复盘是 Incident 关闭后的延续
+
+因此导航和页面设计都应让用户快速进入 Incident。
+
+### 2.2 以任务流而不是配置流组织页面
+
+用户最常见的任务顺序不是“先配规则，再看用户，再看服务”，而是：
+
+1. 看见问题
+2. 确认谁在处理
+3. 找到上下文
+4. 继续协作
+5. 最后回看规则或排班是否合理
+
+因此首页和主导航应优先暴露运行态页面，而不是后台配置页。
+
+### 2.3 运行态与配置态分离
+
+建议把产品分成两种视角：
+
+- 运行态
+  - Incidents
+  - Services
+  - On-call
+  - Reports
+  - Reviews
+- 配置态
+  - Event Orchestration
+  - Escalation Policies
+  - Schedules
+  - Users / Teams
+
+这样能避免管理配置和处理故障混在一起。
+
+## 3. 顶层导航建议
+
+MVP 推荐左侧一级导航如下：
+
+1. `Incidents`
+2. `Services`
+3. `On-call`
+4. `Reviews`
+5. `Analytics`
+6. `Settings`
+
+其中 `Settings` 下再承载配置型模块。
+
+### 3.1 一级导航含义
+
+| 一级导航 | 目标用户 | 核心价值 |
+| --- | --- | --- |
+| `Incidents` | 一线响应人、团队负责人 | 看当前故障、处理故障 |
+| `Services` | 服务负责人、管理员 | 看服务与关联 Incident |
+| `On-call` | 值班人、排班管理员 | 看当前值班与排班 |
+| `Reviews` | 负责人、管理者 | 管理复盘与行动项 |
+| `Analytics` | 管理者、平台运营 | 查看运营指标 |
+| `Settings` | 管理员 | 管理编排、升级、人员等配置 |
+
+## 4. 页面地图
+
+## 4.1 一级页面结构
+
+```text
+Incidents
+  Incident List
+  Incident Detail
+  Create Incident
+
+Services
+  Service List
+  Service Detail
+  Create/Edit Service
+
+On-call
+  On-call Overview
+  Schedule List
+  Schedule Detail
+  Escalation Policy List
+  Escalation Policy Detail
+
+Reviews
+  Review List
+  Review Detail
+
+Analytics
+  Dashboard
+
+Settings
+  Event Orchestration
+  Users
+  Teams
+  Notification Settings
+  Audit Log
+```
+
+## 4.2 关键跳转关系
+
+- Incident List -> Incident Detail
+- Incident Detail -> Service Detail
+- Incident Detail -> Review Detail
+- Service Detail -> Escalation Policy Detail
+- Escalation Policy Detail -> Schedule Detail
+- On-call Overview -> Schedule Detail
+- Review Detail -> Incident Detail
+
+## 5. 页面详细设计
+
+## 5.1 `Incidents` 列表页
+
+### 5.1.1 页面目标
+
+这是最重要的运行态入口，用户要能在这里快速回答：
+
+- 现在有哪些未关闭 Incident
+- 哪些最紧急
+- 哪些无人接手
+- 哪些已经在升级
+
+### 5.1.2 页面模块
+
+建议包含以下区域：
+
+1. 顶部筛选栏
+2. 统计摘要卡片
+3. Incident 列表表格
+4. 快速操作区
+
+### 5.1.3 筛选条件
+
+- 状态
+- 优先级
+- 服务
+- 团队
+- 是否已确认
+- 是否升级中
+- 时间范围
+
+### 5.1.4 列表字段
+
+- Incident 标题
+- 服务
+- 状态
+- 优先级
+- 当前 assignee
+- 当前 on-call
+- 触发时间
+- 最近更新时间
+- 升级层级/升级状态
+
+### 5.1.5 快速操作
+
+- 创建 Incident
+- Acknowledge
+- Resolve
+- Add responder
+- Add subscriber
+
+## 5.2 `Incident Detail` 详情页
+
+### 5.2.1 页面目标
+
+这是平台最核心的页面，用户要在一个页面内完成大部分响应动作。
+
+### 5.2.2 页面布局建议
+
+建议采用三栏或二栏布局。
+
+方案 A：三栏布局
+
+- 左栏：基础信息和状态卡
+- 中栏：Timeline 与状态更新
+- 右栏：响应人、订阅人、关联对象
+
+方案 B：二栏布局
+
+- 主栏：Timeline
+- 侧栏：基础信息 + 人员 + 快速操作
+
+MVP 建议先做二栏布局，复杂度更低。
+
+### 5.2.3 顶部头部信息
+
+- Incident 标题
+- 状态标签
+- 优先级
+- 所属服务
+- 创建时间
+- 当前负责人
+
+### 5.2.4 侧栏模块
+
+- 基础信息卡片
+- Responders
+- Subscribers
+- Escalation 状态
+- 关联链接
+  - Service
+  - Schedule
+  - Escalation Policy
+  - Review
+
+### 5.2.5 主栏模块
+
+- Status Updates
+- Unified Timeline
+- Notes
+
+### 5.2.6 页面动作
+
+- Acknowledge
+- Resolve
+- Reopen
+- Add responder
+- Add subscriber
+- Publish status update
+- Add note
+- Create review
+
+## 5.3 `Create Incident` 页面/弹窗
+
+### 5.3.1 页面目标
+
+允许用户手工声明事故，不依赖外部事件接入。
+
+### 5.3.2 表单字段
+
+- 标题
+- 服务
+- 优先级
+- 描述
+- 指派对象
+  - 用户或升级策略
+- 附加响应人
+- 订阅人
+
+### 5.3.3 交互建议
+
+MVP 可采用右侧抽屉或模态框，不必单独做复杂页面。
+
+## 5.4 `Services` 列表页
+
+### 5.4.1 页面目标
+
+用于查看和维护服务对象，回答：
+
+- 系统里有哪些服务
+- 每个服务归谁负责
+- 当前是否有打开的 Incident
+
+### 5.4.2 列表字段
+
+- 服务名
+- 所属团队
+- 默认升级策略
+- 当前 on-call
+- 打开 Incident 数
+
+### 5.4.3 页面动作
+
+- 创建服务
+- 编辑服务
+- 查看服务详情
+
+## 5.5 `Service Detail` 页面
+
+### 5.5.1 页面目标
+
+展示一个服务的运行态概况和配置入口。
+
+### 5.5.2 页面模块
+
+- 服务基础信息
+- 关联升级策略
+- 当前 on-call
+- 最近 Incident
+- 服务维度指标卡
+
+### 5.5.3 关键跳转
+
+- 跳转到 `Escalation Policy Detail`
+- 跳转到 `Schedule Detail`
+- 跳转到该服务的 Incident 列表
+
+## 5.6 `On-call Overview` 页面
+
+### 5.6.1 页面目标
+
+快速回答：
+
+- 现在谁在值班
+- 哪些服务的 on-call 正常
+- 有没有排班空洞
+
+### 5.6.2 页面模块
+
+- 当前 on-call 总览
+- 即将交班提醒
+- 关键服务 on-call 列表
+- 异常排班提示
+
+### 5.6.3 适合用户
+
+- 值班经理
+- 团队负责人
+- 平台管理员
+
+## 5.7 `Schedule List` 列表页
+
+### 5.7.1 列表字段
+
+- 值班表名称
+- 时区
+- 当前 on-call
+- 下一位 on-call
+- 最近更新时间
+
+### 5.7.2 页面动作
+
+- 创建值班表
+- 编辑值班表
+- 查看排班详情
+
+## 5.8 `Schedule Detail` 详情页
+
+### 5.8.1 页面目标
+
+帮助管理员理解和维护排班结构。
+
+### 5.8.2 页面模块
+
+- 基础信息卡片
+- 当前 on-call 信息
+- 排班时间视图
+- 临时替班管理
+- 关联升级策略列表
+
+### 5.8.3 页面布局建议
+
+- 顶部摘要卡
+- 中部日历/时间轴
+- 下部参与人配置区
+
+## 5.9 `Escalation Policy List` 列表页
+
+### 5.9.1 页面目标
+
+用于维护升级规则链。
+
+### 5.9.2 列表字段
+
+- 策略名称
+- 关联服务数
+- 规则级数
+- 更新时间
+
+## 5.10 `Escalation Policy Detail` 详情页
+
+### 5.10.1 页面目标
+
+清晰展示升级链结构，让管理员一眼知道超时后会通知谁。
+
+### 5.10.2 页面模块
+
+- 基础信息
+- 升级层级可视化
+- 关联服务
+- 关联值班表
+
+### 5.10.3 可视化建议
+
+建议采用纵向步骤流：
+
+```text
+Level 1 -> wait 5m -> Level 2 -> wait 10m -> Level 3
+```
+
+比表格更适合理解升级链。
+
+## 5.11 `Event Orchestration` 页面
+
+### 5.11.1 页面目标
+
+让管理员维护事件路由与编排规则。
+
+### 5.11.2 页面结构建议
+
+- 顶部规则说明区
+- 规则列表
+- 规则详情编辑抽屉
+- 测试事件模拟区
+
+### 5.11.3 列表字段
+
+- 规则名称
+- 状态
+- 优先级
+- 条件摘要
+- 动作摘要
+- 更新时间
+
+### 5.11.4 MVP 特别建议
+
+即使第一版不做复杂可视化规则编辑器，也最好提供：
+
+- 条件摘要展示
+- 命中结果预览
+- 测试样例事件
+
+否则规则很难维护。
+
+## 5.12 `Users` 页面
+
+### 5.12.1 列表字段
+
+- 用户名
+- 邮箱
+- 团队
+- 联系方式状态
+- 当前是否 on-call
+
+### 5.12.2 详情能力
+
+- 联系方式配置
+- 通知方式偏好
+- 所属团队
+- 关联值班表
+
+## 5.13 `Teams` 页面
+
+### 5.13.1 页面模块
+
+- 团队列表
+- 成员列表
+- 关联服务
+- 关联升级策略
+
+## 5.14 `Reviews` 列表页
+
+### 5.14.1 页面目标
+
+帮助团队查看哪些 Incident 已复盘，哪些还未完成。
+
+### 5.14.2 筛选条件
+
+- 复盘状态
+- 所属团队
+- 服务
+- 时间范围
+
+### 5.14.3 列表字段
+
+- 复盘标题
+- 关联 Incident
+- 负责人
+- 状态
+- 最近更新时间
+
+## 5.15 `Review Detail` 页面
+
+### 5.15.1 页面目标
+
+承载 MVP 版复盘记录与行动项。
+
+### 5.15.2 页面模块
+
+- 基础信息
+- Incident 摘要
+- 时间与影响
+- Takeaways
+- Action Items
+- 状态流转
+
+### 5.15.3 第一版建议
+
+MVP 不做复杂多标签页，直接一个长页即可，降低实现复杂度。
+
+## 5.16 `Analytics Dashboard` 页面
+
+### 5.16.1 页面目标
+
+面向负责人和管理者展示运行指标。
+
+### 5.16.2 页面模块
+
+- 指标卡
+  - Incident 总量
+  - MTTA
+  - MTTR
+  - 升级次数
+- 趋势图
+- 服务排行
+- 响应人负载分布
+
+## 5.17 `Audit Log` 页面
+
+### 5.17.1 页面目标
+
+给管理员查看核心配置变更与关键运行事件。
+
+### 5.17.2 页面范围
+
+- 规则配置变更
+- 值班表变更
+- 升级策略变更
+- Incident 关键状态变更
+
+## 6. 核心用户任务流
+
+## 6.1 任务流一：处理新 Incident
+
+```text
+Incident List
+  -> Incident Detail
+  -> Acknowledge
+  -> Add responder / Publish status update
+  -> Resolve
+  -> Create review
+```
+
+## 6.2 任务流二：排查通知为什么没命中
+
+```text
+Incident Detail
+  -> Service Detail
+  -> Escalation Policy Detail
+  -> Schedule Detail
+```
+
+## 6.3 任务流三：新增一个服务接入
+
+```text
+Services
+  -> Create Service
+  -> Bind Escalation Policy
+  -> Configure Event Orchestration Rule
+  -> Send test event
+```
+
+## 6.4 任务流四：进行复盘
+
+```text
+Incident Detail
+  -> Create Review
+  -> Review Detail
+  -> Add Takeaways
+  -> Add Action Items
+  -> Mark Completed
+```
+
+## 7. 信息层级建议
+
+### 7.1 Incident 详情页的信息优先级
+
+P0 信息：
+
+- 当前状态
+- 谁在处理
+- 服务
+- 最近状态更新
+- 时间线
+
+P1 信息：
+
+- 升级情况
+- 订阅人
+- 关联复盘
+
+P2 信息：
+
+- 详细配置关系
+- 历史关联对象
+
+### 7.2 配置页面的信息优先级
+
+P0 信息：
+
+- 当前配置是什么
+- 影响哪些对象
+- 是否启用
+
+P1 信息：
+
+- 编辑历史
+- 测试验证结果
+
+## 8. 设计与前端实现建议
+
+### 8.1 MVP 优先用表格 + 详情页
+
+对这类运维产品，第一版不需要追求过度炫技的卡片化布局。对 Incident、Service、Schedule、Policy 这类对象，`列表 + 详情` 是最稳的结构。
+
+### 8.2 时间线组件应尽早统一
+
+Incident Timeline 是全系统最关键的基础展示组件，建议尽早沉淀统一样式，复用到：
+
+- Incident 详情
+- 复盘详情
+- 审计视图
+
+### 8.3 关系跳转要强
+
+这类产品的用户经常在对象之间来回跳转，因此页面内应加强：
+
+- Service 链接
+- Schedule 链接
+- Escalation Policy 链接
+- Review 链接
+
+不要让用户只能靠返回列表找对象。
+
+## 9. MVP 页面清单总结
+
+推荐首批交付页面如下：
+
+1. `Incident List`
+2. `Incident Detail`
+3. `Create Incident`
+4. `Service List`
+5. `Service Detail`
+6. `On-call Overview`
+7. `Schedule List`
+8. `Schedule Detail`
+9. `Escalation Policy List`
+10. `Escalation Policy Detail`
+11. `Event Orchestration`
+12. `Users`
+13. `Teams`
+14. `Review List`
+15. `Review Detail`
+16. `Analytics Dashboard`
+17. `Audit Log`
+
+## 10. 结论
+
+如果从信息架构角度总结 PagerDuty 风格产品，最关键的不是页面多，而是“是否让用户在最短路径上找到故障、找到责任人、找到上下文、找到下一步动作”。
+
+因此 MVP 页面设计应坚持三个原则：
+
+1. 运行态优先于配置态。
+2. Incident 详情页优先于花哨首页。
+3. 对象之间必须强链接跳转。
+
+只要这三点做对，后续再扩展 Status Page、Narrative Builder、AIOps 面板都会比较自然。