中小银行通常是指全国性商业银行、区域性股份制商业银行与城市商业银行，比如城市银行、农商行等。近年来，随着城市建设速度加快和信息技术产品更新迭代，中小银行需要面对机房搬迁、系统架构升级、系统迁移等棘手问题。
其中，系统迁移是中小银行信息部门较为头疼的工作，迁移失败，轻则影响业务持续开展，重则造成系统故障，影响银行的声誉。日本知名的瑞穗银行因系统迁移出现“大规模系统故障”，并造成了“数千台 ATM 机‘吞食’银行卡、部分网上银行交易出现故障”等严重问题，就是一个非常惨痛的教训。
在国内，银监会对银行业务连续性有非常严格的要求，根据银监会《商业银行业务连续性监管指引》（银监发 [2011]104 号）及银保监会发布《关于开展中小银行机构业务连续性相关风险整治工作的通知》（银保监办发 [2019]221 号）等相关文件，要求银行采取措施，减少因系统服务异常导致关键业务中断，保障业务连续性。
二、面临的挑战
银行启动系统迁移的条件有很多，包括机房建设搬迁、系统版本升级合并等。在大规模系统迁移过程中，面临主要问题如下：
经验不足
对于没有参与过大规模系统迁移的团队，在实际迁移过程中，可能会存在人为操作失误、迁移工具适配及功能完善、电力与网络故障、数据报错等问题；由于经验不足，可能导致问题解决的时间过长，影响业务的正常开展。
协调能力不强
立项之后，项目组需要协调内外部人员进行会议讨论、测试环境搭建、模拟演练操作、技术人员现场支持等，对于部分中小银行的团队而言，协调能力不强可能会拖慢项目进度，问题得不到及时的解决。
工具适配不及时
银行系统迁移工具部分自于外部技术供应商，由于新旧系统之间存在差异，迁移工具如果没有及时适配新系统，可能会出现迁移失败、数据不一致等问题。
时间窗口有限
系统迁移交割，通常会选择在业务闲暇的夜间时段，但银行服务是持续对外的，系统存在读写操作，这需要项目组在规定时间内完成迁移系统的测试验证和数据一致性比较，否则可能会影响白天业务的开展。
三、项目案例实践
在实际项目案例中，中小银行新建机房是导致大规模系统迁移的重要原因。通常这种迁移仅限于新旧机房的迁移，并不过多地涉及到同城及异地灾备中心。本文接下来将列举某银行因机房搬迁导致大规模系统迁移的项目实践案例。
该行业务系统由EasyStack、VMware 虚拟化、物理机等多种异构平台组成，系统主机数量超过 1000 个，从项目实际启动到新机房系统投产成功，项目周期大概是 5 个月。
在系统正式迁移交割前，项目经过了模拟演练—搭建测试环境—运行测试—正式交割—测试验证等一系列环节。为了确保系统的安全性、可控性、可用性，运行测试分阶段对重点系统进行迁移测试。所有系统的正式交割也根据迁移时间窗口的局限性，分批次进行交割验证。
迁移项目涉及众多系统和环节，内容难以逐一概述，下面通过部分重要系统迁移实践，具体描述迁移过程。
文件及存储层迁移
银行业务系统拥有众多的 FTP 文件系统，由于迁移过程文件存在读写操作，因此项目支持团队采用字节级实时复制软件将文件系统传输到目标端，并将变化数据同步过去；针对 NAS 存储数据，则通过 NAS 数据灾备软件迁移到目标端，保障文件系统及 NAS 数据的安全迁移。
操作系统层迁移
银行存在大量的 VMware 虚拟机，并且版本不一，针对这种情况，项目支持团队采用虚拟化备份软件将不同版本的虚拟机，成功迁移到新版本的 VMware 虚拟机上。同时针对少数云主机、物理机系统，通过在线热迁移软件成功迁移到目标端，实现异构操作系统的智能化安全迁移。
数据库系统层迁移
针对银行大型结构化数据库系统，项目支持团队通过结构化数据同步软件，将数据库数据实时同步到目标端，并进行数据一致性比较，保障用户的数据安全。
图片1△ 新旧机房系统迁移架构图
项目所有的系统迁移安全、如期地完成，新机房在预期的时间内成功启动并对外提供服务。从前期的项目运行测试，到系统正式交割，英方团队均在现场给予支持，服务能力获得了用户的高度认可。
四、用户价值
整个迁移项目历经可行性论证，多次测试验证迁移安全性，分批次交割验证等关键环节，不仅实现了项目的预期目标，还提升了项目团队的实践能力。同时，通过多层次的数据复制技术产品，帮助用户实现以下价值：
(1) 在生产业务不停的情况下，可实现存量数据和增量数据的快速迁移，保障数据一致性和安全性。
(2) 可支持异构环境下系统的大规模迁移，支持虚拟化多版本系统的迁移，节省迁移时间和成本。
(3) 迁移过程智能化，对于整个迁移过程可以准确预测；针对操作系统的迁移，只需保障操作系统一致，便可实现一键迁移，并可随时暂停、回退。
(4) 迁移过程安全可靠，两端数据保持一致性，迁移完成后新机房业务正常对外提供服务。
五、总结与展望
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
