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