add workflow planning docs
This commit is contained in:
667
pagerduty/PagerDuty_Information_Architecture_and_Page_Design.md
Normal file
667
pagerduty/PagerDuty_Information_Architecture_and_Page_Design.md
Normal file
@@ -0,0 +1,667 @@
|
||||
# PagerDuty 页面与信息架构设计
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本文档在 `PagerDuty_MVP_Product_Requirements.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 面板都会比较自然。
|
||||
Reference in New Issue
Block a user