一名工程师的迁移日记：致不平凡的你们

当我接到要写一篇迁移日记时，“其实一开始我是拒绝的”。因为，对于一个理工男来说，能拾起的妙笔生花词汇应该是在大学时代，写给了“当年计算机系那个女生”。

但也是在一瞬间，我觉得自己应该写点什么，关于一次迁移，关于一支迁移团队，关于让平凡的迁移成为不平凡的“你们”。

1200万行的应用程序代码，482张应用系统业务表，2TB的应用系统业务数据，3个多月迁移和测试，12场迁移项目例会和评审，3次系统上线模拟演练……

这是洛阳银行系统迁移的工作记录，也是一名迁移工程师的心路历程。

在资产临近千亿门槛的重要发展时期，洛阳银行决定对原有业务系统进行深度整合，由此带来的系统迁移回报是：

上线后，系统支撑业务涵盖洛阳银行个人客户210万，存款账户数470万；系统扩展性强满足银行5年业务发展，即数据5000万条数据查询、600万条数据更新的能力。迄今为止，洛阳银行系统实现零故障运行，关键应用主机高可靠、高性能、高可用。

2014年8月18日，晴

在洛阳银行信息中心会议室里，我带着前天刚刚整理完毕的《迁移信息收集表》调研报告，这里面收集了客户系统迁移的36项信息，涵盖了洛阳银行业务系统基本情况、原数据库服务器状况、应用系统状况和其他服务器情况四部分。

这是本月第3次和客户召开迁移评估沟通会，系统迁移前客户最关心的核心问题主要有：系统迁移的可行性，系统的性能和稳定性要求，系统的可用性和可靠性设计，以及项目的迁移周期。

记得在调研中，当听到被移植的应用程序是使用C/C++语言编写的时候，我当时的内心还很犯怵，心想这真不是啥好活，都是硬骨头，移植这类程序，对我们来说意味着将要耗费大量的时间来移植和测试，硬着头皮上吧。

接下来我们首先了解了待移植应用程序所依赖的软件，如：数据库、中间件、第三方软件和开发库。知道了这些依赖，我们就可以评估K-UX平台上是否有这些软件产品。

其次，我们还要评估编译环境，对源平台上使用的编译器和链接器参数进行调查，以确定在K-UX上是否存在对应的参数。如果编译环境依赖于源平台，我们还要调整参数确保编译环境能够移植到K-UX上。

评估工作是个系统工程，这里面涉及了技术、资源、成本和风险等多方面要素，为了保证迁移任务能够顺利完成，细致、缜密的评估调研尤为重要，客户对我们准备的评估报告很满意，对系统迁移心里也更有底了。

从现在开始，真正的考验来了。

2014年9月8日，阴

按照迁移进度，今天要向客户提交迁移计划方案。计划方案的核心目的是，将评估结果和客户需求相结合，生成一个可以给客户清晰可见的系统迁移执行方案。

针对洛阳银行的需求和IT状况，我们制定了10项向K1平台迁移的具体方案，涵盖从基础软件兼容性测试到应用系统性能和稳定性测试，以及K1系统运维及监控。

方案计划落实到了每一个环节，并且对每个环节都做了风险评估。这样做的目的是当项目的某个环节出现问题或者某些程序移植遇到障碍时，我们该采取什么样的措施，协调什么样的资源去保障迁移项目的进度。

比如在移植的程序出现大小端错误时，我们在方案的风险评估中就考虑到了， 对于这样的问题，我们根据程序的移植经验，列出了可能产生错误的特征代码，通过这些特征代码来定位错误并解决它。

如果把评估阶段比作医生在“把脉”，那么计划阶段好比医生“开方子”，但并不是每个医生第一次开的方子都是考虑周全的，所以，我们要更多的关注项目迁移过程中的遇到的新问题，尽量避免因这些问题而导致的项目延期。

2014年10月14日，阴

应用程序移植验证已经进行了一个多月。
第一个难题出现在开始程序移植过程后不久，当时ISV的工程师跟我们说，通过SVN下载的业务源代码中含有中文命名的文件不能正常下载并显示，影响自动化测试脚本执行。

为了解决这个问题，我们在客户现场和公司的实验室做了多组实验，在多种解决方案无效的情况下，我带领团队从移植过程的源头开始分析排查，在操作系统原理的引导下，我们发现了引起错误的关键点。编译升级GLIBC的时候，执行make install命令会打断旧的动态库链接，改为指向新的库文件，在这个过程中，不同的链接指向新旧不同版本的库文件，很容易导致的系统某些功能服务（如LOCALE）的异常。

于是我们查找资料，学习了操作系统中LOCALE和GLIBC的关系，GLIBC是K-UX系统中最底层的应用程序开发接口（API），几乎其它任何的运行库都会倚赖于GLIBC。GLIBC除了封装操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现，这其中就包括LOCALE服务。根据理解我们尝试在更新GLIBC后，使用localedef命令补充所需LOCALE字符集，最终于实现了完整的字符集支持解决了这一困扰我们多天的难题。

移植验证阶段，总会碰到各种各样的问题，只要多反复求证，多试验，方法总比问题多。

2014年11月5日，晴

2、3个多月的移植和测试经历，让团队每个人都承担了很大的压力，在集成测试和功能测试阶段，ISV和客户根据测试用例对移植后的软件功能进行了100%的覆盖测试，可以说一颗悬着的心终于放下了，集成测试和功能测试涉及的所有测试用例都正确通过了。

后面还有应用系统的性能测试和稳定性测试，这是两道坎，也是客户最为关注的两项测试。

稳定性测试过程要运行自动调用脚本，在调试自动调用脚本完成且测试通过后，我们将调用脚本加载到系统deamon守护进程中以实现调用脚本的自动运行，然而在第二天检查的时候我们发现调用脚本虽然未停止运行，但是数据已经不再处理，数据库中没有今天的新记录。记得当时碰到这个问题的时候，我们走了很多弯路，最后用本该是最容易想到的办法，解决了这个问题。

我们在调用脚本的关键处加上了打印日志的指令，通过日志输出发现了脚本报错的地方,5天过去了，当问题原因找到的时候，真的是觉得自己的聪明反被聪明误。

接下来，我们根据这3个月以来测试的结果，向客户提交6份测试报告：基础环境测试报告、系统源代码迁移报告、系统功能测试报告、系统性能测试报告、系统稳定性测试报告和系统上线评估报告。

在新系统上线前，我们还会对新系统执行系统、网络等异常条件下，系统的可用性和可靠性，并在测试的最后组织多次模拟演练，确保系统上线切换万无一失。

2014年12月2日，晴

今天，客户通知正式上线新系统，在这之前，我们已经驻场给客户系统负责人
做了完整的K1平台操作培训。

上线当天系统切换过程很顺利，应用和数据库经受住了用户的考验，系统整体运行稳定。

有了前面严谨的步骤保障，系统上线就是水到渠成。洛阳银行新系统上线运行至今，实现了主机系统零故障运行，完全满足银行系统对关键应用主机的高可靠、高性能、高可用等要求，可满足未来5年的发展需求。

以上就是我的系统迁移日记。也许有人会说，“这些都是迁移标准流程，平凡而无新意。”

也许还有人会说，“迁移是个经验活，案例都是可以复制的，写出来会不会太矫情？”

但是，没有两个迁移过程是完全相同的。在浪潮迁移团队眼中，每一个客户，每一次迁移，都是一场全新的挑战和突破，在迁移的路上，我们和客户，和ISV，和合作伙伴并肩前行，将一个又一个难题成功化解，确保了系统迁移成功。

感谢，在每一次迁移中，我们的客户、ISV、合作伙伴给予的理解和支持。

感激，我是如此幸运，能与一支优秀的迁移团队共事，是你们让每一个平凡的迁移，成为“不平凡”。这是属于所有人的荣誉，我为你们自豪！

发给小编这篇迁移日记后，小编问我，怎么署名？

就用“ 128名浪潮迁移工程师中的一员”吧。