回刷后的复检清单
回刷完成后要复检，而不是直接宣布修复：核对回刷分区的行数、主键唯一性与金额勾稽是否与源端一致（含边界日期）；确认下游依赖任务已重跑或已收到通知；确认增量任务从正确位点继续，没有发生重复回放；最后把回刷范围、原因与影响写入变更记录。最容易出二次事故的场景是回刷与增量同时写同一批数据——要么先冻结写入，要么明确先后顺序，并在复检时确认最终结果。
基本信息
| 复检项 | 行数、主键唯一、金额勾稽、与源端抽查 |
|---|---|
| 边界确认 | 区间首尾日期与跨月、跨年边界 |
| 下游处理 | 依赖任务重跑或明确通知，避免旧口径展示 |
| 增量位点 | 确认位点未重复回放或漏读 |
| 留痕 | 回刷范围、原因、影响写入变更记录 |
典型使用场景
- 上游补数后回刷下游分区，确认结果与源端一致
- 故障修复后重跑当天任务，确认指标恢复且下游同步更新
- 历史口径调整后回刷整段时间，核对边界分区的正确性
- 回刷与增量并行时确认最终写入结果没有被增量覆盖
- 对外交付前把复检记录作为交付依据
回刷复检清单
回刷复检清单
[ ] 行数 / 主键唯一 / 金额勾稽 校验通过
[ ] 与源端关键字段抽查一致（含区间首尾与跨月边界）
[ ] 下游依赖任务已重跑或已收到通知
[ ] 增量任务位点正常，未发生重复回放
[ ] 回刷与增量写入顺序已确认（先冻结或明确先后）
[ ] 回刷范围、原因、影响已写入变更记录复检项与判据
| 复检项 | 判据 | 不通过时 | 备注 |
|---|---|---|---|
| 行数 | 与源端或基线一致 | 继续排查过滤条件 | 注意测试单与冲正单 |
| 主键 | 无重复 | 检查是否重跑叠加 | 用业务键组合判重 |
| 金额勾稽 | 合计差异在容差内 | 核对退款与优惠分摊 | 容差要写进口径 |
| 下游状态 | 依赖任务已成功重跑 | 补跑或通知负责人 | 避免旧口径继续展示 |
回刷与增量同时写同一批数据是二次事故的高发场景：先冻结写入或明确先后顺序，并复检最终落库结果。
回刷后不复检直接宣布修复，次日可能发现数据又被增量覆盖，业务方对上线的信任度会明显下降。
回刷范围要写到变更记录里：谁在什么时候回刷了哪段时间、原因是什么，这既是审计需要，也是下次同类问题的参考。