展开导读
链接复制成功!
迁移批次规划的方法
迁移批次规划既是科学也是艺术,有些规划依据数据,有些规划只能依赖专家经验,批次规划需要做好三件事情:迁移分组、迁移分批、迁移优先级。

一、迁移分组
迁移分组主要是基于依赖关系将迁移对象进行分组,我们将一组具有强依赖关系的应用程序和基础架构的集合(包括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个数据库,超过这个大小挑战和风险都很大,增加失败挑战和回退风险,建议严格检查此规则的任何例外情况。
如果一个分批很大,首先要将关联关系打开,识别出强关联和弱关联,将弱关联断开,拆分成较小的分批迁移,降低风险。
- 同一供应商的系统安排在同一批或相邻的批次上云
同一供应商的多个系统之间耦合度较高,将这些系统的上云时间安排在一起,更有利于供应商在一段较短的时间内集中人力资源,确保各项目组之间的协同,有利于上云迁移实施的顺利开展。
- 不同的迁移环境放到不同的分批
将生产环境与测试环境放在不同的分批中,先迁移测试环境,可以大大降低生产环境的迁移风险。
三、迁移优先级
影响上云迁移优先级的影响因素有如下:
影响因素 |
影响结果 |
业务上云意愿 |
上云意愿度高的先上,意愿度低的后上 |
业务环境 |
测试环境优先,生产环境最后 |
业务重要性 |
一般业务先上,核心业务后上 |
业务关联度 |
关联关系简单的业务先上,复杂的业务后上 |
基础架构复杂度 |
底层基础架构简单、实例数少的先上,复杂的后上 |
允许停服时间 |
停服时间长的先上,不停服的最后上 |
迁移策略 |
平迁的先上,要改造的后上 |
其中,业务部门的上云意愿是第一优先级,先基于上云意愿排序,然后再按其余因素进行排序。如果做的更科学一点,可以基于每个影响因子打分,按照打分结果确定优先级。
分类 |
影响因素 |
分数参考 |
---|---|---|
业务环境 |
开发 |
5 |
测试 |
3 |
|
生产 |
1 |
|
业务重要性 |
一般 |
5 |
重要 |
3 |
|
核心 |
1 |
|
关联性 |
简单(0-3) |
5 |
复杂(4-6) |
3 |
|
非常复杂(7~) |
1 |
|
基础架构复杂度 |
简单(实例数1~3) |
5 |
复杂(实例数4~10) |
3 |
|
很复杂(实例数11~) |
1 |
|
允许停服时长 |
120分钟以上 |
5 |
60~120分钟 |
3 |
|
<60分钟 |
1 |
|
迁移策略 |
Rehost |
5 |
Replatform |
3 |
|
Re-architect |
1 |
应用迁移批次规划样例
应用名称 |
上云策略 |
上云批次 |
第一批次上云 |
第二批次上云 |
第三批次上云 |
第四批次上云 |
---|---|---|---|---|---|---|
- |
- |
- |
2025.01.01~2025.03.31 |
2025.04.01~2025.06.30 |
2025.07.01~2025.09.30 |
2025.10.01~2025.12.31 |
此处仅给出表头信息作为参考。 表格具体内容请按业务实际情况进行补充。 |