课程 4.6 - 运营事件等级¶
Scenario｜故事¶
不是每个问题都是 P1¶
一位客户投诉一笔订单延迟。另一位 Dealer 未经验证就报告“系统宕机”。与此同时，真正的 报价源 全面断开影响多个产品。
交易台需要一个统一的严重度与紧急性语言。
Severity Model｜严重度模型¶
| Severity | 项目 | Typical Response |
|---|---|---|
| P4 | 孤立小问题，无广泛影响 | 记录并监控 |
| P3 | 对少量产品或客户产生有限影响 | 调查并通知Shift Leader / 当班负责人 |
| P2 | 对产品、客户组或系统功能产生实质影响 | 跨团队升级 |
| P1 | 交易、连接或风险层面出现广泛影响 | 立即启动 Incident 管理 |
Response Sequence｜响应顺序¶
Detect
→
Verify
Verify
→
Assess Scope
Scope
→
Classify Severity
Severity
→
Communicate Facts
Communicate
→
Execute Approved Response
Act
→
Monitor Recovery
Monitor
→
Document / Review
What to Report｜报告什么？¶
每条初始 Incident Update 应包括：
- 时间。
- 观察到什么。
- 受影响系统/产品/客户范围。
- 已验证事实。
- 当前影响。
- 已采取行动。
- 下次更新时间。
Case Study｜案例¶
报价源全面断连¶
Common Mistakes｜常见错误¶
实战训练¶
真实场景
单一 报价源异常但备用 报价源 正常，点差略有扩大。
Dealer 应该看的证据
影响产品、报价源 数量、成交是否可用、客户影响、Exposure 影响、恢复情况。
错误示范
把所有 报价源 问题都报成 P1。
正确处理
根据范围和影响判定严重度；能交易且影响有限时按 P3/P2 处理并持续监控。
Summary｜总结¶
完成 4 Module A
完成标准¶
- 能说明本课的核心风险或操作目的
- 能指出需要查看的系统、数据或证据
- 能说明正确的升级或处理方式
- 已完成 Shift Leader / 当班负责人抽查或实操确认