3. 迁移批次规划
核心银行系统迁移不是一次“大爆炸”式的整体切换，而是把庞大的系统拆解为可控的批次，逐批验证、逐批上线。批次规划的质量，直接决定了迁移风险是否被有效隔离、回退是否可行、业务窗口是否够用。本节围绕四个关键动作展开：批次划分原则、依赖关系分析、优先级排序与时间窗口设计。
一、批次划分的核心原则
批次划分的本质是“在风险与效率之间找平衡点”。划分过粗，单批影响面大、回退困难；划分过细，联调次数多、窗口成本高。实践中应遵循以下原则：
- 业务闭环优先：一个批次应尽量覆盖一条完整的业务链路，避免出现“半条链路”导致跨批次强耦合。
- 数据耦合最小化：共享同一批主数据、账务表或对账逻辑的模块，尽量放在同一批次，减少跨批数据同步。
- 技术栈与改造类型聚类：纯数据库迁移、接口重构、外围适配等改造类型不同的模块，宜分批处理，避免验证口径混乱。
- 可独立回退：每个批次必须具备独立的回退方案，回退后不影响已上线批次。
- 规模可控：单批涉及的核心交易数量、接口数量、数据量应落在团队可验证的容量范围内。
二、依赖关系分析：识别“看不见的锁链”
依赖关系是批次排序的输入。核心银行系统的依赖通常分为四类：数据依赖（共享账户、客户、额度等主数据）、交易依赖（A 交易调用 B 交易）、接口依赖（同步/异步接口调用）、时序依赖（必须先后完成的操作）。
分析时建议采用“双向扫描法”：从业务链路正向梳理调用关系，再从数据表反向追踪写入来源。两者交叉比对，能发现大量隐性依赖。依赖关系可用有向图表达，节点为模块，边为依赖方向，环即为强耦合信号。
三、优先级排序：从“必须先行”到“可以后置”
排序不是简单按业务重要性排列，而是综合依赖方向、风险等级、业务价值与验证成本四个维度。常用方法是“依赖拓扑排序 + 风险加权”：先按依赖关系确定硬性先后，再在同层内按风险与价值排序。
| 优先级 | 判断依据 | 典型批次 | 窗口策略 |
|---|---|---|---|
| P0 | 被多批依赖、无替代路径 | 客户主数据、参数中心 | 独立大窗口，先行上线 |
| P1 | 核心账务、强一致性要求 | 存款、贷款核心 | 业务低峰期，双轨并行 |
| P2 | 外围接口、异步链路 | 支付、清算、对账 | 可拆分小窗口，灰度切换 |
| P3 | 报表、查询、辅助功能 | 历史查询、统计 | 可后置，允许短暂降级 |
四、时间窗口设计：让切换“有路可退”
时间窗口设计要回答三个问题：窗口多长、窗口内做什么、窗口关闭后如何确认。核心银行迁移窗口通常包括：停业准备、数据追平、切换执行、验证确认、开门营业五个阶段。
窗口阶段示例（T0 为切换日）：
T0-2h 停业准备：停止外围写入，冻结批处理
T0-1h 数据追平：增量数据同步至目标库，校验一致性
T0 切换执行：流量切换、配置生效、服务重启
T0+1h 验证确认：核心交易冒烟、对账、余额核对
T0+2h 开门营业：逐步放量，监控告警
窗口设计的关键参数包括：回退点（最晚可回退时刻）、数据追平速率、验证用例覆盖度。建议每个批次设置明确的“Go/No-Go”检查点，未通过则立即回退，而不是带病继续。
五、常见误区与复盘要点
- 误区一：按组织架构划分批次。部门边界不等于技术边界，容易造成跨批依赖断裂。
- 误区二：忽视弱依赖。异步接口、报表抽取等弱依赖在高峰期可能变成强阻塞。
- 误区三：窗口估算过于乐观。未计入数据追平波动、验证失败重试、回退操作时间。
- 误区四：优先级一次定死。依赖关系变化后未重新排序，导致后续批次被动等待。
复盘时应重点核对：实际依赖是否与规划一致、窗口各阶段耗时偏差、回退触发次数与原因、跨批数据一致性问题。把这些结论反哺到下一批次的规划中，批次规划才会越做越准。
批次规划不是追求“完美切分”，而是追求“风险可控、路径清晰、可回退、可验证”。掌握划分原则、依赖分析、优先级排序与窗口设计这四件事，迁移就从“赌运气”变成了“可管理的工程”。