数据质量事故复盘
数据事故的复盘发生在止血之后，目标是让同类问题不再发生。要写清四件事：时间线（何时出错、何时产生脏数据、何时被发现、何时止血、何时修复完成）、影响面（哪些表与下游任务、影响哪些业务日期、哪些指标口径）、根因（直接原因、系统原因如缺少卡点、管理原因如变更未评审）、改进项（负责人、截止时间、验收方式）。衡量复盘质量的不是文档厚度，而是改进项是否在后续演练中被验证有效。
基本信息
| 复盘时机 | 止血完成后，数据修复前或并行进行 |
|---|---|
| 核心内容 | 时间线、影响面、根因、改进项 |
| 根因层次 | 直接原因、系统原因、管理原因 |
| 改进项要求 | 有责任人、截止时间与验收方式 |
| 跟踪机制 | 定期回看改进项是否落地并验证 |
复盘模板
复盘模板
时间线：T0 异常发生 → T1 产出脏数据 → T2 下游发现或告警 → T3 止血 → T4 数据修复完成
影响面：受影响表 / 下游任务 / 业务日期区间 / 受影响的指标口径
根因：直接原因（代码逻辑、数据异常）→ 系统原因（缺失的卡点与校验）→ 管理原因（变更未评审、无人值守）
改进项：每项写清 责任人 + 截止时间 + 验收方式（新增规则 / 新增卡点 / 演练验证）复盘要素清单
| 要素 | 要写清的内容 | 常见缺失 |
|---|---|---|
| 发现路径 | 是告警发现还是业务方反馈 | 只写结果不写发现方式 |
| 发现延迟 | 从产生脏数据到被发现的时间 | 忽略延迟，掩盖监控缺口 |
| 影响范围 | 表、任务、业务日期、对外交付 | 只写内部表，漏对外口径 |
| 止血动作 | 停了哪些任务、冻结了哪些写入 | 未记录临时处置导致二次事故 |
复盘的产出是可执行的改进项而不是检讨：每一项都要有责任人与验收方式，下次演练时回看是否真的生效。
只修复数据不做根因修复，同类事故会按季度重复发生；复盘要专门追问为什么没能更早发现，这一条往往指向最有价值的改进项。
发现延迟本身值得单独统计：如果每次都是业务方先发现，说明监控覆盖或告警通道存在系统性缺口，比单个数据错误更值得处理。