课程 4.6 - 运营事件等级

故事

不是每个问题都是 P1

一位客户投诉一笔订单延迟。另一位 Dealer 未经验证就报告“系统宕机”。与此同时，真正的报价源全面断开影响多个产品。

交易台需要一个统一的严重度与紧急性语言。

严重度模型

严重等级	示例	典型响应
P4	孤立小问题，无广泛影响	记录并监控
P3	对少量产品或客户产生有限影响	调查并通知当班负责人或指定负责人
P2	对产品、客户组或系统功能产生实质影响	跨团队升级
P1	交易、连接或风险层面出现广泛影响	立即启动 Incident 管理

响应顺序

发现 → 核对

核对 → 评估影响范围

评估影响范围 → 判定严重等级

判定严重等级 → 沟通已确认事实

沟通已确认事实 → 验证授权响应结果

验证授权响应结果 → 监控恢复

监控恢复 → 记录与复盘

报告什么？

每条初始 Incident Update 应包括：

• 时间。
• 观察到什么。
• 受影响系统 / 产品 / 客户范围。
• 已验证事实。
• 当前影响。
• 已采取行动。
• 下次更新时间。

案例

报价源全面断连

观察结果：

• 多个产品失去报价源 B 的报价参与；
• Bridge 日志显示报价源会话断开；
• 路由已切换至获批备用路径；
• 受影响产品点差扩大；
• 当前客户影响有限，但潜在风险较高。

初步等级：

初步判定为 P2；如果备用路由无法维持成交质量，则升级等级。

常见错误

• 未经核对就判定为 P1。
• 因单一界面显示正常而低估广泛影响。
• 将意见当作已确认事实进行汇报。
• 未说明影响范围和下一步动作。
• 未监控恢复情况就关闭 Incident。

实战训练

真实场景

单一报价源异常但备用报价源正常，点差略有扩大。

Dealer 应该看的证据

影响产品、报价源数量、成交是否可用、客户影响、Exposure 影响、恢复情况。

错误示范

把所有报价源问题都报成 P1。

正确处理

根据范围和影响判定严重度；能交易且影响有限时按 P3/P2 处理并持续监控。

总结

事件等级用于帮助团队根据已确认的范围和影响采取相称响应。正确分类始于事实核对、影响评估和清晰沟通，并应随着新证据和恢复情况及时调整。

完成标准

• 能说明本课的核心风险或操作目的
• 能指出需要查看的系统、数据或证据
• 能说明正确的升级或处理方式
• 能在模拟或实际指导场景中按流程处理