为什么大额系统切换最怕"一刀切"？

把旧系统一次性停掉、一次性导入全量数据、一次性切到新系统，看起来最省事，实际上把三个风险叠在了同一时刻：

• 切换窗口不够：数据量越大，导入时间越长，业务停机时间越难接受
• 数据不一致难以发现：全量导入后若某张表少了几千条，在上百万条数据里很难第一时间察觉
• 回滚无路：旧系统已下线，新系统数据又不可信，此时既回不去也走不动
• 责任难界定：出问题时无法定位是数据问题、程序问题还是规则问题

增量与双备份的组合，本质是把"一次性大赌"拆成"多次小注"，每注都能单独验证、单独收回。

什么是"增量迁移"？

增量迁移指不一次性搬迁全量数据，而是先导入某个基准时间点之前的历史数据，再把后续产生的新数据分批追补，最终在某个时间点完成对齐切换。

增量批次怎么切

• 按业务维度：先迁低风险模块（如归档数据），最后迁高频写模块（如订单）
• 按时间维度：以自然月或季度为界，老数据先行
• 按组织维度：先迁单一分公司或单一部门验证流程，再全面铺开

选择标准的判断依据很简单：哪一批出了问题影响面最小，就先迁哪一批。先用最不重要的数据跑通全流程，把问题暴露在影响最小的时候。

什么是"双重备份"？重点不是备份两份

很多人理解的"双备份"是备份两份到两个地方。这里我们说的不是份数，而是两个不同时间点、不同用途的备份。

备份一：切换前的完整快照（可回到起点）

在开始任何迁移动作之前，对旧系统做一次完整的全量快照，包括数据库、配置文件、附件与程序版本。它的作用是：万一整个迁移方案失败，能完整回到动手之前的状态。

备份二：切换过程中的增量日志（可回到任意节点）

从第一个批次开始，记录每一批的数据变更日志。它的作用是：不用回到起点，只需回滚某一个出问题的批次，其他已验证通过的批次不受影响。

两套备份的时间点与验证动作

关键的一条：备份完成后必须做一次恢复演练，并记录实际耗时。未验证过的备份在应急时等同于没有备份——这是事故复盘里出现频率最高的教训。大连爱得科技在项目中的备份策略为【待填：说明你们实际的备份周期、保留份数与验证方式】。

一套可执行的 6 步流程

1. 盘点：资产清单、系统依赖关系、数据量、接口清单、业务可容忍的停机时长
2. 打镜像：在测试环境复刻生产环境，用真实数据跑一遍全流程
3. 定批次：确定增量的切分维度、批次数量，以及每一批的回滚点
4. 建双备份：全量快照 + 增量日志，先做恢复演练再开始切换
5. 分批切换：每批切换完成后立即做数据一致性核对，通过后再进行下一批
6. 并行观察：新旧系统并行运行【待填：建议观察天数】，覆盖至少一个完整业务周期后下线旧系统

其中第二步最容易被压缩——"反正测试环境差不多"。但恰恰是这一步能提前暴露八成的兼容性问题，代价只是在真实切换前多花几天。

这套做法同样适用于哪些场景？

• 大版本升级：跨版本的数据结构变更，风险与换系统相当
• 数据库迁移：换数据库类型或换版本
• 服务器更换：硬件迭代或机房搬迁
• 机房搬迁：物理环境变化带来的配置与服务依赖风险
• 域名或证书切换：看似简单，但涉及第三方回调地址时同样需要灰度

判断标准：只要这次变更影响的数据不可再生成，就值得按这套流程做。

容易做错的 3 个点

备份了但没验证过能否恢复

最常见也最致命。备份文件可能损坏、可能不完整、可能缺少恢复所需的中间依赖。一次完整的恢复演练能消耗几个小时，但能验证整个方案的可靠性。

增量批次之间没做数据一致性核对

连续切换三批后再统一检查，一旦发现问题，已经无法判断是哪一批引入的。必须每批核对，代价只是多花一点时间。

旧系统下线太早，追补数据无路可退

业务方往往希望尽快结束并行期。但并行期的价值正是"安全垫"——建议至少覆盖一个完整业务周期（一次月度结算、一次集中缴费），让真实场景检验新系统。

常见问题

增量迁移比一次性迁移慢吗？

总工期通常更长，但停机窗口显著更短。对无法接受长时间停机的业务系统，用总工期换取可用性窗口是划算的；对允许停机的内部系统，一次性全量反而更简单。

备份两份就够了吗？

关键不在份数，而在是否演练过恢复。建议至少做一次完整的备份恢复演练，并记录实际耗时。未验证过的备份在应急时等同于没有备份。

并行期要留多久？

取决于业务周期。覆盖一个完整业务周期（如一次月度结算、一次集中缴费）能较充分暴露问题【待填：你们的经验值】。

普通版本升级也需要双备份吗？

建议保留。即便改动很小，升级前的完整快照成本极低，而一旦失败回滚的代价很高。增量日志可视改动范围决定是否需要。

切换后发现新系统数据不对怎么办？

这正是分批次的意义：立即停止下一批切换，用该批的增量日志回滚到切换前状态，核对差异后再推进。因此每批之后必须做数据一致性核对，不能连续切换多批后再统一检查。