人工对账修复如何避免二次事故？
简化版
人工修复要像生产发布一样治理：先冻结差异快照与权威依据，脚本只读预演，双人复核，小批灰度，条件更新，修复后复验。 禁止直接执行无范围 UPDATE，也不能在自动同步仍运行时与其互相覆盖。 每条操作可追踪、幂等、可暂停，高风险资金数据优先使用正向冲正而非修改历史。
详细版
工单记录差异来源、业务键、当前版本、期望结果、规则版本、影响金额和回滚/冲正方案。 脚本包含明确主键范围和 expectedVersion，受影响行数超阈值立即停止。 先 dry-run 导出将变更记录，再对少量样本执行并观察。
协调暂停或隔离相关自动补偿，避免竞态。 执行账户最小权限、有时间限制，全程审计。 完成后重新跑对账、检查业务指标和下游派生数据，原始证据不可删除。
完整版教学
一、人工不代表随意
人工修复往往发生在压力最大、信息最不完整时。 一条错误 SQL 可能把局部差异扩大为全表事故。 流程要减少临场自由度，并保留停止点。
人工修复是高风险生产变更，不是数据库里的快捷键。
二、先确定权威证据
比较源事件、业务流水、数据库版本和外部凭证。 明确哪侧是权威以及为什么。 资金场景以不可抵赖流水和清算凭证为依据。 不确定时冻结对象并升级，不能凭经验猜值。
三、冻结输入清单
生成不可变 repair batch，包含主键、当前版本、期望动作和原因。 对清单计算摘要并绑定工单。
batchId, entityId, expectedVersion, action, expectedResult
R20260930, O123, 17, CREATE_ADJUSTMENT, balance+100审批后执行内容不能被静默替换。
四、Dry-run 与复核
脚本先只读计算命中数、金额汇总和状态分布。 随机抽样与高金额样本人工核对。 提交者与审批者分离，生产执行使用受控机器人。 若实际命中与预演偏差超阈值，自动停止。
五、条件更新与幂等
| 保护措施 | 示例 | 防住的问题 |
|---|---|---|
| 版本条件 | WHERE id=? AND version=? | 覆盖修复期间的新写入 |
| 修复批次号 | repair_batch_id 唯一 | 脚本重跑造成二次修改 |
| 状态前置条件 | 仅 PENDING 可改 SUCCESS | 非法状态跳转 |
| 影响行数断言 | 期望 1 行，实际非 1 即停 | 对象不存在或条件已经变化 |
更新携带 expectedVersion，防止审批后数据已变化。 每条修复用 batchId+entityId 作为幂等键。 受影响行数为 0 转冲突队列，不强行覆盖。 资金更适合追加冲正流水，保留原交易历史。
六、控制爆炸半径
先 10 条，再 1%、10%、全量分批执行。 每批限制 QPS、事务大小和锁等待。 观察错误率、数据库负载和业务指标。 任一门禁失败暂停，不能脚本一启动就跑到底。
七、协调自动链路与复验
自动补偿可能同时写同一对象，需要暂停、排除批次或依靠版本冲突保护。 修复后重跑同一对账规则，确认差异归零。 检查缓存、搜索、报表等派生系统是否追平。 保留前后摘要、执行结果和未成功清单。
八、常见误区与追问
- 误区：人工操作比自动化更可控。 手工输入更易越界，必须平台化。
- 误区：有备份就能执行全表 UPDATE。 恢复时间和副作用不可忽略。
- 误区：修主库后任务就完成。 下游派生状态仍需复验。
- 误区：资金数据直接改余额最简单。 应优先追加可审计冲正。
- 追问：审批后数据变化怎么办？ expectedVersion 条件失败并重新评估。
- 追问：如何回滚？ 普通数据按旧值条件恢复，账务使用反向冲正。
- 追问：如何防脚本跑多次？ batch+entity 唯一键与幂等结果表。
九、加强记忆
- 证据先于修复。
- 清单冻结并绑定工单。
- dry-run、双人复核和条件更新。
- 小批限速，门禁失败即停。
- 修复后重新对账并确认所有派生系统。