一、基于IBM-I的大型銀行核心系統(tǒng)目前的基本情況

核心系統(tǒng)轉(zhuǎn)型，近幾年是銀行業(yè)界一個很熱門的話題。銀行是最早開始構(gòu)建自己的IT系統(tǒng)去做數(shù)字化和自動化的行業(yè)之一，經(jīng)過幾十年的發(fā)展，這些IT系統(tǒng)和背后龐大的數(shù)據(jù)成為了銀行的一大筆財富，但同時也成為一個負(fù)擔(dān)。

例如我今天介紹的這個基于IBM-I的大型銀行核心系統(tǒng)，完全匯豐內(nèi)部研發(fā)，開發(fā)和運行了30多年，累積了千萬行代碼，數(shù)以噸計的海量數(shù)據(jù)。至今，這個系統(tǒng)仍然支持著我們環(huán)球市場50多個國家和地區(qū)多個中后臺業(yè)務(wù)領(lǐng)域 ，包括運營，財務(wù)和風(fēng)險管理等等，它既要支持環(huán)球市場統(tǒng)一和標(biāo)準(zhǔn)化的業(yè)務(wù)流程，同時也要滿足很多地區(qū)性的需求。同時，作為骨干系統(tǒng)之一，它連接著300多個匯豐其它內(nèi)部系統(tǒng)，像一棵古樹的樹根一樣，錯綜復(fù)雜。

我在這個團(tuán)隊的整整10年，基本上都是在為這個骨灰級別的核心系統(tǒng)，尋找各種新技術(shù)和新的替代方案，有失敗也有成功。今天，我的分享會以這10年以來我參與的兩次大型的重構(gòu)遷移的故事為主線。都說時代造就人，其實時代也造就架構(gòu)和選擇。在科技的世界，每5年就是一個新時代了。十年兩次遷移，我們對于平臺、架構(gòu)、技術(shù)棧以及整個開發(fā)部署的模式的選擇和決定，都有很多不同。

這次的回顧和分享，背后的思路和考量，希望給我自己，給大家，都可以帶來一些參考。

二、兩次大遷移

1、第一次大遷移

10年前， 我開始參與這個核心系統(tǒng)的第一次遷移，主要的目標(biāo)是把全世界50個獨立運行的一代實例，匯總到3個亞歐美的大區(qū)域?qū)嵗?，也是我們的二代系統(tǒng)上面，這個跟當(dāng)時在國內(nèi)外都頗為流行的“大集中”項目類似。

10年前，IBM 還是行業(yè)的老大，特別是在金融科技領(lǐng)域，IBM-I具備中后臺系統(tǒng)必須的優(yōu)秀品質(zhì)，例如健壯、穩(wěn)定，在后臺處理和批處理方面也有它優(yōu)勝之處。所以當(dāng)時二代系統(tǒng)的遷移還是選擇了IBM-I。

這個橫跨5年的重構(gòu)遷移項目在整體上是成功的。重構(gòu)后的二代系統(tǒng)，采用了當(dāng)時更先進(jìn)的設(shè)計理念，同時在這個整合和遷移的過程中，我們在全球范圍簡化、優(yōu)化、標(biāo)準(zhǔn)化和自動化了環(huán)球市場運營的整個業(yè)務(wù)流程。另外，我們對IBM-I 上的核心模塊進(jìn)行瘦身，清理了30%左右的舊功能和無用代碼，把部分功能、新的服務(wù)以及很多和其他系統(tǒng)交互的接口模塊解構(gòu)出來，獨立運行。第一次遷移總體來說是相當(dāng)成功的，它也為我們第二次遷移打下了很好的基礎(chǔ)。

但是，項目運行的過程，就有點不堪回首了。我們采用瀑布模型運行整個項目。一代系統(tǒng)支持的所有業(yè)務(wù)、功能和數(shù)據(jù)，一次性遷移到二代系統(tǒng)上。即使把50個國家，分成了幾批上線，平均周期1年一批，每批10個國家左右，每個批次還是相當(dāng)龐大的。忙碌了一整年，成功與失敗，都是最后上線那一刻決定。更準(zhǔn)確來說，是周末的驚心動魄48小時。成功了，舊系統(tǒng)就一鍵關(guān)掉。來自全球不同國家的所有用戶從星期一開始，就用新系統(tǒng)去做他們的日常工作。這就是我們常說的“BIG DAY”。所有的投資和風(fēng)險一直累積，價值和回報只有等成功上線的“BIG Day”之后才會開始，回收期長達(dá)幾年。

2、第二次大遷移

5年前第一次大遷移基本上完成，我們又開始了對這個大型核心系統(tǒng)第三代的構(gòu)想。

1）第一個靈魂拷問：還是IBM-I嗎，如果不是，又將是什么呢？

IBM-I，曾經(jīng)的王者。隨著時代的變遷，它特別支持的編程語言，對于我們采用新的架構(gòu)和設(shè)計理念有很多的限制。大而全的架構(gòu)和設(shè)計，令到更新的速度已經(jīng)跟不上業(yè)界需要的節(jié)奏。最迫在眉睫的問題就是，老系統(tǒng)已經(jīng)無法吸引年輕人和新的人才加入了。因此，5年前我們就做了一個決定，我們開始搬離IBM-I，如果不是IBM-I，那又是什么呢？

微服務(wù)架構(gòu)、分布式設(shè)計、云原生系統(tǒng)。?

• 我們的系統(tǒng)需要支持環(huán)球市場，7*24在線模式是必須的。
• 金融市場瞬息萬變，這個行業(yè)對系統(tǒng)更新的要求，不比互聯(lián)網(wǎng)行業(yè)慢。然而金融系統(tǒng)需要在靈活快速更新和擴(kuò)展的同時，和穩(wěn)定安全的要求上要取得一個平衡點，分布式的架構(gòu)能夠滿足我們的要求。
• 數(shù)據(jù)為王，基于大數(shù)據(jù)的分析預(yù)測和AI/MI的應(yīng)用，已經(jīng)是基本需求，也是銀行保持競爭力的必備要求，所以，我們的新系統(tǒng)要有能力和大數(shù)據(jù)分析以及AI/ML模型的對接。

最后還有一個重要原則：堅持內(nèi)部研發(fā)，特別是核心模塊。

2）第二個靈魂拷問：系統(tǒng)遷移只能一步到位嗎？

系統(tǒng)遷移，在需求上面， 業(yè)務(wù)部門是希望一步到位的，而不是在新舊兩個系統(tǒng)之間轉(zhuǎn)換。脫離了業(yè)務(wù)的技術(shù)就是偽技術(shù)，所以我們做任何的技術(shù)方案一定得到業(yè)務(wù)部門的支持。但我們也問自己，問業(yè)務(wù)部門，能否再來一次為期5年的系統(tǒng)遷移？如果5年以后新系統(tǒng)才上線，世界已經(jīng)發(fā)生了巨大的變化，5年我們等得起嗎？我們是否可以迭代式敏捷遷移，通過雙機(jī)并行數(shù)據(jù)同步統(tǒng)一入口等手段，最小化對業(yè)務(wù)部門的影響呢？

三、“迭代式”敏捷遷移的挑戰(zhàn)

1）第一個挑戰(zhàn)：全面了解原系統(tǒng)?

30年是一個足夠久遠(yuǎn)的年代，我們組里第一代的程序員甚至已經(jīng)退休了，運行了30多年且至今還在不斷更新的老系統(tǒng)，已經(jīng)沒有人能說完全懂它，對原來的系統(tǒng)進(jìn)行全面的了解是第一個巨大的挑戰(zhàn)。

2）第二個挑戰(zhàn)：找到切入點模塊化遷移，新舊系統(tǒng)有機(jī)并行?

原來的系統(tǒng)大而全，內(nèi)外部錯綜復(fù)雜，我們?nèi)绻龅降倪w移，就需要找到一個合適的切入點，能夠把它整個模塊解剖解構(gòu)，再模塊化遷移，難度也較大。引用一位同事的比喻，就像做外科手術(shù)一樣，手術(shù)中的精準(zhǔn)和術(shù)后的縫合都是非常重要的。

3）第三個挑戰(zhàn)：新舊系統(tǒng)有機(jī)并行，一起敏捷，統(tǒng)一運維?

迭代式敏捷遷移必須解決的一個挑戰(zhàn)就是新老系統(tǒng)需要健康交互、有機(jī)并行。業(yè)界有一個挺好的比喻，如今，銀行核心系統(tǒng)做轉(zhuǎn)型，就像在做一個不能停的換心手術(shù)，所以用什么方法能夠保持新老系統(tǒng)的健康交互和有機(jī)并行，而我們的開發(fā)運維團(tuán)隊也能夠同時跟得上這兩個系統(tǒng)？這就是我們最后一個也是最大的難點。

1、全面了解原系統(tǒng)

10年前第一次遷移，我們采用的是翻箱倒柜，找歷史文檔，然后再人工分析，把文檔和代碼比對。但是隨著時間的遷移，這一套方法已經(jīng)行不通了。懂IBM-I的人越來越少，就像之前說的，第一代的程序員甚至已經(jīng)退休。人工分析，工程量大，周期長，原系統(tǒng)一直還在被持續(xù)不斷地更新改進(jìn)中，人工分析根本跟不上進(jìn)度，人為錯誤的機(jī)率也大。

這一次遷移，我們開始尋找新的解決思路。

首先，有什么是可以完全信賴的呢？就是至今還在生產(chǎn)機(jī)上日日夜夜跑動的千萬行代碼，以及每天都在新鮮產(chǎn)生的海量數(shù)據(jù)。

然后，我們只能依靠人工分析嗎？如果我們把IBM-I上的這些代碼和數(shù)據(jù)，都變成大數(shù)據(jù)。另外，讓我們的技術(shù)和業(yè)務(wù)專家們輸入他們的知識和分析邏輯，轉(zhuǎn)換成規(guī)則建立在規(guī)則引擎。最后，利用今天自然語言處理、大數(shù)據(jù)分析以及AI的各種技術(shù)庫，我們完全可以構(gòu)建一個機(jī)器人來協(xié)助自己，所以我們就有了自研智能分析引擎。

最后為了方便大家的搜索檢索，我們利用了一些開源的自動構(gòu)圖工具根據(jù)知識庫去自動構(gòu)建圖形和流程圖，可視化了知識庫，這樣我們就得到了一部活字典。

2、找到切入點模塊化遷移，新舊系統(tǒng)有機(jī)并行

有了智能分析引擎去幫助我們了解老系統(tǒng)之后，我們的第二個難題就是：我們的老系統(tǒng)內(nèi)外部錯綜復(fù)雜，需要找到一個合適的切入點將它進(jìn)行拆解和遷移。

1)MVP(Minimum Viable Product) 功能和范圍定義

第一步也是重要的一步就是定義MVP的功能和范圍，MVP的成敗決定了我們是否可以得到業(yè)務(wù)層和管理層后續(xù)的支持。大部分技術(shù)遷移的成功就在于我們要證明它有商業(yè)價值，并且在可接受的回收期。

首先我們選擇了一個老系統(tǒng)沒有的功能，從全新功能開始，意味著萬一失敗，對現(xiàn)在的系統(tǒng)和業(yè)務(wù)的影響不會太大。另外，也要考慮從最適合用新技術(shù)解決的業(yè)務(wù)痛點開始，痛點不夠痛，大家不會動。一旦成功了，會讓業(yè)務(wù)部門和企業(yè)感受到實實在在的的價值和回報，這樣更容易得到業(yè)務(wù)部門、管理層和后續(xù)資金的支持。我們選擇了后臺系統(tǒng)最核心最重要的一塊業(yè)務(wù)——支付和結(jié)算，以及整個流程中一個小服務(wù)——智能審查控制服務(wù)。利用大數(shù)據(jù)分析預(yù)測的技術(shù)可以大大提升整個審查控制的精確度，幫助我們客戶、業(yè)務(wù)部門和銀行控制支付風(fēng)險。

除了實現(xiàn)功能，我們也在MVP里把基礎(chǔ)設(shè)施構(gòu)建好，并沒有急著上線新功能，而是通過各種測試和完善，保證新架構(gòu)的靈活擴(kuò)展、 穩(wěn)定、性能和彈性等。

2）新服務(wù)和舊系統(tǒng)交互，有機(jī)并行

第二步，我們需要把新服務(wù)和舊系統(tǒng)連接起來，有機(jī)并行。我們選擇了在老系統(tǒng)建立了API endpoints以及和消息中間件交互的適配器。這里我也想分享一個理念，就是老系統(tǒng)不能破罐子破摔。保證老系統(tǒng)對新系統(tǒng)的對接，是支持我們完成整個迭代式跨技術(shù)平臺遷移大計劃的重要保證。同時，為了盡可能減少對業(yè)務(wù)部門的影響，我們在MVP加入了統(tǒng)一的用戶界面，它同時連接著新老系統(tǒng)背后的數(shù)據(jù)庫，讓對應(yīng)業(yè)務(wù)部門在統(tǒng)一的入口看到了全貌，既享受了新系統(tǒng)帶來的更豐富的前端功能，也不會在這個過渡階段受到太大的影響。簡單一句話就是，門面功夫還是要做足的。

這個MVP 還是挺成功的，它收到了業(yè)務(wù)部門的支持，我們把單純的技術(shù)遷移轉(zhuǎn)變?yōu)闃I(yè)務(wù)和技術(shù)的同時推陳出新。

3）遷移現(xiàn)有功能

架構(gòu)和基礎(chǔ)都打好以后，我們才開始遷移現(xiàn)有功能模塊。我們選擇了郵件交易確認(rèn)功能?？紤]點就是，相對風(fēng)險較小和容錯率相對高一點的業(yè)務(wù)模塊。另外，自動測試是遷移，特別是跨技術(shù)棧重構(gòu)遷移的重要保證。業(yè)務(wù)系統(tǒng)本身的重構(gòu)遷移開發(fā)和自動測試所用到的用例設(shè)計以及自動化工具，應(yīng)該是同步的。

5年過去了，這個就是如今的雙IT架構(gòu)的總體樣子。我們基本上探索出了我們的思路和路線，算是找到了一條可持續(xù)發(fā)展的路。另外，更重要的是，得到了業(yè)務(wù)部門、管理層和后續(xù)資金的支持，我們也把單純的技術(shù)遷移轉(zhuǎn)變成技術(shù)和業(yè)務(wù)的同步的遷移和創(chuàng)新。

3、新舊系統(tǒng)保持一致的敏捷節(jié)奏和統(tǒng)一的運維模式

打好了架構(gòu)和基礎(chǔ)之后，我們面臨的第三個挑戰(zhàn)是兩個系統(tǒng)有機(jī)并行，那么就需要開發(fā)維護(hù)兩個系統(tǒng)，平臺技術(shù)棧和用到的工具都不太一樣，團(tuán)隊越來越不負(fù)重荷了。我們通過應(yīng)用和自研相結(jié)合，構(gòu)建了一套自動化工具鏈，以及同時適配新老系統(tǒng)的開發(fā)運維一站式平臺，來幫助我們自己。

下圖是我們現(xiàn)在的團(tuán)隊所用的工具集的一覽圖，上面既有一些業(yè)界廣為應(yīng)用大家應(yīng)該也熟悉的一些工具，如Jira、Jenkins、CheckMarx，也有特別適用于IBM-I系統(tǒng)的一些工具，如RTC、RDI和Arcad，而帶星號的就是我們自己開發(fā)構(gòu)建的工具和平臺。

分享一下我們選擇工具和自研設(shè)計的一些理念。

1）優(yōu)先考慮業(yè)界優(yōu)秀的工具。

因為業(yè)界的工具會有很多的場景和用戶一起論證和不斷完善，它們一定程度會比我們自研的更周全。另外，采用業(yè)界的工具，可以讓我們精力和時間，更專注于我們自己在金融科技和業(yè)務(wù)領(lǐng)域的專長。

2）當(dāng)業(yè)界沒有合適的工具時，我們可以自己研發(fā)構(gòu)建。

例如我們針對IBM-I開發(fā)了IBM-I特有的編程語言RPG的自動掃描工具，以保證代碼的安全和質(zhì)量，還有前面提到的同時適配新老系統(tǒng)的自動化測試框架。

當(dāng)所有業(yè)界和自研的工具搭建完成后，一個新問題是：我們在不同的工具平臺之間輪換，已經(jīng)大大影響了我們的工作效率和質(zhì)量。為了解決這個痛點，我們又構(gòu)建了適合我們自己的開發(fā)運維一站式平臺，讓大家可以在一個平臺完成大部分日常工作。

我們的一體化平臺的實現(xiàn)思路并不復(fù)雜：現(xiàn)在大部分工具都是API接口的，我們只是on top搭建了一站式平臺，通過API自動觸發(fā)以及連接不同工具上的action，然后通過API從不同平臺抓取所需要的信息。之前，我們需要登錄10多個工具平臺，200多個點擊，才能完成一個標(biāo)準(zhǔn)的更改流程?，F(xiàn)在只需要登錄我們的一站式平臺，20多個點擊，就可以完成整個流程了。這個平臺對于我們同時需要支持新老系統(tǒng)的團(tuán)隊來說，幫助非常大。此外，我們也節(jié)省了很多對于同事使用不同工具的學(xué)習(xí)和培訓(xùn)的成本。

最后我想跟大家分享我們在開發(fā)構(gòu)建工具時對技術(shù)棧選擇的一些考慮。

• 第一，工具和平臺的構(gòu)建和運行，目標(biāo)也是遷離IBM-I，跟我們的愿景一致。同時我們的目標(biāo)是一套工具和平臺，同時適配新老系統(tǒng)。
• 第二，采用更開放的新技術(shù)棧來開發(fā)構(gòu)建工具，為原IBM-I技術(shù)人員提供從實戰(zhàn)中學(xué)習(xí)新技術(shù)棧的機(jī)會。我們有相當(dāng)一部分IBM-I程序員，在開發(fā)工具的實戰(zhàn)中掌握了新技術(shù)，成功轉(zhuǎn)型成為新老系統(tǒng)，新舊技術(shù)棧都懂，業(yè)務(wù)也很精通的跨界程序員，他們已經(jīng)成為我們這個遷移大計劃的骨干力量。

四、思考與總結(jié)

• 技術(shù)或者模型不分貴賤，IBM-I還是云，瀑布還是敏捷，沒有好壞對錯，最適合的就是最好的。
• 人和文化（people and culture）比技術(shù)更重要。各種技術(shù)只是工具，架構(gòu)和設(shè)計的理念，以及一直探索、學(xué)習(xí)和創(chuàng)新的團(tuán)隊和文化，才是永恒的。