大型銀行核心系統“迭代式”敏捷遷移之路
一、基于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多個點擊,才能完成一個標準的更改流程?,F在只需要登錄我們的一站式平臺,20多個點擊,就可以完成整個流程了。這個平臺對于我們同時需要支持新老系統的團隊來說,幫助非常大。此外,我們也節省了很多對于同事使用不同工具的學習和培訓的成本。
最后我想跟大家分享我們在開發構建工具時對技術棧選擇的一些考慮。
- 第一,工具和平臺的構建和運行,目標也是遷離IBM-I,跟我們的愿景一致。同時我們的目標是一套工具和平臺,同時適配新老系統。
- 第二,采用更開放的新技術棧來開發構建工具,為原IBM-I技術人員提供從實戰中學習新技術棧的機會。我們有相當一部分IBM-I程序員,在開發工具的實戰中掌握了新技術,成功轉型成為新老系統,新舊技術棧都懂,業務也很精通的跨界程序員,他們已經成為我們這個遷移大計劃的骨干力量。
四、思考與總結
- 技術或者模型不分貴賤,IBM-I還是云,瀑布還是敏捷,沒有好壞對錯,最適合的就是最好的。
- 人和文化(people and culture)比技術更重要。各種技術只是工具,架構和設計的理念,以及一直探索、學習和創新的團隊和文化,才是永恒的。