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