大型银行核心系统“迭代式”敏捷迁移之路本文根据黄丽丽老师在〖2022

本文根据黄丽丽老师在〖2022Gdevops全球敏捷运维峰会-广州站〗现场演讲内容整理而成。（关注【dbaplus社群】公众号，回复“220617”可获取完整PPT）

文章图片
讲师介绍
黄丽丽，目前就职于汇丰科技，环球市场与证券服务技术部门，担任软件开发技术主管。拥有多年金融领域核心系统开发技术管理与业务分析经验，主要负责全球大型项目落地。持有PMP和SAFe认证，熟悉主流敏捷与DevOps方法及工具集，同时带领团队设计开发构建内部工具链和一体化协作平台，推进团队敏捷开发转型和流程改进。
分享概要
一、基于IBM-I的大型银行核心系统目前的基本情况
二、十年来两次大迁移，对技术选型和迁移方式的不同选择、对比和思路
三、近一次大迁移，从IBM-I到云， “迭代式”敏捷迁移的挑战和方法
四、思考与总结
一、基于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小时。成功了，旧系统就一键关掉。来自全球不同国家的所有用户从星期一开始，就用新系统去做他们的日常工作。这就是我们常说的“BIGDAY” 。所有的投资和风险一直累积，价值和回报只有等成功上线的“BIGDay”之后才会开始，回收期长达几年。