傳統金融的運維如何應對互金時代的業務衝擊？

文末有【彩蛋】

作者簡介

張建林

招商銀行 數據中心應用管理負責人

20年運營開發、海量運維和應用規劃管理經驗，任招商銀行數據中心應用管理負責人，主要負責招行應用架構規劃、發布、監控、運維等應用全生命周期管理工作，精通應用架構設計和自動化運維建設，目前專註於應用全生命周期的自動化運維實踐。

前言

本文根據招商銀行數據中心應用管理負責人張建林，在GOPS2017·深圳站演講整理而成，文章共分為五個小議題：

傳統金融IT應用運維痛點分析

思想的碰撞

困局之下如何求變

成果初現

自動化運維之路

1、傳統金融IT應用運維痛點分析

可能大家都知道, 傳統金融遇到了一個瓶頸，而互聯網金融給我們帶來很大衝擊。傳統金融應用運維的發展趨勢是，系統規模越來越複雜，組件越來越多，用戶的流量不斷上升，事件變更各指標較以往而言不是量級增長，而幾乎都是呈非線性增長。

傳統運維模式帶來的成本消耗比較大，已經不能很好地應對非線性增長的系統規模和流量。解決的方法是要做好傳統金融業務的主機下移，與做好應用全流程運維的標準化管控。那麼我們需要如何應對這方面的需求呢？接下來，我們針對傳統金融的痛點做分析。

通過對傳統金融的痛點做分析，可以發現「非功能」是根本原因。因為要針對目前系統運維成本和流量接入，我們一定要做到應用運維全自動化才能應對目前的現狀。

當前運維環境下，非功能引起的事件比較多，我們拿招行2016年的生產事件做分析，可以發現與非功能相關的事件佔比將近三成。無論是從應對自動化的需求、接入的需求、傳統的可用性要求、還是變革的期望，我們對於非功能的需求越來越強烈。

2、思想碰撞

面對我們當前的痛點，我們怎麼做思想碰撞呢？首先，傳統金融IT的模式中，開發與運維是割裂的，開發對運維基本上是「甩包袱」的形式。

其實，流程和自動化並不矛盾，但是我們如何做到開發和運維優雅的結合呢？招行採取的方式是圍繞運維自動化去做。通過非功能的落地、運維繫統的規範標準化，並通過規範制定自動化的工具，再結合現在的流程，形成迭代的完善，最終達成運維自動化的目的。

這可能是現在比較流行的 DevOps 的思想。DevOps 和 SRE 的理念會有些許衝突，但整體思路是一致的，都是加強開發和運維之間的配合。DevOps 可能更側重開發層面將自動化的理念推送給運維，而SRE 的理念則側重於運維人員角度，它的理念是運維的自我研發，我們運維怎麼去開發出適合我們工具，通過工具來進行日常運維的工作。

目前，招行已經將以上兩個理念都承接到現在的運維工作中，招行對運維的管理已經做了一套流程，固定了由 DevOps 理念形成的、適用於招行的一套持續交付的流水線平台。

接下來是優化現有開發模式和現有產品架構，消除流水線流動障礙。構建輕開發測試的發布流程，做到發布全生命周期的自動化。

3、困局之下如何求變

在當前流行的 SRE和 DevOps 上，我們如何融合他們之間的差異點，選擇適合我們招行的解決方案，是一個關鍵。這兩個理念不衝突的是持續迭代的交付，也是我們一定要做到的關鍵點：承接開發給我們的產品發布和如何運維好這些交付的產品。

3.1 以非功能管理為抓手的應用運維持續改進

我們如何能快速做到這一點呢？首要任務是做到產品發布的自動化。而支撐自動化的基礎，則是一定要有一個非功能管理的運維工具，並對其持續改進。

所以我們的做法是，先要對產品規範的制定，再有架構能力的提升，接上流程管控，運維工具的自動接管，還有運營數據的分析和挖掘，並形成持續改進的循環。這就是我們以非功能管理為抓手，推動應用運維的持續改進和自動化的改進的方式。

3.2 非功能矩陣

講到具體的落地，首先講講非功能管理規範中的非功能的矩陣。

首先我們運維需要面對的是一個多且雜的龐大的系統體系。面對這種情況，我們對招行的系統進行了歸類，針對不同的部署平台和應用場景進行分解和剖析。梳理出針對不同部署平台、應用場景適用的非功能矩陣。歸類情況如下：

1. 應用場景：針對招行現有的架構，結合招行對非功能要求，對應用場景，我們做了如下的分類：

前端應用

後端應用

聯機事務處理

聯機分析處理

2. 部署平台：招行的產品部署平台包括390、AS400、以及開放平台，而開放平台是未來發展的主流。

3. 非功能指標：同樣，我們對招行系統進行分類的同時，為了方便對非功能指標的維護、管理及更新，我們也對非功能指標以及其驗收方式也進行了梳理和規範。

可用性：我們對產品的高可用和數據備份管理提出明確的要求，保證各產品上線後的穩定和持續運行。

可維護性：對於產品的可維護性，我們提出提升進程自愈管理能力、加強日誌管理能力、強化進程維護和柔性功能，提升業務指標監控和探測能力。

容量規劃：對每個產品，我們都會對業務容量做提前規劃與度量，固化應用性能評估，明確要求數據歸檔策略。

技術規範：對產品要有明確後台跑批任務管理辦法，規範應用部署路徑和日誌格式標準化的管理，明確運維文檔的要求。

4. 驗收方式：以前對一些非功能需求的提出，比較少，並且落地驗收更少之又少，為了非功能指標的落地，我們對非功能指標的驗收方式進行的分類，按照不同的指標採用不同的驗收方式進行落地的驗收：

測試驗收

數據的交叉檢驗

自動化工具的驗收

人工驗收

3.3 非功能公共技術組件庫

有了產品的非功能規範後，對於招行的產品所採用的不同的技術、不同的框架和不同的部署平台，我們應當如何實現非功能的統一管理？我們做成了非功能技術組件庫，直觀看起來似乎比較複雜。

先從資源層看起。目前招行所有系統是以單個系統為單位進行切割，而我們則以部室為單位進行切割。

基於資源上的應用，我們怎麼把它真正落地到運維的自動化呢？通過將非功能公共組件、技術組件做成抓手，我們從資源層裡面提取公共組件的數據，比如安全、日誌、消息、數據訪問、緩存、文件管理的公共數據。

除了公共數據之外，我們提出了標準化的非功能技術組件庫，這個組件庫是一個以我們非功能規範作為的技術標準，跟其他平台適配的API公共組件，供開發調用。該組件庫適配各種開發語言、框架和平台，可以使開發人員更專註業務功能的實現。這樣就實現了以非功能公共組件推動業務功能開發的效果。

完成了 API 的開發之後，研發中心還提出剛才講的性能容量和應用架構改進的訴求，但是招行現有系統中存在各種各樣的業務組件，這就要求我們的 API、以及我們的應用要做到對高可用、性能容量有一個自我探測的功能。

我們做完非功能組件之後，就是我們運維接管的事情了。我們的目的是為了運維的自動化，所以首先要做就是自動化平台的整合及開發，這就要求我們的平台有自動化發布、一體化監控、API 網關、數據平台、作業平台、管控平台等功能。我們的自動化平台對運維的工作進行了整合。

以往運維涉及的自動化平台太多，我們沒有辦法將他們之間割裂的部分逐一統一起來。現在，我們有了非功能組件，通過非功能組件，我們能把底層的資源、開發的規範和對高可用的應用訴求都在公共組件裡面集中實現並通過它來協助我們的自動化平台對運維工作進行整合。

當實現之後，我們怎麼知道開發所交付的產品確實能做到自愈或者滿足我們的非功能要求呢？這就要求我們做到應用全流程的監控。

我們的做法是採用探針式應用全流程的監控，上面是用戶的公共介面，用戶通過客戶端的公共介面訪問我們的伺服器，通過我們的探針，將用戶的行為及應用的處理等信息收集起來。

在自動化平台中，我們將會對這些信息進行監控及分析，確保我們開發所交付的產品符合我們的非功能要求。而核心就是我們的統一組件庫。

3.4 應用框架設計優化

在架構的實現上，我們大體上參考了架構優化的精髓，這裡提出來的，主要是架構設計的理念。

首先考慮市場響應，將構建小、發布快、實效小做為考量依據；

其次是成本，站在成本方面考慮，一般情況下，我們都會使用較為成熟的技術，對於非核心的產品，對於不是我們最擅長的，也提供不了差異化的競爭優勢的產品，則直接購買；對於我們所使用的商品化的硬體，我們的原則是在大多數情況下，便宜的就是最好的；

三是產品的非功能性，產品的非功能性我們主要關注產品的可用性、可擴展性、可維護性等質量指標。

綜合這三方面的考慮出發，我們就很容易得到了我們對應用框架設計優化的基本參考原則：

N+1設計：永遠不少於兩個伺服器（互為主備）

回滾設計：確保系統可以回滾到以前發布的任何版本

禁用設計：能夠關閉任何發布的功能

監控設計：在設計階段就必須考慮監控

多活中心：不要被一個數據中心的解決方案限制住

使用成熟的技術：只用確實好的技術

非同步設計：只有在絕對必要的時候才進行同步調用

無狀態系統：只有確實需要的時候，才使用狀態

水平擴展：永遠不要依賴更大、更快的系統

設計至少要有兩個步驟的前瞻性：在擴展性問題發生前考慮好下一步的行動計劃

非核心則購買：如果不是你最擅長的，也提供不了差異化的競爭優勢則直接購買

使用商品化硬體：在大多數情況下，便宜的是最好的

小構建，小發布，快試錯：不斷迭代

故障隔離：實現故障隔離設計，通過斷路保護避免故障傳播和交叉影響

自動化：如果機器可以做，就不要依賴於人

3.5 性能容量動態擴容

接下來，說到性能容量擴展。我們怎麼做應用性能容量擴展？這裡我們以 AKF 擴展立體方理論為基礎參考，劃分 XYZ 軸。我們傳統的是通過Y軸的擴展複製，但這並不能滿足我們對性能容量的擴展需求。所以，我們根據客戶的數量、應用的組件庫還有客戶層面不同，我們針對性做了三種不同的擴容方式。

從應用層面上來看，無論針對應用做怎樣的擴展，基本上都是按照這個理念做。

X軸：應用無差別複製、克隆。例如：我們會部署N台同樣的應用伺服器，我們採取這種策略來應對應用伺服器不斷攀升的壓力。

Y軸：根據功能分割。這是因為很多應用功能所消耗的資源以及交易高峰並發時間都不是統一的，有些功能消耗資源較大，有些功能資源消耗就相當少，而且這些功能都是可以獨立出來的，例如用戶信息維護功能和用戶的交易功能。

如果僅僅是對伺服器無差別複製和克隆，可能對運維瓶頸沒有突破，或者說成本相當高。這就是我們根據功能對伺服器進行分割方式，基本原則是針對不同的交易類型就通過不同的伺服器處理，以此達到對性能提升的擴容目的。

Z軸：根據客戶分割。如果只按應用功能跟伺服器數量方面進行擴容的話，不同地域的客戶數量和訪問速度都存在很大的差異，故面對不同地域的伺服器壓力也會存在差異，所以我們在應用層面還必須按不同地域的接入量來做性能容量的切割，比如對南方接入、北方接入的客戶進行分割。

我們對應用層面對伺服器進行分割的同時，為了使伺服器性能達到進一步的提升，還在數據層面進行了進一步的優化。

數據分割與應用分割差不多，但也有差異。

X軸：無差別複製和克隆。主要體現為讀寫分離的資料庫架構對於不同業務功能分別訪問不同的伺服器，達到對資料庫壓力的分攤。

Y軸：根據功能分割。體現為根據交易資料庫和日誌庫數據分離，提高交易響應時間。

Z軸：根據客戶分割。通過做分庫分表的架構，按客戶某一特徵進行取模或哈希來分配不同的資料庫，從而降低資料庫伺服器的壓力，從而讓客戶有更好的體驗。

3.6 非功能流程管控

怎麼做好管控？

運維在項目立項階段就開始介入非功能管控的設計。通過和項目室對接，和開發需求對接，在項目立項開始階段，我們已經介入一些非功能的設計和訴求的提出，以保證開發及項目室和運維是同步的，達成無縫隙對接。

我們做的所有非功能，最終目標都是運維自動化。所以我們除了原流程上的功能開發和 ST/UAT 測試驗收外，我們還增加了對產品非功能的開發，非功能的測試和驗收，以及運維自動化模塊的集成。

我們提出這些非功能的訴求，無外乎是為了開發能按照我們的公共介面、公共組件進行開發，並根據我們的性能容量的框架要求，以及自動化平台的要求做好產品開發，做到開發工作和我們運維工作的無縫對接。

所以在基本訴求提出之後，運維就要和開發一起進行評估、立項，乃至最後開發。開發完之後，我們將對開發的非功能進行測試和驗收，並與自動化平台進行對接。只有在測試結果滿足運維對非功能的要求時，才允許它投產上線。這不僅為了讓產品在上線後持續穩定地運行提供更好的保障。更為了後續實現運維自動化打好基礎。

產品投產上線後，我們還將對產品進行持續的跟進以及評估，對應用質量做事件回顧，以此來發現我們設計的非功能和開發開出來的非功能對自動化運維和生產事件存在的缺陷及問題，我們後續需要針對這些缺陷和問題，對產品進行重新優化和設計。這是我們對產品從開發到上線的非功能過程的管控方法。

3.7 自動化工具平台

非功能管控我們做運維工具自動對接，自動化平台怎麼具體落地？

自動化工具平台，基本上接管了整個數據中心，從開發到測試之後到我們運維階段的全流程管理，面向業務支撐全生命周期自動化接管了。

自動化接管包含什麼呢？包括上線擴容、發布、日常運維、服務請求、下線、故障處理，都需要做到統一的平台里去。我們的目的是為了保持傳統運維模式的安全的同時，達成具備自我設計、自我修復能力的數據中心。我們的框架和實現理念已經落地，這就為做實現全自動化運維的數據中心打好了基礎。

自動化平台的設計理念：

以全生命周期情景，梳理出具體的自動化需求。我們會根據各個業務品種做自動化的訴求，比如網銀、手機銀行等等。

基於API網關中的API基礎服務，按照需求完成運維管理平台，支撐全生命周期自動化管理。

如果這個平台支撐它的管理之後，但是我們的工具平台的引擎、數據怎麼做呢？我們會有一個API網關還有流程匯流排，會把它快速提升自動化應用。

根據API規範，將功能和服務封裝成為標準API。在我們講的數據源裡面做真正數據源的匯總，最後支撐自動化的應用。

這是我們自動化運維平台的設計理念。

3.8 應用全流量監控

自動化運維設計之後，還有應用全流程監控。自動化發布之後我們怎麼做運維呢？圖中就是現在的自動化的監控，我們通過它對目前產品的非功能還有運維、應用質量做實時監控。我們會做到節點上線即刻監控，我們將通過NPM節點連接質量監控對Web端到中間件、再到應用伺服器、到最後的資料庫等等（包括中間的各個節點）進行全解碼的監控，基本上所有業務流、業務性能容量和真正的交付都做了第一線監控和實時展示。

3.9 性能容量預測

最後是性能容量的預測，也就是運維數據的分析和挖掘。我們會把性能數據和價格數據統一收集到一個數據解析中，並且將相關的依賴關係、配置信息、每個伺服器需求的數據資源預測數據等集中到大數據平台之後，通過求解器，結合容量演算法、資源供給、資源價格及分配計劃，形成一個演算法。

這個演算法是通過性能的實時參數、業務增長趨勢的函數、性能容量預測等方面進行實現。我們通過該演算法，能得到諸如連接、響應時間、趨勢分析、CPU 內存、硬碟使用率等方面的趨勢分析。現在，我們能做到所有應用節點的性能容量實時的展示，並且能做到實時的數據分析。

這樣的好處是，我們不需要通過壓測以及煩瑣的數據收集、大數據分析，基本上通過全自動化就能自動出現性能的趨勢圖和後續分配計劃匹配。

4、成果初現

我們逐步深化非功能的管理，我們管理的流程給大家分享一下。

我們的非功能管理平台已經搭建起來，這是由運維先提出的非功能規範。這是針對開發的所提出來的，因為傳統的開發都比較關注功能的實現。而我們的要求是，開發一定要將功能和非功能同等看待。

首先我們會通過應用非功能管理平台對產品提出非功能的規範和需求。接下來，我們的開發將對其進行開發，通過非功能測試及驗收，完成最終的版本確認。最後，把已具備非功能要求的產品與自動化的工具平台對接，落地自動化工具之後，最後自動化平台將自動對產品進行上線投產，再完成上線驗收。

開發是否完全按照我們的訴求做研發呢？最後是否真正落地運維的自動化呢？這就要依賴於投產之後的驗收，以及後續不斷的迭代循環。

基於 Profile 的應用標準化管理。在這裡我們可以通過應用系統視角，描述應用系統裡面的產品編號、名稱、人員、管理員、組件還有程序等之間的關聯關係，詳細記載應用各項非功能屬性信息。在把應用非功能屬性標準化之後，開發發布過來的應用，數據都是完整的，我們做後續的管理和台帳或變更，都能很容易達成自動化管控。

有了標準化數據之後，圖片上的功能都可以做到自動化實現，並且做到自動化的應用畫像，可以清晰地知道應用流到底怎麼走。

我們還會對一級環境和二級環境環境進行自動化的驗證，也就是大家常說的試運行和灰度環境，我們從灰度環境到生產環境，會不斷做兩個版本之間的驗證，並且我們的驗收是通過自動化的方式進行驗收的。

所有產品在投產之後，還要做節點的監控，確認剛才所說落地的東西已經真的已經達到了我們的要求，這就要求我們在變更之後的對產品進行全自動化監控。我們會有一個演算法，即對比運算模塊（核心是基線、閥值），這是一個自我學習的驗證模塊，也是驗證的核心。

我們核心模塊怎麼完善？我們會對原節點的數據和外部節點的數據、原始節點數據反覆對比，最後到運算模塊之後，從對比裡面可以發現一些流量中不存在或者節點屬性關係缺失的，我們可以對缺失信息去協調數據的進項，完善應用模塊，並且在已知節點的對比，發現節點訪問關係變更，包括新增、消失、訪問關係變更，我們都會做自動更新，我們通過這個實時監測運維所監管的所有應用的健康狀況，還有非功能的運維狀況，還有所有自動化發布或者自動化運維工具的現狀。

5、自動化運維之路

剛才講到所有的非功能實現的理念，無論是框架、架構、性能容量還有監控還有發布、自動化，我們最終都是為了自動化運維。

自動化運維即是最終的目標。以前的傳統模式下，需要做應用需求、資源準備、環境構建、公共組建、日誌追溯、應用開發、代碼部署、監控告警等工作。我們在做非功能時，把這些全部集中在一個模塊，即都在非功能公共組件裡面實現，應用需求提出之後，我們就把它集成到這個平台里。

將公共組件和自動化平台對接後，就實現所有資源準備、環境準備等等方面的全自動化，所以現在基於招行所推崇的 SRE 的開發模式，就是我們運維和開發一起完善功能和非功能的需求整理。

需求完善之後，就根據我們公共模塊的要求規範做開發。開發之後，後續所有傳統的模式下的工作，我們都可以一鍵式交給自動化發布平台，自動化運維就實現了。自動化運維代替了以前分布式的所有工作，包括資源準備、環境構建、組件的升級、日常的監控、日誌的管理等。這是招行的自動化理念。

6、總結

我們有了自動化理念，並實現了所有自動化理念後。我們的工作重點，就從傳統的金融IT模式轉變為以非功能模塊作為核心、作為抓手的自動化運維模式。

從功能需求開始，與開發共同參與產品非功能設計，並且在非功能公共模塊里支持和推動開發立項，並不斷完善自動化工具的集成，完成運維對自動化所有的訴求。

我們將所有自動化運維的訴求都提出來，統一監管 API，並且將介面提供給開發。開發完畢之後，我們對產品非功能進行驗收和投產後評估等工作就可以和自動化平台進行無縫對接。當把所有整套流程運作完成之後，我們就真正能實現運維工具的自動化集成，做到真正的運維的自動化。

這是我們今天講的主要議題，即傳統金融IT怎麼應對現代日益增長的運維瓶頸，怎麼解決訴求和應用的擴展。通過非功能的推動，達到自動化真正的落地，做到傳統金融非功能工作的重心轉變。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！