商业银行应用系统云化迁移之路浅析

依照中国银监会发布的“十三五”规划要求，到2020年底，商业银行面向互联网场景的重要信息系统全部迁移至云计算架构平台，其他系统迁移比例不低于60%。由此可见，无论从市场角度还是监管考量，商业银行应用系统的云化之路都已然是大势所趋。

目前,云计算的出现使得传统观点开始转变为“信息技术灵活性”观点，许多银行都希望将应用系统部署到云端，当然这一切的基础必须以不损失系统性能和和商业价值为前提。那么怎样的系统适合迁移到云呢？迁移的准备工作有哪些呢？迁移的最佳方式又是什么呢？本文旨在汲取同业先进的云计算推广经验的基础上，结合我行数据中心的私有云建设方向,通过分析应用在云化迁移准备过程中可能遇到的问题和需要关注的重点，尝试梳理出一种“多角度对比、精细化评估、分阶段执行”的三段式实施策略并提出初步的实施计划。

一、云化模式的多角度对比

（一）政策角度

根据银监会下发的《商业银行数据中心监管指引》规范，对银行业数据的运维安全提出了明确要求，“公有云”类数据存储中心目前并不符合相应要求。这主要是因为政府没有运营“云”的相关法律、法规，而商业银行面临着严酷的同业竞争和经营压力，与客户息息相关的重要数据更需要严格保密，如果使用公有云，数据出了问题无法追究责任，这一点不像很多公共资源的管理企业，政府有很多明确的规定和约束,使得其运营具有完备的政策保障。

（二）安全角度

就当下的发展状况而言，公有云的安全问题仍然因互联网犯罪的打击力度而显得扑朔迷离，将行业机密、身份信息、金融信息等敏感信息存放他处，一旦发生服务器宕机或信息泄露，企业形象势必将受到影响。目前的公有云仍可看作是之前的一些互联网技术的融合，所以一直存在的与回避服务、关系人打击等关联的安全危害不能视而不见，而对于视安全和效率为生命的银行业，迫切需要一个更安全可靠，更能融入业务的独立服务平台。

（三）经济角度

追求利润最大化是企业乃至银行运营的主要目标，经济效益也是影响银行应用云化模式的重要因素。公有云服务本质上是Utility服务，无论是哪个厂商其计费的原则应该是一致的，但目前“云”运营商计费标准不统一，流量计费千差万别，价格管理也缺乏依据。此外，目前具备给商业银行提供“云”服务的运营商数量有限，品质也是参差不齐，一旦未来需要更换服务商，数据迁移的费用也是个大问题。

综上所述，由于银行很多重要应用系统都采用独立的软、硬件平台部署，持续的维护和升级扩容需要庞大的费用支持，同时数据中心的高可用性、关键数据的可靠性、网络传输的安全性等依然是系统建设需要考虑的重点，因此银行短时间不会将数据完全迁移到公有云，而会更加专注于私有云技术的应用与推广。

二、迁移实施的准备与策略

（一）搜集与分析

在调查应用系统现状时，应重点关注包括存储、网络、负载均衡、数据库等软硬件资源及相关业务特点等信息，需要结合业务平台的实际情况和云计算的技术特点综合评估是否可通过云平台承接。建议重点分析如下要素：

1.应用系统架构：优先考虑基于开放平台分布式架构的应用系统迁移到云计算平台，非分布式架构的应用系统建议分析分布式架构改造的难度、费用、时间等因素后，再考虑是否迁移到云平台。

2.虚拟化适用性：商业银行应用系统大多采用非X86服务器，因此如何采用小型机虚拟化技术承接是一个必须考虑的课题。虚拟化技术不适用所有应用系统，结合业务现状将系统属性抽象出一些关键点，根据这些关键点来综合判断该系统是否适合虚拟化承载。

3.业务属性特征：对于应用系统的业务特征进行分析，诸如离线分析型、独立功能型、瞬时压力型系统优先考虑迁移到云平台；而对于业务实时性要求高、涉及敏感客户信息、安全等级要求高的应用系统，暂不考虑迁移到云平台。

（二）调研与评估

经过初步的搜集与分析之后，具体的评估流程应从业务分析出发最终落地到技术实施，覆盖软件生命周期的全流程，为每项影响因素定制不同的积分因子并构建综合评价模型来最终确定迁移策略，从而最大程度规避应用云迁移的系统风险。

调研和评估人员的分工可采取以下策略：

针对应用业务特点，由业务及需求人员组成需求与方案组评分；

针对数据库特点，由DBA及开发人员组成数据结构专家组评分；

针对系统关联度，由架构、业务及技术人员组成综合评审组评分；

针对运行维护能力，由运维管理人员组成运维能力考评组评分。

（三）云架构调整

应用系统的架构设计应当转变固有的方式，适当调整实施策略，以云架构的设计理念逐步代替传统架构设计思路，采用分布式数据访问机制、虚拟化技术摆脱对于数据库、硬件及中间件的依赖，从而适应云平台基础设施和平台资源的特点。应用系统之于云架构未来将成为应用服务层的一部分，作为最终用于交互的接口为客户提供独立的云应用和服务。

在面临存量应用系统上云时，多数情况下我们需要在实施迁移之前对应用程序架构进行调整，这类调整可能包括数据解耦、逻辑剥离、微服务改造、聚合封装等，使其更好地兼容并适配云环境去工作。采用面向产品服务的迁移方案不失为一个恰当的选择，它能够通过云平台的API与去服务的抽象层顺畅对接，充分利用虚拟化技术以及集群架构的优势，为实现私有云平台的软件即服务奠定基础。

以我行核心系统为例，在经过了集群架构的高可用性改造之后，已实现了应用的分布式架构部署，为云架构调整创造了条件。下一步可继续实施服务模块化拆分，以使粒度横向纵向相对统一且模块间独立；采取合适的粒度，将系统现有诸如存款、贷款、客户、卡等各逻辑模块进行解耦和独立性改造，服务之间依赖轻量级的接口，使系统具备松耦合、以服务为中心的特性，最终达到云架构的系统迁移要求。

（四）标准化改造

商业银行实施应用系统云化迁移的初衷是为了充分发挥云平台带来的强大功能，为了降本增效实现利润的最大化，如果云化改造只能够满足系统正常运行是远远不够的，这样只会带来高昂的运营成本与糟糕的执行效率，可谓赔了夫人又折兵。

在云化迁移前应该考虑优化应用系统，使其逐步规范化最终达到与云服务相对接，包括动态管理、弹性存储直连以及参数化配置等，从而充分利用云功能来发挥云平台的优势。银行应用系统建设基于历史原因经常是各自为战、缺乏统一的规划，这样在进行云化实施时就会导致巨大的改造成本，因此为应用建立统一规范的实施标准实施系统云迁移的必要条件，也是未来银行实现软件产品化的前提条件。

标准化改造的实施标准主要分两步：首先应该是系统去“IOE”，只有去除了应用与传统的“小型机+大型数据库+数据存储”的硬件捆绑之后，才能实现软、硬件的解耦从而完成主机平台向开放平台转化；其次，进一步实现应用系统与操作系统的解耦，达成应用跨平台的效果，以此来为最终的云化迁移奠定基础。

（五）分阶段迁移

从现阶段来看，应用系统分阶段迁移或许是唯一可行的策略选择。但无论何种上云策略，数据迁移对于一个业务应用来说都是最重要的，直接关系到应用上云的成败。抛开数据迁移采用的存储设备选择和分级管理不谈，单从保证数据完整和可用性出发，比如应用上云后需要去“Oracle”化，就涉及到SQL语法的适配和转换，底层DBIO代码的改造和重构，这些带来的实施挑战都需要在迁移阶段有充分的考虑。总体来说，应用系统的数据迁移可以分为三个阶段：迁移前的准备、迁移的实施和迁移后的校验。

迁移的准备是完成数据迁移工作的先决条件。首先，要梳理并给出待迁移数据源的详细信息与字段说明;其次，建立系统迁移前后数据库的数据字典和映射对比;然后，针对新旧系统数据层次结构与数据访问逻辑进行差异分析;最后，制定无法映射字段和异常情况的应急转换措施。

迁移的实施是实现数据迁移工作最重要的环节。首先，需要制定数据转换的详细实施步骤流程;其次，准备数据迁移以及数据备份和恢复的环境;然后，制定业务数据连续性方案，保证未处理完成的业务在迁移过后仍能正常处理；最后，按既定方案实施数据迁移。

数据迁移后的测试是对总体迁移工作的检查，是判断应用系统能否正式对外提供服务的重要依据。我们可以通过编写检查程序或者借助成熟的质量检查工具进行数据校验，也可以通过系统试运行或者开放部分诸如查询、统计等非主要功能模块来检查数据的准确性。

三、迁移之路的探索与规划

不论是迁移旧的应用还是构建新的应用，上云都是个复杂的系统工程，都需要仔细考虑成本与运营是否与云平台模式相匹配。应用云化迁移的过程不是简单的几步操作就大功告成，我们需要结合云化迁移所做的准备工作，依据云平台的技术架构特点，对应用做一定的适应性改造。尤其对于业务耦合度高和对传统架构依赖性强的复杂应用系统，一般都需要大量的改造开发，也可能需要大量的时间来完成。对于实施时间周期长，不可控因素多的系统，更需要谨慎地从投资回报以及可行性方面进行详细迁移评估。

（一）探索与讨论

举例说明，在如何实施关于人民银行帐户分类管理体系的架构设计中，一种基于核心系统集群高可用性改造之后的分布式架构和模块服务化与独立自治的思路，将一类帐户与二、三类帐户交易剥离分模块管理的方式曾引发了广泛的争论和探讨。

由于帐户分模块独立管理，因此应用场景更丰富但风险等级也更高的二、三类帐户交易将与一类帐户交易的处理逻辑隔离，一方面增强了架构选择的灵活性，另一方面也降低了交叉的影响，未来可以进一步通过云化迁移将应用更广泛的二、三类帐户处理体系投入云端；但是，由此种架构变化带来的代价也是巨大的，涉及到几乎全部应用系统的改造和总线系统接口的大幅调整，其落地实施的风险也逾越了银行出于科技安全考量的心理预期。

（二）总结与规划

商业银行应用系统云化还是应该先易后难、由浅入深，并且依照系统间的关联关系按步骤、有层次、分阶段的推行，从而最大限度的规避迁移风险，同时摒除传统思维壁垒，对于新建应用系统大胆使用云架构方式，不为未来云化迁移的实施累积欠账。

以我行的金融科技发展规划（2017-2020）为蓝本,结合银监会的“十三五”规划要求，试拟定应用系统云化迁移工作的实施计划如下：

2018年，重点完成应用系统云化迁移的准备工作中的搜集与分析、调研与评估工作；目标是建立应用云化迁移的评价模型，组织专家完成综合评分，并确定各应用系统的迁移策略和顺序。

2019年，重点完成应用系统的标准化改造和云架构调整工作；目标是建立全行应用系统的统一标准，达成存量应用系统的去“IOE”动作和分布式架构部署，新建应用系统的云架构推行。

2020年，逐步完成系统的虚拟化技术适应性调整和分阶段迁移工作；目标是按照既定的迁移策略和顺序，逐步实施各应用系统的分阶段迁移。

总之，应用架构的选择与业务制度施行、技术力量支撑都是密不可分的，应用的云化迁移离不开与之特点相适应的资源与运营保障，建立科学的云运营和云监管体系至关重要，而迁移策略也并非一个一成不变的方案，需要结合各银行的实践在迭代中不断更新，根据实施情况和效果进行不断的修正和完善。