2015-07-09 12:54:27
来 源
赛迪网
容灾
正因为有了充分的计划以及严谨的验证过程,使得整个迁移过程对客户公开透明,客户可以充分了解整体迁移计划可能出现的风险点。

该迁移案例共分为三步,一、评估:预判迁移风险;二、计划和验证:找到最佳迁移路径;三、严密的测试 上线水到渠成

二、计划和验证:找到最佳迁移路径

提要

上一篇,浪潮的工程师向小编介绍了迁移评估,在经过这个阶段的“把脉问症”后,迁移工作将进入计划和验证阶段,也就是“开方子”和“专家会诊”阶段。

计划——“开方子”

计划阶段好比“开方子”,但并不是每个医生第一次开的方子都是正确的,所以计划阶段其实是对评估阶段的“体检报告”对症下药,决定采取何种诊疗方案。

4.jpg

制定计划的核心

计划的核心目的是,将评估结果和客户需求相结合,生成一个可以给客户清晰可见的执行方案。这里面包含:针对项目浪潮的迁移团队打算怎么做?实施步骤是什么?业务分工包含哪些?以及包括ISV在内的第三方资源如何协调等。

同时,要保证计划的制定要落实到每一个环节,并且对每个环节都要做风险评估。这样做的目的是确保一旦当某个环节出现问题,或者某些应用迁移不过去的时候,该采取什么措施,协调什么样的资源去支持迁移工作?这些都需要写进迁移计划方案里。

在河南某银行迁移过程中,浪潮迁移团队在了解客户需求和IT状况后,对向K1平台迁移制定计划:

1、硬件平台入场的调试安装步骤;

2、基础软件在K1平台的兼容性测试计划;

3、应用系统在K1平台的功能性测试计划;

4、模拟数据在迁移后系统上的测试计划;

5、运维监控工具和监控方式的培训计划(如果客户原有监控手段不变,可以不用此计划);

计划全面,确保回退

在制定兼容性测试计划的时候,由于客户的数据库是从Oracle迁移到DB2数据库,在评估阶段会发现原有的系统会用到Oracle特有的函数和存储过程,而DB2的转换工具不一定能100%实现转换,那么我们在制定计划的时候,就需要增加对客户特定的存储过程的迁移做测试计划,并评估如果无法完成转换。

下一步的步骤该如何做,是否需要提前引入DB2的工程师支持,还是和应用开发商沟通,更改应用程序的代码?

如果前2种都不能满足,是否考虑依然退回沿用原来的数据库,同时在计划阶段,需要把此类风险和客户充分沟通,有助于客户早期决断,避免客户在系统迁移到一半的时候,出现无法回退的情况。

验证——“专家会诊”

验证是对迁移计划的校验过程,校验之前医生开的“方子”是否可行,需要众多专家一起“会诊”。

5.jpg

验证内容

验证的内容包含:人员分工协作的校验;时间节点校验;应用迁移模块和过程的校验;对数据完整性的校验等。

在迁移过程中,有时会出现在理论评估阶段认为迁移环境兼容性是一致的,但实际在迁移的过程中会发现一些异常。因此验证的主要目的是,在制订了完整计划以后对迁移的计划中的每个步骤,进行分解检验,通过验证过程中的预先演练,找出在迁移过程中可能出现的应用基础软件的版本不兼容问题,系统的环境变量以及核心参数设置的错误,软件编译出错以及数据库对象无法正常工作等意外。通过演练,严格按照执行计划进行反复地测试,保证任何一位迁移工程师,在针对该业务迁移的时候通过标准化操作,都能获得一样的迁移结果,从而大大降低在正式迁移中所遇到的风险。

验证场景

下图列举的是一个原先运行在X86平台的3个Java应用和国外小型机上的数据库全部迁移到K1平台的场景。在应用层的迁移的时候,需要验证JDK的版本有没有变化,功能模块是否正常工作,应用代码是否可编译等等问题;在数据库的迁移,需要验证迁移前后数据的完整性,数据库对象是否可正常工作等一系列的问题。

6.jpg

验证主要解决应用兼容问题、数据库调优和性能优化。验证阶段,迁移团队要全程记录验证过程中的BUG和解决方案,并针对此生成相应的“升级包”(一种可执行的规范性的校验操作手册),固化迁移过程中的问题修复流程,以便在正式迁移过程中,迁移工程师可严格按照升级包和迁移计划,“有迹可循”地快速对应解决在验证阶段发现的问题。

公开透明的迁移过程

正因为有了充分的计划以及严谨的验证过程,使得整个迁移过程对客户公开透明,客户可以充分了解整体迁移计划可能出现的风险点,浪潮迁移团队的工作分配,合作伙伴的专家支持等信息,从而打消客户的种种顾虑,避免在上线阶段出现的各种意外而引起的割接失败,从而有计划、有步骤地帮助客户完成业务系统的升级工作。

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。