比对工具,我做老系统改造时唯一不省的东西
8 年里我反复总结过一句话:
老系统改造,新老两边的输出如果不能用工具自动 diff,就只能
靠人盯。靠人盯一定会漏。
漏的不是大 bug——大 bug 上线 1 小时就报警了。
漏的是那种"看起来对但不对"的——单跑任何一边都看不出来,
机器把全量数据 diff 一遍,问题才浮出来。
下面是 4 个例子,都是真实经历过的项目,做了脱敏。
例 1 · 订单类系统迁移的 dump 比对
上篇提过的"老语言迁到主流语言"的项目,跨 14 个月切完。
这 14 个月里整个迁移就靠一件事撑着:dump 比对。
老系统的事件流 dump 一份,新系统的事件流 dump 一份,
每天定时跑 diff,差异写报表。
期间发现的 11 个"看起来对但不对"的 bug——全部是 diff
报表先发现,人后看到的。
最典型的一类:同一个业务状态,老系统用字符串表达,新系统用
枚举表达,两边语义其实一样。下游消费方两套都能解析——直到
diff 报表跑出来"同一条记录两种表达",我们才意识到出了问题。
如果当时省了这套——切完后只会有一堆历史数据不一致,
**到时只能选:全量重跑(代价大),或者认账(留坑)**。
例 2 · 聚合查询系统的跨结果表对账
某个聚合查询系统有 2 张结果表,逻辑上 1:1 对应。
跑了 5 年,某天我们顺手算了一下——
有上千条核心业务记录在表 A 有,表 B 没有。
是某个增量更新的边界 bug 。
不大,数据缺失也不影响主业务流程,所以 5 年没人发现。
后来加了个简单工具——
每天 1 次,表 A vs 表 B 跑 diff,差异 > 阈值告警,告警里
带具体写入代码段的指针。
工具上线 1 周,问题暴露;3 周修完。
值得说的是:**前 5 年是"暴露不出来",不是"修不了"**。
代码本身一直在那,bug 不是隐蔽,是没人有手段看见它。
例 3 · 数据匹配的离线 vs 在线 diff
某个数据匹配场景有两条链路:
- 离线全量(每天凌晨重算所有匹配关系)
- 在线增量(数据有变更时,即时算)
逻辑上两条应该一致——但实际经常不一致。
我们的比对方式很简单:取 1% 数据,让两条链路同时跑同一份输入,
diff 输出。每周大概能跑出 50-100 条不一致。
有意思的是:这些不一致里只有 30-50% 是真 bug。
剩下的是真实业务边界——比如某些场景在线已经能感知到、离线
还没扫到——这种"差异"是合理的,标"忽略"。
但你必须能看到它,才有资格忽略它。
没有这套工具的时候,我们以为两条链路一致;有了之后才发现:从来
就没一致过,只是没人在比。
例 4 · 多源数据合并时的字段分布对比
某个数据合并场景中,不同来源的数据语义不完全一致。
但字段分布(枚举值频次 / 数值范围)是一种隐含约束。
工具:合并前后跑同一个字段的分布,漂移 > 5% 就告警。
发现过一个特别隐蔽的 case——
枚举值"未知"在 A 来源约定是 0,B 来源约定是 -1 。
单看代码看不出来,0 和 -1 都是合法值,谁也没写错。
但合并后字段分布告警立刻响:**"0"占比从 30% 降到 15%**——
回头查,才看出两个来源的"未知"约定不一样。
字段分布对比有时比代码 review 更准——
代码 review 看的是逻辑,字段分布看的是约定。
不是 1 个工具,是 4 件配合用的事
很多人理解"比对工具"是写个脚本跑 diff——
这是把比对工具理解小了。
我经历的几次大改造,每一次都是这 4 件事一起做:
┌─────────────────────────────────────────┐
│ 老系统流量 新系统流量 │
│ │ │ │
└───────────┼──────────────────┼───────────┘
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ ① 数据快照 dump │ │ ① 数据快照 dump │
│ (独立存储) │ │ (独立存储) │
│ 解耦 / 毫秒级 / │ │ 字段冗余比节省强 │
│ 字段冗余 │ │ │
└─────────┬────────┘ └─────────┬────────┘
│ │
└─────────┬──────────┘
▼
┌──────────────────┐
│ ② diff 报表 │
├──────────────────┤
│ ▸ 字段级:A.x≠B.x │
│ ▸ 结构级:有/无 │
│ ▸ 时间级:早/晚 N 秒│
└─────────┬────────┘
▼
┌──────────────────┐
│ ③ 告警分级 │
├──────────────────┤
│ P1 关键字段差异 │ ──→ 立即告警
│ P2 非关键 > 阈值 │ ──→ 邮件
│ P3 时间级 < 容忍 │ ──→ 入归档
└─────────┬────────┘
▼
┌──────────────────┐
│ ④ 回溯链路 │
├──────────────────┤
│ 报表保留 ≥ 30 天 │
│ 改动有版本号 / 时间戳│
│ 时间窗口反查 │
└─────────┬────────┘
▼
根因定位
"哪次改动引入的"
① 数据快照 dump
老新两边都要把关键事件 dump 到独立存储。
3 个细节:
- 跟主链路解耦(dump 故障不能影响业务)
- 时间戳精确到毫秒
- 字段冗余比节省强(多 dump 一些没坏处,少 dump 一个就废了)
② diff 报表
定时全量或采样跑 diff,差异分类:
- 字段级差异(A.x ≠ B.x)
- 结构级差异(A 有 B 没有)
- 时间级差异(A 早 B 晚 N 秒)
不分类的 diff 报表等于没看——一堆条目堆在那,人会习惯性忽略。
③ 告警分级
不是所有 diff 都告警。
- 业务关键字段差异 → P1 立即告警
- 非关键字段差异 > 阈值 → P2 邮件
- 时间级差异 < 容忍窗口 → 入归档,不告警
不分级 = 全告警 = 等于没告警——3 天后没人看了。
④ 回溯链路
发现 diff 后,要能定位具体哪个改动引入的。
要求:
- diff 报表至少保留 30 天
- 所有改动有版本号 / 时间戳
- 按时间窗口能反查
没有回溯能力的 diff,等于"看到 bug 但不知道怎么发生的"。
这 4 件事缺一件,比对工具就只是"看起来在比"。
什么时候不该做
也有反例。
某次小项目,1 个 service 重构,代码量不到 500 行。
我也想搞这套——leader 直接砍了:"投入 vs 产出比不合理。"
事后看是对的——那个 service 切完后没出过故障。
我大概的判断:
- 千行以内 / 周级别的小改造——别上,没必要
- 上万行 / 月级别以上的大改造——必上
- 中间档——看两件事:数据语义复杂吗?并跑会持续 1 个月以上吗?
任何一个"是",就上
写在最后
很多人会把"比对工具"归在测试的事——
我倾向认为是改造方案的一部分。
测试问"这次发布有没有 bug"。
比对工具问"接下来这 N 个月,新老两边到底一不一致"。
看的时间尺度不一样。
而且时机很重要——
比对工具要在切第一刀之前就上线。
切完一半再加,你已经分不清"这条差异是改造带来的,还是早就存
在的"。
写到这,我也不太确定这套对所有团队都成立。
我经历的项目都是"业务相对稳定 + 改造期长 + 数据要追溯",
这种场景比对工具几乎是必修。
但如果是高速迭代的创业团队,搞这套可能反而是负担——
这点我自己也还在想。
下一篇打算写 6 阶段验收 SOP——
比对工具是其中第 4 阶段的核心,正好顺着接。
(以上 4 个例子都做了脱敏。
如果你做过老系统改造,欢迎评论区聊聊你们的比对工具长什么样,
特别想听没搭比对工具直接切,后来踩过的坑。)
