大型银行核心系统“迭代式”敏捷迁移之路

一、基于IBM-I的大型银行核心系统目前的基本情况

核心系统转型，近几年是银行业界一个很热门的话题。银行是最早开始构建自己的IT系统去做数字化和自动化的行业之一，经过几十年的发展，这些IT系统和背后庞大的数据成为了银行的一大笔财富，但同时也成为一个负担。

例如我今天介绍的这个基于IBM-I的大型银行核心系统，完全汇丰内部研发，开发和运行了30多年，累积了千万行代码，数以吨计的海量数据。至今，这个系统仍然支持着我们环球市场50多个国家和地区多个中后台业务领域 ，包括运营，财务和风险管理等等，它既要支持环球市场统一和标准化的业务流程，同时也要满足很多地区性的需求。同时，作为骨干系统之一，它连接着300多个汇丰其它内部系统，像一棵古树的树根一样，错综复杂。

我在这个团队的整整10年，基本上都是在为这个骨灰级别的核心系统，寻找各种新技术和新的替代方案，有失败也有成功。今天，我的分享会以这10年以来我参与的两次大型的重构迁移的故事为主线。都说时代造就人，其实时代也造就架构和选择。在科技的世界，每5年就是一个新时代了。十年两次迁移，我们对于平台、架构、技术栈以及整个开发部署的模式的选择和决定，都有很多不同。

这次的回顾和分享，背后的思路和考量，希望给我自己，给大家，都可以带来一些参考。

二、两次大迁移

1、第一次大迁移

10年前， 我开始参与这个核心系统的第一次迁移，主要的目标是把全世界50个独立运行的一代实例，汇总到3个亚欧美的大区域实例，也是我们的二代系统上面，这个跟当时在国内外都颇为流行的“大集中”项目类似。

10年前，IBM 还是行业的老大，特别是在金融科技领域，IBM-I具备中后台系统必须的优秀品质，例如健壮、稳定，在后台处理和批处理方面也有它优胜之处。所以当时二代系统的迁移还是选择了IBM-I。

这个横跨5年的重构迁移项目在整体上是成功的。重构后的二代系统，采用了当时更先进的设计理念，同时在这个整合和迁移的过程中，我们在全球范围简化、优化、标准化和自动化了环球市场运营的整个业务流程。另外，我们对IBM-I 上的核心模块进行瘦身，清理了30%左右的旧功能和无用代码，把部分功能、新的服务以及很多和其他系统交互的接口模块解构出来，独立运行。第一次迁移总体来说是相当成功的，它也为我们第二次迁移打下了很好的基础。

但是，项目运行的过程，就有点不堪回首了。我们采用瀑布模型运行整个项目。一代系统支持的所有业务、功能和数据，一次性迁移到二代系统上。即使把50个国家，分成了几批上线，平均周期1年一批，每批10个国家左右，每个批次还是相当庞大的。忙碌了一整年，成功与失败，都是最后上线那一刻决定。更准确来说，是周末的惊心动魄48小时。成功了，旧系统就一键关掉。来自全球不同国家的所有用户从星期一开始，就用新系统去做他们的日常工作。这就是我们常说的“BIG DAY”。所有的投资和风险一直累积，价值和回报只有等成功上线的“BIG Day”之后才会开始，回收期长达几年。

2、第二次大迁移

5年前第一次大迁移基本上完成，我们又开始了对这个大型核心系统第三代的构想。

1）第一个灵魂拷问：还是IBM-I吗，如果不是，又将是什么呢？

IBM-I，曾经的王者。随着时代的变迁，它特别支持的编程语言，对于我们采用新的架构和设计理念有很多的限制。大而全的架构和设计，令到更新的速度已经跟不上业界需要的节奏。最迫在眉睫的问题就是，老系统已经无法吸引年轻人和新的人才加入了。因此，5年前我们就做了一个决定，我们开始搬离IBM-I，如果不是IBM-I，那又是什么呢？

微服务架构、分布式设计、云原生系统。​

• 我们的系统需要支持环球市场，7*24在线模式是必须的。
• 金融市场瞬息万变，这个行业对系统更新的要求，不比互联网行业慢。然而金融系统需要在灵活快速更新和扩展的同时，和稳定安全的要求上要取得一个平衡点，分布式的架构能够满足我们的要求。
• 数据为王，基于大数据的分析预测和AI/MI的应用，已经是基本需求，也是银行保持竞争力的必备要求，所以，我们的新系统要有能力和大数据分析以及AI/ML模型的对接。

最后还有一个重要原则：坚持内部研发，特别是核心模块。

2）第二个灵魂拷问：系统迁移只能一步到位吗？

系统迁移，在需求上面， 业务部门是希望一步到位的，而不是在新旧两个系统之间转换。脱离了业务的技术就是伪技术，所以我们做任何的技术方案一定得到业务部门的支持。但我们也问自己，问业务部门，能否再来一次为期5年的系统迁移？如果5年以后新系统才上线，世界已经发生了巨大的变化，5年我们等得起吗？我们是否可以迭代式敏捷迁移，通过双机并行数据同步统一入口等手段，最小化对业务部门的影响呢？

三、“迭代式”敏捷迁移的挑战

1）第一个挑战：全面了解原系统​

30年是一个足够久远的年代，我们组里第一代的程序员甚至已经退休了，运行了30多年且至今还在不断更新的老系统，已经没有人能说完全懂它，对原来的系统进行全面的了解是第一个巨大的挑战。

2）第二个挑战：找到切入点模块化迁移，新旧系统有机并行​

原来的系统大而全，内外部错综复杂，我们如果要做迭代式的迁移，就需要找到一个合适的切入点，能够把它整个模块解剖解构，再模块化迁移，难度也较大。引用一位同事的比喻，就像做外科手术一样，手术中的精准和术后的缝合都是非常重要的。

3）第三个挑战：新旧系统有机并行，一起敏捷，统一运维​

迭代式敏捷迁移必须解决的一个挑战就是新老系统需要健康交互、有机并行。业界有一个挺好的比喻，如今，银行核心系统做转型，就像在做一个不能停的换心手术，所以用什么方法能够保持新老系统的健康交互和有机并行，而我们的开发运维团队也能够同时跟得上这两个系统？这就是我们最后一个也是最大的难点。

1、全面了解原系统

10年前第一次迁移，我们采用的是翻箱倒柜，找历史文档，然后再人工分析，把文档和代码比对。但是随着时间的迁移，这一套方法已经行不通了。懂IBM-I的人越来越少，就像之前说的，第一代的程序员甚至已经退休。人工分析，工程量大，周期长，原系统一直还在被持续不断地更新改进中，人工分析根本跟不上进度，人为错误的机率也大。

这一次迁移，我们开始寻找新的解决思路。

首先，有什么是可以完全信赖的呢？就是至今还在生产机上日日夜夜跑动的千万行代码，以及每天都在新鲜产生的海量数据。

然后，我们只能依靠人工分析吗？如果我们把IBM-I上的这些代码和数据，都变成大数据。另外，让我们的技术和业务专家们输入他们的知识和分析逻辑，转换成规则建立在规则引擎。最后，利用今天自然语言处理、大数据分析以及AI的各种技术库，我们完全可以构建一个机器人来协助自己，所以我们就有了自研智能分析引擎。

最后为了方便大家的搜索检索，我们利用了一些开源的自动构图工具根据知识库去自动构建图形和流程图，可视化了知识库，这样我们就得到了一部活字典。

2、找到切入点模块化迁移，新旧系统有机并行

有了智能分析引擎去帮助我们了解老系统之后，我们的第二个难题就是：我们的老系统内外部错综复杂，需要找到一个合适的切入点将它进行拆解和迁移。

1)MVP(Minimum Viable Product) 功能和范围定义

第一步也是重要的一步就是定义MVP的功能和范围，MVP的成败决定了我们是否可以得到业务层和管理层后续的支持。大部分技术迁移的成功就在于我们要证明它有商业价值，并且在可接受的回收期。

首先我们选择了一个老系统没有的功能，从全新功能开始，意味着万一失败，对现在的系统和业务的影响不会太大。另外，也要考虑从最适合用新技术解决的业务痛点开始，痛点不够痛，大家不会动。一旦成功了，会让业务部门和企业感受到实实在在的的价值和回报，这样更容易得到业务部门、管理层和后续资金的支持。我们选择了后台系统最核心最重要的一块业务——支付和结算，以及整个流程中一个小服务——智能审查控制服务。利用大数据分析预测的技术可以大大提升整个审查控制的精确度，帮助我们客户、业务部门和银行控制支付风险。

除了实现功能，我们也在MVP里把基础设施构建好，并没有急着上线新功能，而是通过各种测试和完善，保证新架构的灵活扩展、 稳定、性能和弹性等。

2）新服务和旧系统交互，有机并行

第二步，我们需要把新服务和旧系统连接起来，有机并行。我们选择了在老系统建立了API endpoints以及和消息中间件交互的适配器。这里我也想分享一个理念，就是老系统不能破罐子破摔。保证老系统对新系统的对接，是支持我们完成整个迭代式跨技术平台迁移大计划的重要保证。同时，为了尽可能减少对业务部门的影响，我们在MVP加入了统一的用户界面，它同时连接着新老系统背后的数据库，让对应业务部门在统一的入口看到了全貌，既享受了新系统带来的更丰富的前端功能，也不会在这个过渡阶段受到太大的影响。简单一句话就是，门面功夫还是要做足的。

这个MVP 还是挺成功的，它收到了业务部门的支持，我们把单纯的技术迁移转变为业务和技术的同时推陈出新。

3）迁移现有功能

架构和基础都打好以后，我们才开始迁移现有功能模块。我们选择了邮件交易确认功能。考虑点就是，相对风险较小和容错率相对高一点的业务模块。另外，自动测试是迁移，特别是跨技术栈重构迁移的重要保证。业务系统本身的重构迁移开发和自动测试所用到的用例设计以及自动化工具，应该是同步的。

5年过去了，这个就是如今的双IT架构的总体样子。我们基本上探索出了我们的思路和路线，算是找到了一条可持续发展的路。另外，更重要的是，得到了业务部门、管理层和后续资金的支持，我们也把单纯的技术迁移转变成技术和业务的同步的迁移和创新。

3、新旧系统保持一致的敏捷节奏和统一的运维模式

打好了架构和基础之后，我们面临的第三个挑战是两个系统有机并行，那么就需要开发维护两个系统，平台技术栈和用到的工具都不太一样，团队越来越不负重荷了。我们通过应用和自研相结合，构建了一套自动化工具链，以及同时适配新老系统的开发运维一站式平台，来帮助我们自己。

下图是我们现在的团队所用的工具集的一览图，上面既有一些业界广为应用大家应该也熟悉的一些工具，如Jira、Jenkins、CheckMarx，也有特别适用于IBM-I系统的一些工具，如RTC、RDI和Arcad，而带星号的就是我们自己开发构建的工具和平台。

分享一下我们选择工具和自研设计的一些理念。

1）优先考虑业界优秀的工具。

因为业界的工具会有很多的场景和用户一起论证和不断完善，它们一定程度会比我们自研的更周全。另外，采用业界的工具，可以让我们精力和时间，更专注于我们自己在金融科技和业务领域的专长。

2）当业界没有合适的工具时，我们可以自己研发构建。

例如我们针对IBM-I开发了IBM-I特有的编程语言RPG的自动扫描工具，以保证代码的安全和质量，还有前面提到的同时适配新老系统的自动化测试框架。

当所有业界和自研的工具搭建完成后，一个新问题是：我们在不同的工具平台之间轮换，已经大大影响了我们的工作效率和质量。为了解决这个痛点，我们又构建了适合我们自己的开发运维一站式平台，让大家可以在一个平台完成大部分日常工作。

我们的一体化平台的实现思路并不复杂：现在大部分工具都是API接口的，我们只是on top搭建了一站式平台，通过API自动触发以及连接不同工具上的action，然后通过API从不同平台抓取所需要的信息。之前，我们需要登录10多个工具平台，200多个点击，才能完成一个标准的更改流程。现在只需要登录我们的一站式平台，20多个点击，就可以完成整个流程了。这个平台对于我们同时需要支持新老系统的团队来说，帮助非常大。此外，我们也节省了很多对于同事使用不同工具的学习和培训的成本。

最后我想跟大家分享我们在开发构建工具时对技术栈选择的一些考虑。

• 第一，工具和平台的构建和运行，目标也是迁离IBM-I，跟我们的愿景一致。同时我们的目标是一套工具和平台，同时适配新老系统。
• 第二，采用更开放的新技术栈来开发构建工具，为原IBM-I技术人员提供从实战中学习新技术栈的机会。我们有相当一部分IBM-I程序员，在开发工具的实战中掌握了新技术，成功转型成为新老系统，新旧技术栈都懂，业务也很精通的跨界程序员，他们已经成为我们这个迁移大计划的骨干力量。

四、思考与总结

• 技术或者模型不分贵贱，IBM-I还是云，瀑布还是敏捷，没有好坏对错，最适合的就是最好的。
• 人和文化（people and culture）比技术更重要。各种技术只是工具，架构和设计的理念，以及一直探索、学习和创新的团队和文化，才是永恒的。