（1）评估：预判迁移风险前沿技术
2015-07-09 来源：IDCUN 编辑：IDCUN
关于关键业务系统迁移，网上相关的案例和白皮书很多，不胜枚举。但这些技术性很强的文章，对像小编这样的技术小白来讲，晦涩难懂。于是，借着前几天浪潮启动的 “惠”迁计划，
提要
关于关键业务系统迁移，网上相关的案例和白皮书很多，不胜枚举。但这些技术性很强的文章，对像小编这样的技术小白来讲，晦涩难懂。于是，借着前几天浪潮启动的 “惠”迁计划，小编采访了浪潮的迁移工程师，决定从一个技术小白的视角，用自己对迁移的通俗理解，说一说关键应用迁移的那些事。
众所周知，一个完整的迁移方案分为“评估、计划、验证、测试和上线”5部分。
而浪潮平滑迁移5步走，每一步又是如何做的呢？
为了方便理解，小编将整个迁移过程比喻为一场“医疗救治”，那么迁移又可以是这样的：
今天，我们就先说说迁移中的评估——“把脉问症”。而在这之前，我们必须先了解以下几点。
迁移的时机
迁移是一项系统技术工作，是客户拓展业务发展机遇，获取竞争优势的一种途径。
实施迁移需要选择一定的时机，客户需要构建一个适应关键业务急速发展的IT基础架构，需要将核心应用程序和数据库相应迁移到新建立的环境之中。
实施迁移的最佳时机：
1、面临业务增长或合并；
2、客户的软件系统升级，需要将数据库等关键平台软件升级到新的版本上；
3、当前供应商不再对原有的硬件/软件提供技术支持；
4、企业在尝试建立高效虚拟化平台，利用新购服务器整合原有的业务系统，淘汰旧的服务器；
迁移的担忧
迁移是一项大规模的任务，会影响企业的多个部分，并带来一定的风险。我们了解到面临迁移的企业正在为很多事情而担忧，大致可总结如下图所示：
浪潮的迁移能力
没有两个迁移过程是完全相同的，而从浪潮多年的迁移经验来看，所有迁移中都是基础架构迁移、数据库迁移、 ISV 软件包、定制程序或者以上四个方面的组合。浪潮实施的迁移案例，涵盖12大关键行业、累计320多个迁移案例，积累了丰富的经验，可以帮客户节约成本，降低迁移风险。
浪潮的迁移能力包括但不限于：
1、准确地预估迁移规模和成本；
2、控制与应用程序迁移有关的风险所必备的专门技术；
3、原厂本地服务，保证系统迁移和修复的专业和及时；
4、自定义编码应用程序和选定打包应用程序与数据库的迁移；
5、将系统和应用程序升级到更新的平台；
迁移内容
迁移内容主要分为：应用迁移和数据库迁移。
目前，在Solaris、HP-UX、AIX和 Linux的应用程序和相关数据库，都可以平滑迁移到K-UX平台。
迁移前的背景信息就介绍这么多，回到浪潮5步平滑迁移，评估先行。
评估——“把脉问症”
评估是系统迁移前收集信息，衡量技术复杂难度和迁移风险的过程。评估阶段最核心的目的是，充分了解客户迁移需求。这好比医生给病人“把脉问症”，是一次综合体检，全面摸底了解的过程，只有弄清楚了病人的病症，才能对症下药。
对客户来讲，迁移的核心诉求有4点：
1、上线时间：新系统什么时候上线，系统交割时间点，反馈给我们是如何制定迁移工作进度，时间排期；
2、系统平滑迁移：客户希望系统迁移是平滑的，业务不受影响，因此需要明确客户对系统平滑迁移中导致的系统中断的时间容忍度；
3、中间业务逻辑不能出问题：第三方软件和中间件的可用性，评估编译工具和编译环境在K-UX平台上是否可用；
4、系统性能要有提升：客户希望新系统性能要有所提升，这里面涉及到对系统软硬环境兼容和多组件迁移环境做系统调研，才能找到影响系统性能提升的症结，评估加以解决；
迁移中的评估工作是个系统工程，这里面涉及各方资源协调，跨越多个领域，要保证迁移任务顺利完成，细致、缜密的评估调研尤为重要。浪潮有来自主机系统、数据库和行业软件等各个领域的专家团队，通过评估阶段36项信息分类的细致调研，最终形成统一的《迁移信息收集表》，此收集表作为制定迁移方案的基本依据，可以精准把脉客户系统“病症”，为后面计划阶段开好“方子”。
通过上述36项信息调研，迁移团队几乎可以摸清客户系统情况，预估迁移风险，从容制定迁移计划方案。
以其中一项对数据库服务器的评估工作为例，客户数据库从几百G到几十T不等，有的可以停机维护，有的则需要7*24小时不间断服务，这些要求不同，决定了后续的计划和方案的差异。
在一些小型的数据库，如区县级发票票据查询系统，数据库在200G以内，系统表结构中基本没有特别复杂的存储过程和数据对象，可以允许周末停机维护，那么我们就可以选择在客户的非工作日实施迁移，在新系统上安装好数据库，同时关闭生产数据库，将数据文件导出并备份，再将数据文件导入到新数据库，修改应用数据库访问地址，从而完成系统的割接过程。
而像银行、电信这样对数据一致性、业务连续性要求极高的客户，核心数据库的数据容量通常达到几十T，而且每天至少有几百G的数据库随着业务而不停地变化。
对于此类数据库，光是数据的导出就得需要2-3天，有的甚至长达一周左右。面对这种情况，单纯地采用数据库导入导出的操作，将无法满足客户的需求，那么我们需要分批次，分多次进行数据迁移，保证客户业务的不中断和平滑过渡。具体来讲，评估阶段就要根据系统业务大小、模型应用差别，分别诊断，采用分批次，多步骤迁移计划方案，一步步做迁移，同时还需要搭建异构平台互备，做好回退方案，确保新旧系统同步和数据库的一致性。
没有任何两个迁移过程是完全相同的
评估阶段最能考验一个迁移团队的思维缜密性，以及对迁移风险的预判能力。
用一名浪潮迁移工程师的话说：发现问题有时比解决问题更重要，而更重要的是我们在评估阶段，用可见的、具有说服力的评估报告，为后续迁移工作奠定扎实基础，给客户吃一颗定心丸。
关于关键业务系统迁移，网上相关的案例和白皮书很多，不胜枚举。但这些技术性很强的文章，对像小编这样的技术小白来讲，晦涩难懂。于是，借着前几天浪潮启动的 “惠”迁计划，小编采访了浪潮的迁移工程师，决定从一个技术小白的视角，用自己对迁移的通俗理解，说一说关键应用迁移的那些事。
而浪潮平滑迁移5步走，每一步又是如何做的呢？
迁移的时机
迁移是一项系统技术工作，是客户拓展业务发展机遇，获取竞争优势的一种途径。
实施迁移需要选择一定的时机，客户需要构建一个适应关键业务急速发展的IT基础架构，需要将核心应用程序和数据库相应迁移到新建立的环境之中。
实施迁移的最佳时机：
1、面临业务增长或合并；
2、客户的软件系统升级，需要将数据库等关键平台软件升级到新的版本上；
3、当前供应商不再对原有的硬件/软件提供技术支持；
4、企业在尝试建立高效虚拟化平台，利用新购服务器整合原有的业务系统，淘汰旧的服务器；
迁移的担忧
迁移是一项大规模的任务，会影响企业的多个部分，并带来一定的风险。我们了解到面临迁移的企业正在为很多事情而担忧，大致可总结如下图所示：
没有两个迁移过程是完全相同的，而从浪潮多年的迁移经验来看，所有迁移中都是基础架构迁移、数据库迁移、 ISV 软件包、定制程序或者以上四个方面的组合。浪潮实施的迁移案例，涵盖12大关键行业、累计320多个迁移案例，积累了丰富的经验，可以帮客户节约成本，降低迁移风险。
浪潮的迁移能力包括但不限于：
1、准确地预估迁移规模和成本；
2、控制与应用程序迁移有关的风险所必备的专门技术；
3、原厂本地服务，保证系统迁移和修复的专业和及时；
4、自定义编码应用程序和选定打包应用程序与数据库的迁移；
5、将系统和应用程序升级到更新的平台；
迁移内容
迁移内容主要分为：应用迁移和数据库迁移。
目前，在Solaris、HP-UX、AIX和 Linux的应用程序和相关数据库，都可以平滑迁移到K-UX平台。
评估——“把脉问症”
评估是系统迁移前收集信息，衡量技术复杂难度和迁移风险的过程。评估阶段最核心的目的是，充分了解客户迁移需求。这好比医生给病人“把脉问症”，是一次综合体检，全面摸底了解的过程，只有弄清楚了病人的病症，才能对症下药。
1、上线时间：新系统什么时候上线，系统交割时间点，反馈给我们是如何制定迁移工作进度，时间排期；
2、系统平滑迁移：客户希望系统迁移是平滑的，业务不受影响，因此需要明确客户对系统平滑迁移中导致的系统中断的时间容忍度；
3、中间业务逻辑不能出问题：第三方软件和中间件的可用性，评估编译工具和编译环境在K-UX平台上是否可用；
4、系统性能要有提升：客户希望新系统性能要有所提升，这里面涉及到对系统软硬环境兼容和多组件迁移环境做系统调研，才能找到影响系统性能提升的症结，评估加以解决；
迁移中的评估工作是个系统工程，这里面涉及各方资源协调，跨越多个领域，要保证迁移任务顺利完成，细致、缜密的评估调研尤为重要。浪潮有来自主机系统、数据库和行业软件等各个领域的专家团队，通过评估阶段36项信息分类的细致调研，最终形成统一的《迁移信息收集表》，此收集表作为制定迁移方案的基本依据，可以精准把脉客户系统“病症”，为后面计划阶段开好“方子”。
通过上述36项信息调研，迁移团队几乎可以摸清客户系统情况，预估迁移风险，从容制定迁移计划方案。
以其中一项对数据库服务器的评估工作为例，客户数据库从几百G到几十T不等，有的可以停机维护，有的则需要7*24小时不间断服务，这些要求不同，决定了后续的计划和方案的差异。
在一些小型的数据库，如区县级发票票据查询系统，数据库在200G以内，系统表结构中基本没有特别复杂的存储过程和数据对象，可以允许周末停机维护，那么我们就可以选择在客户的非工作日实施迁移，在新系统上安装好数据库，同时关闭生产数据库，将数据文件导出并备份，再将数据文件导入到新数据库，修改应用数据库访问地址，从而完成系统的割接过程。
而像银行、电信这样对数据一致性、业务连续性要求极高的客户，核心数据库的数据容量通常达到几十T，而且每天至少有几百G的数据库随着业务而不停地变化。
对于此类数据库，光是数据的导出就得需要2-3天，有的甚至长达一周左右。面对这种情况，单纯地采用数据库导入导出的操作，将无法满足客户的需求，那么我们需要分批次，分多次进行数据迁移，保证客户业务的不中断和平滑过渡。具体来讲，评估阶段就要根据系统业务大小、模型应用差别，分别诊断，采用分批次，多步骤迁移计划方案，一步步做迁移，同时还需要搭建异构平台互备，做好回退方案，确保新旧系统同步和数据库的一致性。
没有任何两个迁移过程是完全相同的
评估阶段最能考验一个迁移团队的思维缜密性，以及对迁移风险的预判能力。
用一名浪潮迁移工程师的话说：发现问题有时比解决问题更重要，而更重要的是我们在评估阶段，用可见的、具有说服力的评估报告，为后续迁移工作奠定扎实基础，给客户吃一颗定心丸。
