课程 5.4 - 事件后复盘¶
目的¶
事故复盘不是找人背锅，而是记录发生了什么、影响了什么、哪些控制有效或失效，以及后续应该如何改进。
学习目标¶
- 建立事实型 Incident 时间线。
- 识别根因、促成因素和控制缺口。
- 为纠正行动指定责任人和截止日期。
事故复盘结构¶
Incident 已关闭
→
建立时间线
Timeline
→
确认事实 / 证据
Facts
→
根因分析
Root
→
促成因素
Factors
→
控制评估
Controls
→
纠正 / 预防动作
Actions
→
Assign Shift Leader / 当班负责人 / Due Date
负责人
→
跟进复核
五个复盘问题¶
- 发生了什么？
- 何时发生？
- 对客户、系统及风险的影响是什么？
- 为什么发生，涉及哪些控制？
- 什么改动可以降低复发概率？
根因与促成因素¶
| 类型 | 示例 |
|---|---|
| 根因 | 报价源 Session 状态在高波动期间失效 |
| 促成因素 | 高影响新闻、报价深度下降、报价贡献变少 |
| 有效控制 | 报价聚合自动移除异常报价源 |
| 控制缺口 | 报价源报价贡献下降前缺少提前告警 |
| 预防措施 | 增加报价源性能恶化告警阈值 |
案例模拟¶
Quote Anomaly Review¶
纠正行动标准¶
每项行动应包括清晰描述、责任人、截止日期、优先级、验证方式和状态。
实战训练¶
真实场景
报价异常 Incident 关闭后，团队需要复盘为什么告警发现较晚。
Dealer 应该看的证据
时间线、告警记录、报价源数据、沟通记录、影响订单、恢复时间、改进行动。
错误示范
复盘变成追责，或者只写“已恢复”。
正确处理
围绕事实、根因、促成因素、控制缺口和 Shift Leader / 当班负责人制定可验证改进行动。
总结¶
复盘的价值在于让同类问题下次更早被发现、更快被升级，并且有明确 Shift Leader / 当班负责人跟进行动。事实和假设必须分开写；根因尚未验证时，应使用“复核中”，不要提前下结论。
完成第 5.5 课
完成标准¶
- 能说明本课的核心风险或操作目的
- 能指出需要查看的系统、数据或证据
- 能说明正确的升级或处理方式
- 能在模拟或实际指导场景中按流程处理