迁移批次规划的方法

迁移批次规划既是科学也是艺术，有些规划依据数据，有些规划只能依赖专家经验，批次规划需要做好三件事情：迁移分组、迁移分批、迁移优先级。

图1 批次规划

一、迁移分组

迁移分组主要是基于依赖关系将迁移对象进行分组，我们将一组具有强依赖关系的应用程序和基础架构的集合（包括APP、主机、存储、数据库、中间件等）放进一个迁移分组，迁移的时候要放同一批次，切换的时候要一起切。

依赖关系主要包括三种：共享数据依赖、共享服务器依赖、应用间的通信依赖。

依赖关系还有强弱之分：以共享数据依赖举例：应用程序A、B 和 C 都连接到db01，A 和B 每秒都会进行许多读写操作，但是C每晚在非高峰时间运行批处理作业，因此A、B和db01是紧耦合，C与db01是松耦合，A和B必须与db01一起迁移，放到同一个迁移分组，C可以单独移动，如果需要可以放到另一个迁移分组。

二、迁移分批

企业上云过程往往是分批进行的，1个分批可以包含1个或多个迁移分组，每个分批都是上云过程的一个里程碑，迁移分批一般参考以下原则：

• 依据关联性分析结果，强关联的应用要放在一个分批

  关联性强的要放在一个批次一起迁移，避免云上云下互访延时对业务的影响

• 一个分批跨度4~8周最合适

  将批次划分到合适的大小，以确保有足够的人力和技术资源来执行迁移过程，并将风险降至最低，业界最佳实践一个批次跨度4~8周最合适，时间指的是（部署、迁移、切换），不包含准备阶段。

• 一个分批不能太大，太大增加迁移风险

  根据业界最佳实践，一个批次不应超过20个应用程序、150 个服务器和30个数据库，超过这个大小挑战和风险都很大，增加失败挑战和回退风险，建议严格检查此规则的任何例外情况。

  如果一个分批很大，首先要将关联关系打开，识别出强关联和弱关联，将弱关联断开，拆分成较小的分批迁移，降低风险。

• 同一供应商的系统安排在同一批或相邻的批次上云

  同一供应商的多个系统之间耦合度较高，将这些系统的上云时间安排在一起，更有利于供应商在一段较短的时间内集中人力资源，确保各项目组之间的协同，有利于上云迁移实施的顺利开展。

• 不同的迁移环境放到不同的分批

  将生产环境与测试环境放在不同的分批中，先迁移测试环境，可以大大降低生产环境的迁移风险。

三、迁移优先级

影响上云迁移优先级的影响因素有如下：

其中，业务部门的上云意愿是第一优先级，先基于上云意愿排序，然后再按其余因素进行排序。如果做的更科学一点，可以基于每个影响因子打分，按照打分结果确定优先级。