清算系统的差错处理和普通业务系统的心态完全不同。普通系统出 bug 可以回滚发布、重试请求；清算出错时数据已经进了账本、可能已经被对账文件带去了对方机构，修复动作本身也是账务动作，要受复式记账和对账规则的约束。这篇讲差错如何分级、处置 SOP 每一步的设计意图，以及为什么有一条铁律：不许直接改流水。
先分级：差错和影响面是两个维度
第一反应用来分类的往往不是"出了什么错"，而是"影响面在哪"。两个维度交叉出一个分级矩阵：
- 差错来源：我错（我方系统 bug、参数配错、文件解析错位）/ 对方错（交易所、结算公司下发数据有误）/ 时间差（数据其实没错，只是对账时点两边还没对齐，在途数据）；
- 影响范围：单边错（只有我方账错，对方数据是对的）/ 双边错（我方已经按错数据划款或过户）/ 资金风险（错的是钱的方向，例如该收的钱付出去了）。
分级决定处置路径。单边账错最简单：我方红冲蓝补修账，对方不受影响；双边错麻烦得多——我方修账之前必须和对方机构对齐口径，否则下一天对账两边又对不上；资金风险最紧急，因为钱已经在路上，追回来的成本和时效都按小时计。2013 年光大"8·16"事件的极端版本就是资金风险型：错误的买入委托真实成交，几十个亿的持仓头寸需要当天处置，处置速度决定了损失量级。
处置 SOP：每一步在保护什么
一套经过事故打磨的 SOP 大致是这样：
- 发现与定级：对账差异、客户投诉、调度任务报错，任何入口都要汇到同一个值班台账。定级由值班经理拍板，定错的代价不对称——定高了浪费人力，定低了错过黄金窗口，所以宁高勿低。
- 止血：暂停后续依赖任务（调度图里的下游全部挂起，防止错账被更多任务消费）、锁定相关流水（禁止后续任务重复处理这批数据）、冻结参数或配置的进一步变更。止血不做任何修复，只防止扩大。
- 定位：对差异数据做归因分类。最有用的工具是对比回放——用黄金文件测试的基础设施（下下篇细讲）拿生产数据在测试环境重跑当天清算，看差异能否复现。能复现的是代码 bug，不能复现的多半是环境或数据问题，排查方向完全不同。
- 修复：账务修复一律走红冲蓝补（《错账处理》那篇讲过原理），生成反向流水冲销错误记录，再补记正确记录。注意修复流水也要进当天的清算批次，让对账重新闭环。
- 复盘与基线更新：复盘输出两件事——防再发的代码/流程改造，以及回归基线的补充用例。
为什么黄金窗口只有几个小时
SOP 里最刺眼的词是"当晚"。硬约束来自清算链路的对称性：今天的账不平，明天的账就是在错的基数上继续算——余额是累计值，一日错、日日错。更现实的压力是交收时限：应付给结算公司的资金划付有截止时点（港股通场景里这笔划付甚至跨市场），错过时点的直接后果是交收违约，违约的代价（违约金、信用评级、监管关注）远大于差错本身。
可以用一个量级估算来理解为什么要全员动员：设差错涉及的资金规模为 $M$，当晚处置的成本是人力加班，量级为常数；拖到次日的处置成本除了修复本身，还多了 $M$ 规模头寸的市场风险敞口——按日波动率 $\sigma_d$ 计，期望损失为 $M \cdot \sigma_d$ 的某个倍数。哪怕 $M$ 只有一千万、日波动 2%，敞口也是二十万量级，已经超过绝大多数团队的加班成本。这就是为什么清算值班事故不分大小一律按"今晚必须止血、明早前必须修复或挂上明确处置计划"来执行。
三个常见的实战教训
其一，不要在止血前重启任务。调度系统"失败重试"是双刃剑——上游数据错了，重试只是把错账再生成一遍，从一笔变成多笔。止血动作里必须包含把重试熔断，等修复完成后再人工放行。
其二，和对方机构对齐口径要留书面凭证。双边差错修复时，电话沟通的效率最高但不可追溯，结算公司的业务规则以书面文件为准。曾经出现过的教训：双方口头对齐了修复口径，我方修了，对方按规则文件执行了另一个口径，下一天差异翻倍。
其三，差错修复也要走对账闭环。修了账不等于完事，修复流水必须参与当天对账并验证差异清零。跳过这一步的直接后果是：对账系统继续报差异，值班同学不知道这是"残留的旧差异"还是"修复引入的新差异"，排查成本翻倍。