李懷根：廣發銀行研發中心總經理
本文根據李懷根先生在2018雲栖大會金融峰會上分享整理
大家好，非常榮幸能在雲栖大會的講台上跟大家分享廣發銀行的經曆和經驗。在過去的一年裡，廣發銀行IT研發人員與阿裡雲、螞蟻金服及相關服務商的工程師們并肩作戰，在網際網路架構轉型和移動應用重構方面做了一些努力和探索，并取得了一定的效果。
今天現場的各位金融行業的上司、專家大概能分成兩個群體，一部分是業務部門的上司，肩負業務轉型和業務創新的重任；另外是IT部門負責研發管理工作的上司和專家，或許正面臨着如何上雲、如何推動架構轉型等燒腦的決策。
業務與研發之間的故事，細說起來至少是一個長篇小說，甚至還可能是“武俠”小說。當業務人員評價研發工作時，他們常常會說“慢”，“非常慢”，“幾個月前提的需求還沒有做完？”，研發人員則回複“需求品質太差，想要什麼說不清楚”“總是變，當初需求說明書就是這麼寫的”。相信現場的各位對如上言語并不陌生，在社會的快速發展下，業務創新、技術創新，包括場景的創新經常會發生，不斷變化的業務需求給研發帶來非常大的挑戰，我們如何快速響應業務變化，快速響應市場需求變得尤其重要。
另一方面不确定性已經是現在這個時代的常态，經常會有換道超車、彎道超車案例發生。不确定性使得業務必須要去試錯，那麼研發的另外一個挑戰就是如何降低業務試錯成本。如果業務有一個想法，結果研發說需要兩個月的時間才能試出來，那麼業務就會望而卻步了。如果隻有兩周呢，業務部門肯定會大膽的進行試錯，在不斷試錯中尋找業務增長契機。是以除了快速響應外，研發的另一挑戰是如何降低業務試錯成本。
“厚中台、薄應用”架構轉型
面對業務的需求，在傳統的銀行架構下，研發人員即便是“九九六”也顯得應對吃力。于是，我們在2017年8月份啟動了中台架構轉型。
2015年阿裡巴巴提出中台戰略, 将核心業務中通用的、公共的子產品以服務的方式沉澱到中台，整個集團的核心業務能力均建立在這樣一套共享服務體系之上，在核心業務層通過共享服務中心實作了統一和暢通。銀行其實也一樣，有很多能力是基本固定不變的，比如賬戶能力、支付能力、認證能力等。但我們的産品系統、應用系統是需要随着業務變化而調整的，因為場景在變、管道在變。變化的部分以業務流程為主，能力部分多數情況下不用變動。
這也是廣發銀行在過去一年裡做的架構轉型，過去我們做一些應用系統時，我們會在每個系統裡把業務流程、背景管理，使用者認證以及使用者登入都建設一遍，手機銀行有一套，網上銀行有一套，櫃面系統還有一套。但現在我們單獨建設了一套能力中心，它們互相獨立，可以為所有産品互用。新的産品系統要上線時，它不需要獨立建自己的使用者中心，不需要再去做獨立的認證中心，也不需要再去建構自己獨立的支付中心。
确定架構轉型是工作的第一步，關鍵還是要落地。啟動初期，我們首先做的事情是對人員組織架構進行了調整。過去我們做一個應用時，從産品管道到背景的實作會有一套完整的團隊，既有前端也有後端，還有懂業務流程的後端人員。現在我們發生改變了，建立了獨立的中台産品團隊和中台研發團隊，他們負責建設能力，負責維護全行的能力地圖，這是在組織架構上最大的挑戰。第二件事情，這次架構轉型對我們挑戰非常大，因為過去的能力和經驗幾乎完全沒有用，我們要用新的方法建構，是以在正式實施任務前我們與阿裡合作進行了為期三個月的教育訓練。
架構轉型過程中堅持的三個原則：
第一：重要的事情要慢慢的做，要做得穩當。這是第一個原則，我和團隊說可以自己制定項目計劃，必要的時候可以往後延一個月甚至兩個月。如果我們追求速度，為了快點上雲，很容易會導緻匆匆忙忙就把這個項目的表層工作做完了，但中間的過程會走得并沒有那麼穩，沒有那麼踏實。
第二：設計優先。在整個項目開始過程中特别強調必須把所有設計做好，必須先定出設計規範，我們引入了領域驅動設計，這個模組化過程比較痛苦，因為要把所有業務部門請來按功能梳理，把問題獨立拆分出來。我們以前做項目時，習慣将需求從頭到尾串下來，但現在我們要把中間能力部分一個個摘出來，放在不同的問題域裡。過去我們做項目、做應用開發最缺少的一步就是模組化。這次在網際網路中台架構轉型中，我們特别堅持了要去模組化，要用DDD（領域驅動設計）方法重新拆解整個業務部門。
第三：堅持做持續內建，持續傳遞。我們引入了阿裡雲效平台每天做自動化測試，得益于不斷的測試與回歸，這個工程最終順利通過，同等體量下的項目多數情況下都會有冒煙的問題。
厚中台、薄應用，這是我們一直在堅持的。整個中台部分分成若幹個問題域獨立進行建設與發展，同時它又可以被所有的應用去調用，反複使用，避免相同的功能子產品重複建設，這就是我們過去在一年多時間一直堅持做的架構轉型。
對标超級APP，全面重構移動應用
廣發銀行有兩個App，一個叫做手機銀行，注冊使用者3千萬；另一個是信用卡門戶App發現精彩，2500萬注冊使用者，日活150萬左右，發現精彩每周五都有秒殺活動，秒殺的時候日活接近200萬。
在座各位可能都有這個印象，銀行App總體的體驗沒有網際網路App好。比如啟動比較慢，過去手機銀行打開白屏超過5秒鐘，而在網際網路時代，5秒鐘“白屏”的情況下使用者基本預設這個App已經“死”了；閃退、卡頓的現象也出現頻繁，其實閃退并不可怕，怕的是不知道誰閃退，不知道在哪一步出現閃退；另外還有諸如消息到達率低，導緻業務部門做營銷活動時不太敢去推送消息，影響業務營運等問題。2017年8月份，在一次新浪的移動App體驗評選中，廣發銀行手機銀行App得分排名靠後。當天我在朋友圈裡立下誓言，明年一定要把發現精彩和手機銀行拿下。
我們在2017年9月份啟動移動架構選型工作。在讨論選型原則時，我提出要對标超級App，跟它可以有差距，但要在一個層級上。最終我們選擇了脫胎于支付寶的移動架構平台MPaaS，其強大的營運分析能力，客戶無感更新，極高的到達率，可以按照時間、地區以及機型多條件試錯的性能等都是我們看中的原因。
全面重構，體驗至上。手機銀行和發現精彩這兩個APP體量還是非常大的，千萬級使用者，百萬級日活。最多的時候兩個團隊加起來接近300人同時作業，75%的業務在手機銀行完成，50%分期和交易占比在發現精彩中。我們有兩個方案，一個方案是做相容，對已經“腐化”掉的代碼修修補補，少改50%的代碼，同時留下50%的“垃圾”。另外的方案是完全重構，原來的代碼一行都不用，我們勇敢地選擇了重構，用全新的代碼設計，一行一行重新寫代碼。
我們在今年6月底推出了新版發現精彩，經過一個多月後已有85%使用者更新了版本，手機銀行上周也已經更新了内測版。目前發現精彩（IOS用戶端）熱啟動時間0.52秒，第一次下載下傳冷啟動時間是0.86秒，閃退率萬分之四。關鍵是我知道它是萬分之四，以往這個資料是無法擷取的，該名額與支付寶相當，卡死率（點某個按鈕10秒鐘沒有反應我們稱之為“卡死”）萬分之一。我們還學了網際網路的玩法，第一次在生産環境上進行線上全鍊路壓力測試，過去銀行是不敢做的,峰值達到4.5萬TPS。
關于轉型的思考
兩個轉型過程講完了，背後還是挺辛苦的，如果我今天的分享和實踐能夠推動大家對架構轉型進一步的思考，讓全行業銀行APP使用者體驗上一個台階的話，那我覺得還是非常有價值的。
最後跟大家聊聊通過一年來的轉型工作個人的感悟：
第一、業務和研發：深度融合、業務靈活。我們要改變和業務溝通的方式，過去追求高效率、專業化做事情的方式。現在變化太快了，必須讓業務和研發人員深度走到一起，要做業務靈活，深度融合。
第二、軟體研發唯快不破，速度決定成敗。隻有把整個研發程序放在“快”這個要求下，一切以“快”為目标，快速回報，快速響應，才能夠把環境供給、技術能力等有缺陷的部分暴露出來，及時加以調整。
第三，架構設計要有前瞻性，不建議“夠用就好”。現在業務發展太快了，今天的一個架構，明天可能因為一個新的業務需求，就觸及到了架構天花闆。過去我們有一個零售信貸系統，它針對線下抵押貸款業務綽綽有餘，但是當接入到網際網路管道，通過網際網路獲客時，這個系統就難以支撐。架構設計一定要有前瞻性，不能抱着“夠用就好”的态度。
過去的一年裡我們不停地做改變，改變需要勇氣，也需要堅持和正确的執行。我們不回避沖突，重構了網際網路服務中台。我們敢挑硬骨頭，換App架構，重構最重要的應用。敢于對标，就是要追求極緻體驗。過去我們經常為了省下開發成本，用所謂混合開發的模式，今天我們把App裡轉賬、查詢的功能首頁以及登陸、注冊等高頻環節全部做成了原生，追求的就是使用者體驗。
我們以終為始，堅持目标，相信才能看見，在相信和看見之間是一段漫長的堅持。我們要像發明工具的人那樣使用工具，我們在與阿裡巴巴的合作中請來了阿裡中台事業部的人來給我們做咨詢，我們要學習他們自身的使用方法。開源是一個低門檻，高代價的事情，我們要培養基礎力量，一定要把它研究透。
在過去一年裡，我經常用一句話鼓勵我和自己的團隊，《艾麗斯夢遊仙境》裡，紅桃皇後說了一句話：在我們這裡隻有不停的奔跑，才能留在原地！
原文釋出時間為：2018-09-29
本文作者：未若
本文來自雲栖社群合作夥伴“
阿裡金融雲”，了解相關資訊可以關注“
”。