來源：大鵬雜談丨作者謝鵬

因為工作原因，我與銀行的信息科技部門打交道比較多。在和這些“甲方”客戶聊天的時候，我常問他們一個問題：你們到底是干IT的還是干金融的？

很多人都覺得自己是干IT的。

但事實上，IT是金融的“果”，金融是IT的“因”。

IT只是銀行業(yè)為客戶（對公/對私）提供安全、穩(wěn)定、可靠、便捷、全方位的高質(zhì)量金融與增值服務而帶來的“果”，而這個“因”，實際上還是銀行業(yè)在風險完全可控的前提下，圍繞所有與金融直接或間接相關的活動場景（比如存款、投資、融資、支付、核算...），為客戶提供相應的產(chǎn)品和服務。

隨著信息化建設的推進及互聯(lián)網(wǎng)企業(yè)的顛覆式創(chuàng)新，這些金融活動場景，正在加速從線下渠道走到線上渠道，銀行只有通過不斷提供更加友好、創(chuàng)新產(chǎn)品體驗（比如易用可視化的交互、技術含量較高的生物識別），才能在同業(yè)競爭中獲取更好的口碑及更多客戶。

互聯(lián)網(wǎng)企業(yè)利用后發(fā)優(yōu)勢，不斷通過將大數(shù)據(jù)、云計算等新興技術與傳統(tǒng)金融相融合，為大眾提供更加安全高效便捷的金融服務，這對傳統(tǒng)銀行業(yè)的優(yōu)勢領域形成一定挑戰(zhàn)和壓力，但同時也為銀行業(yè)改革發(fā)展轉(zhuǎn)型帶來了新的指導和動力。在這樣的大背景下，“信息科技”就成為銀行業(yè)抵御風險和增強競爭力的關鍵。

因此，近年來很多銀行都提出“科技興行” 、“科技是銀行的第一生產(chǎn)力” 、“科技引領”等戰(zhàn)略口號。為了化解壓力和挑戰(zhàn)，銀行業(yè)務部門需要深化客戶需求，不斷優(yōu)化、新增更具創(chuàng)新的產(chǎn)品和服務。

對于銀行信息科技部門來說，一方面要不斷響應業(yè)務部門需求，開發(fā)出更多的軟件產(chǎn)品與之對應，另一方面還要保障過去已上線業(yè)務的穩(wěn)定可靠運行。因此，相當一部分業(yè)務的壓力被轉(zhuǎn)移到信息科技部門，這也觸發(fā)了信息科技在軟硬件產(chǎn)品和運營管理方面的創(chuàng)新和變革。

在這個變革的過程中，信息科技部門不得不面對各種業(yè)務架構的坑——

應用系統(tǒng)由于部署模式的原因，導致硬件資源上存在豎井現(xiàn)象。這種情況，絕大部分可以伴隨著IT基礎設施層面的技術發(fā)展，利用虛擬化和云計算進行彌補和改善。

但是應用系統(tǒng)所承載和對應的業(yè)務產(chǎn)品服務，卻如同一只看不見的手，悄無聲息的搭建出了很多形式各異的服務豎井。

這種豎井出現(xiàn)的原因其實很簡單：隨著業(yè)務規(guī)模和服務范圍不斷擴張，應用系統(tǒng)在投產(chǎn)運行3-5年后，原來設計的軟件架構不一定能很好的滿足業(yè)務的發(fā)展，同時，由于研發(fā)部門對需求的理解偏差、及及每次需求臨時變更，都會導致服務豎井的出現(xiàn)。

我過去一半的職業(yè)生涯，都是軟件攻城獅，對此深有體會。比如，當收到一個新的服務需求變更時，由于之前服務設計的通用性和業(yè)務前瞻性不足（大神級除外，而且銀行外包服務商考慮人員成本問題，通常人員能力參差不齊），要滿足新的業(yè)務需求，就要在原有的數(shù)據(jù)模型和業(yè)務邏輯上做出較大的改動，這是很多軟件工程師最不想做的，而且時間緊任務重，因此更多的人會選擇放棄對新業(yè)務需求的支持，保持現(xiàn)有服務穩(wěn)定，重新開發(fā)一套跟這個服務差不多的功能模塊。

長此以往，就會有大量的功能和業(yè)務在多個系統(tǒng)中同時存在，逐步累積隱患。

伴隨業(yè)務部門的需求增長越來越迅猛，銀行信息科技部門在對原有系統(tǒng)的改造升級就變得越來越吃力，而且隨著時間的推移、人員的流動，到最后某個關鍵應用系統(tǒng)可能已經(jīng)復雜到誰也講不清楚，原來對外提供的業(yè)務服務到底分散在哪些產(chǎn)品模塊中，又會被哪些系統(tǒng)使用。

一旦發(fā)生故障，大家都如坐針氈，對業(yè)務響應的能力也就顯得愈發(fā)緊張，直到有一天信息科技部門再無法再滿足業(yè)務部門新的需求。

業(yè)務系統(tǒng)的潛藏豎井越來越多，運維管理的成本和復雜度也逐年攀升。

最終，一套系統(tǒng)在生產(chǎn)環(huán)境的交易鏈路，可能復雜到無法直視的地步，讓信息科技的管理者感覺整個應用系統(tǒng)和業(yè)務服務都處在失控的狀態(tài)。

為了化解這種困境，業(yè)界早在十幾年前就提出了面向服務的架構（SOA，Service-Oriented Architecture）理念，它將應用程序的不同功能模塊（稱為服務）進行拆分，并通過這些服務之間定義良好的接口和規(guī)范聯(lián)系起來。

SOA的出現(xiàn)，給傳統(tǒng)的信息化產(chǎn)業(yè)帶來新的概念，不再是各自獨立的架構形式，能夠輕松的互相關聯(lián)組合共享信息。

按理說只要充分了解業(yè)務邏輯，利用SOA這種松散耦合理念，就可以不用編寫太多代碼，通過業(yè)務流程圖就可以快速搭建一套新的應用系統(tǒng)。

然而不幸的是，在過去10年中，銀行絕大多數(shù)客戶只是利用SOA的理念簡單，從技術視角做了個企業(yè)服務總線，將原本錯綜復雜的服務做個整理，實現(xiàn)了業(yè)務架構上的系統(tǒng)互聯(lián)互通，并未真正實現(xiàn)一個企業(yè)內(nèi)部的服務路由樞紐和渠道，也就沒有真正發(fā)揮出SOA理念最核心的價值：松耦合的服務帶來業(yè)務的復用，通過服務的編排助力業(yè)務的快速響應和創(chuàng)新。

回頭再看SOA項目建設過程，我們不難發(fā)現(xiàn)，在業(yè)務架構轉(zhuǎn)型的過程中，只有持續(xù)運營、完善和改進這些服務模塊，讓其變得更加穩(wěn)定和靈活，才能逐步成為企業(yè)在某領域最為專業(yè)的服務能力。

衡量這些服務能力好壞的標準，目前業(yè)內(nèi)還沒有一個定論。但是我覺得應該包括一些服務成功率、請求頻率、請求響應時間等關鍵指標。

只有這樣，我們才能分析缺陷問題，確認改進方案，持續(xù)優(yōu)化改進服務接口能力，才能真正達到SOA中所描述的業(yè)務的快速響應，更好地支持業(yè)務創(chuàng)新，然而走到這一步卻異常的艱難。

在過去很多年中，我們在銀行里會經(jīng)?？吹竭@樣一幕：一個系統(tǒng)上線運行5-8年后，信息科技部門會不斷提出“現(xiàn)有系統(tǒng)不管是技術架構還是業(yè)務架構，都不能滿足未來業(yè)務長久發(fā)展的需求，需要整體升級”，而這樣的升級往往意味著推倒式重建。

拿J行來說，從2010年底開始規(guī)劃重構包括銀行與非銀行業(yè)務，這是一次涵蓋基礎設施、業(yè)務、技術、實施在內(nèi)的系統(tǒng)性升級工程。

該行首先把業(yè)務解構成可以被業(yè)務或產(chǎn)品重用的組件和構件，參照SOA理念將業(yè)務劃分為自治而相互依存的部件，不但可以被獨立優(yōu)化提高業(yè)務運營模式的靈活性，而且可以依據(jù)離散且可重用的服務進行業(yè)務建模，將所提供的服務發(fā)布在網(wǎng)絡上， 與其他應用進行集成存儲業(yè)務服務，這也最終為該行后來發(fā)布的公有云打下堅實的基礎。

該行的整個轉(zhuǎn)型升級過程，三期分步實施，持續(xù)6年之久，于2017年6月主體功能全部投產(chǎn)，實現(xiàn)由原本面向單一項目管控，向 “一套業(yè)務模型、一套IT架構、一套實施工藝、一套管理流程”模式轉(zhuǎn)型。

雖然該行這樣推倒式重建，對現(xiàn)有業(yè)務帶來了不小沖擊，有不少基礎功能的重復建設和資源投入，但是這次升級改造實現(xiàn)了其IT系統(tǒng)建設模式從“部門級”到“企業(yè)級”的根本轉(zhuǎn)變。

而且由于從頂層設計出發(fā)，構建一個更健全、更規(guī)范、更靈活、更穩(wěn)定開放的“集中式 分布式”融合架構，使它既適用于瀑布式大規(guī)模開發(fā)，指導大型商業(yè)銀行戰(zhàn)略轉(zhuǎn)型項目的順利實施，也適用于迭代式的敏捷開發(fā)，推動諸如該行龍支付等創(chuàng)新產(chǎn)品的迅速投產(chǎn)。

最近該行房屋租賃業(yè)務更是搞的風生水起，由此一躍成為銀行業(yè)爭相學習模仿的榜樣。

該行于2018年4月份成立金融科技公司，嘗試為同業(yè)、企業(yè)和戰(zhàn)略伙伴提供領先的金融級IT服務，引領行業(yè)能力輸出，并于2018年11月份獲得銀行科技發(fā)展特等獎的殊榮。

我也有幸參與了這次轉(zhuǎn)型升級的起始和收尾工作，在此非常感謝那些曾經(jīng)跟我一起奮戰(zhàn)在第一線的小伙伴們，我們一起見證了該行的轉(zhuǎn)型歷程。

中國銀行業(yè)信息科技“十三五”發(fā)展規(guī)劃監(jiān)管指導意見提出，“各家銀行持續(xù)提升信息科技服務能力，構建綠色數(shù)據(jù)中心，推進運維自動化和智能化，提升數(shù)據(jù)中心運營管理能力成熟度，實現(xiàn)基礎架構轉(zhuǎn)型升級，提升信息技術架構管控能力....”

雖然政策壓力不小，但每家銀行業(yè)務規(guī)模、戰(zhàn)略規(guī)劃、歷史包袱、人員能力都不盡相同，如果選擇像J行這樣大破大立推翻重做一站式解決方案，不但要付出非常大的努力，還需要去承擔比較多的資本風險、人員風險、時間風險等。

因此大多銀行采用比較穩(wěn)健的架構轉(zhuǎn)型方式，分階段分步驟，逐步將非交易類、核心賬務類豎井式業(yè)務系統(tǒng)，從傳統(tǒng)平臺逐步遷移到開放平臺，采用微服務架構的方式針對逐個系統(tǒng)進行升級改造，這樣不僅可以保障整個IT架構能夠平穩(wěn)過度，也能靈活適配瞬息萬變的互聯(lián)網(wǎng)業(yè)務需求。

凡事有利就有弊，無論各家銀行采用哪種轉(zhuǎn)型升級模式，都能在一定程度上緩解信息科技部門對業(yè)務部門的響應壓力，但是為了穩(wěn)妥起見，大多銀行實際上還是維持新老架構同時運行，而這樣的雙態(tài)數(shù)據(jù)中心，不但增加了整個數(shù)據(jù)中心的IT架構復雜度，而且增加了系統(tǒng)運維的壓力。

為了保證這些業(yè)務系統(tǒng)“穩(wěn)定、可靠、安全”運行，提升運維管理的效率，信息科技部門采購了大量的運維管理工具。

拿Z行來說，他們在18年籌備智能運維平臺時，梳理了包括自研和外采行內(nèi)正在使用的運維系統(tǒng)，居然有77套之多

Z行總共需要運維的業(yè)務系統(tǒng)，才不過500多套，為何會出現(xiàn)如此之多的運維管理工具？

這些工具都是怎么產(chǎn)生的？各種類別運維管理工具林立，會不會也有出現(xiàn)業(yè)務系統(tǒng)式豎井？

這又是一個很大的話題……