【銀行運維】落地平臺化管理，大步邁向銀行4.0
藍鯨平臺做爲當下最受企業歡迎的研運一體化平臺，已經在不少企業內落地實施，在銀行業也獲得了普遍的推廣，但實施的規模，建設內容，推廣方式以及應用效果卻各有不一樣。本文以兩個典型銀行爲例，對比分析藍鯨建設方式區別和緣由，同時基於平臺特性，對藍鯨在銀行的應用方式給出相關的建議。設計模式
銀行業務運維現狀分析
隨着互聯網的快速發展，銀行從單一的網點渠道服務到現在的多渠道和全渠道業務，可是銀行的中心仍然是基於網點的設計。與其餘服務平臺同樣，銀行來到了一個須要不斷改變以適應客戶需求的世界。即將迎來銀行4.0時代，基於5G、大數據、雲計算、人工智能等新興技術，銀行全面開展數字化轉型。安全
新時代一樣也帶來了新挑戰，銀行業務更趨於敏態化，敏捷、開放、高效等成了業務運維的重要需求。同時，傳統金融業務等穩態業務對安全、穩定、可控的要求也仍然存在。新時代下，如何作好雙態運維成爲了銀行IT運維的巨大挑戰。同時，隨着業務及運維的持續建設，部分問題和困惑也逐漸暴露出來。
架構
一、問題與困惑
煙囪運動框架
運維工具在各自能力範圍內可以較好的知足使用需求，但因爲各運維工具基本獨立建設，運維工具之間缺少服務調用、數據交換等方面的標準，難以造成協力提供服務， 不便於運維工具使用效率的提高。運維
運維工具通常由工具建設方維護，受限於平常工做的負載，在需求的應對與功能開發方面速度較慢，工具使用人員對運維工具的瞭解程度也有限，該狀況不利於運維工具使用場景的推廣。
分佈式
能力缺失ide
部分運維工具爲早年建設，產品服務和發展前景不明朗，特別是廠商服務能力的降低，嚴重影響了現有工具的使用。微服務
隨着新技術的引進，原有「監」、「管」、「控」產品，沒法支持MySQL、Tomcat等開源技術產品，對部分軟件產品新版本也不支持。工具
現有運維工具的覆蓋面不全，現有功能點沒法跨多個系統進行場景式的編排，閉源產品改造難度大，開源產品維護成本高。
佈局
轉型需求
銀行運維正在從手工化向自動化演進的過程當中，將來須要進一步實現「數據化、智能化」的目標。
經過經驗的積累、同業與互聯網企業的調研可知，系統運維中心的轉型不是單靠引入系統、建設平臺便可達成目標，系統與平臺的建設只是打造一個轉型的基礎，而更爲關鍵的是運維人員的培養及管理的配套。
針對上述問題，銀行IT從業者不得不思考如何進行煙囪治理，如何建設工具以及如何促進運維轉型。
二、建設與轉型
平臺化建設
亟需建設統一運維平臺，將API網關引入到運維工具建設中，把數據流與控制流統一，將分散的運維工具備機結合，發揮協力。
引入成熟的運維開發框架，經過PaaS技術實現運維開發人員與底層運維工具的解耦，簡化運維開發的學習成本和開發成本。
持續性工具建設
全面梳理現有運維工具，評估其使用現狀和將來發展性，持續進行優化、整合，將跨系統的功能串聯起來，實現更高階的自動化，甚至實現智能化無人值守。
深化運維工具的應用場景，覆蓋運維到運營的各種場景，實現運維自動化、工具化。
運維開發轉型，建設人才隊伍
爲運維人員提供簡單易用的開發平臺，幫助運維人員瞭解、熟悉、掌握必定的程序開發技巧，實現產品引入到自主開發的逐步轉變。
配套建設完善的運維開發培養及管理的落地方案，爲運維開發轉型積累人才梯隊。
針對上述問題，筆者針對銀行業一般的運維建設現狀和互聯網企業運維現場進行調研後，比對以下：
三、銀行和互聯網企業對比
系統監控
銀行業：工行自研系統監控工具，招行、浦發、華夏使用傳統商業監控產品(面臨功能及服務問題)。
互聯網企業：自研系統監控工具，靈活知足自身需求。
配置管理
銀行業：廣泛存在配置數據準確性、及時性問題，影響配置數據的使用。
互聯網企業：運維技術體系自主研發，運維工具合做密切，配置數據準確性、及時性較好。
運維自動化
銀行業：工行、招行的應用變動自動化比例≥90%，華夏銀行應用變動自動化比例也處於較高水平。
互聯網企業：應用變動自動化比例≥90%，故障自愈比例≥90%，實現了跨系統全流程調度自動化，以及無人值守。
運維大數據
銀行業：工行、招行建成運維大數據平臺，許多銀行還沒有建成運維大數據平臺。
互聯網企業：已建成運維大數據平臺，基於平臺實現從「系統運維」轉向「業務運營」轉型。
運維開發
銀行業：工行、招行等同業正在積極推動運維工具自主研發的路線，並努力推動運維工具與技術的整合，華夏銀行則經過引入騰訊藍鯨平臺來推廣運維開發理念，目前實現小範圍小工具的自研。
互聯網企業：2016年實現基於PaaS的運維一體化，幫助運維團隊成功轉型；並繼續基於平臺低成本、體系化推動DevOps、AIOps，造成「研發運維運營」一體化中臺。
相較互聯網公司，銀行業運維仍然較爲傳統。工行、招行、浦發、華夏等銀行已經開始探索新的運維模式。銀行業亟需順應時代的發展，推動運維的數字化轉型。
銀行運維建設方案調研
一、銀行運維體系
分別對A、B、C三家大型銀行運維體系進行調研，獲得以下信息：
A銀行
基於智能化、PaaS化構建運維開發平臺，承載運維管理的新理念新思路，促進組織的產能升級和人員技能轉型 。利用平臺PaaS化架構，突破常規，構建數字化研運體系，同時打破煙囪壁壘，構築中臺能力池。
B銀行
規劃運維技術藍圖，實現系統運維中心「提產能、促轉型」的整體目標 經過平臺建設實現傳統運維向運維開發轉型；經過API的建設，下降工具使用門檻；運用開發手段，靈活應對複雜應用場景。
C銀行
建設開放平臺，制定產品規範，再提高架構能力，對接流程管控，實現運維工具的自動接管、運營數據分析和挖掘，造成持續改進循環。以非功能管理爲抓手，推進應用運維的持續改進和自動化的改進。
二、銀行運維體系建設宗旨
對比分析三家銀行的建設思路，不難發現銀行運維體系建設的宗旨主要包括：
平臺+應用的構建模式
全面支撐以系統爲視角的全生命週期安全運行管理；
創建一體化研發運營平臺，運用場景輸出模式，對應用功能進行解耦；
提供便捷快速服務組合功能，保留將來的充分擴展性。
功能覆蓋率要求
構建運維、運營於一體的統一管理；
功能設計覆蓋CMDB、監控、自動化、數據分析、AIops場景；
爲將來智能化業務場景預留擴展能力。
技術架構先進性要求
構建一套高可用、高性能安全運行系統；
擯棄傳統單體設計模式，採用業界先進微服務設計模式；
利用分佈式、高可用技術實現平臺高可用、高性能；
採用開放式標準化的平臺接口設計，實現與外圍系統的靈活集成。
藍鯨平臺落地方式對比分析
藍鯨平臺做爲企業IT運維、運營的「大殺器」，獲得了不少銀行的承認，A、B、C三家銀行中，A和B均經過藍鯨自主建設了運維平臺，但建設方式、推廣路線等均有所不一樣。其中，A銀行更多從工具層開始建設，而B更多從平臺層和能力層開始。
A銀行
因爲總行已建設部分運維繫統，考慮充分複用，總行平臺推廣當前僅在運維團隊內部，而分支行因爲缺乏運維管理工具，平臺獲得全面推廣，而且承認度極高。
同時平臺建設從場景層入手，優先建設運維工具，快速填充運維工具缺口，建設速度快，效率高，但工具相對分散，煙囪治理相對不充分，雖立竿見影，但後續持續建設需作相應的攻堅。
B銀行
先進行頂層設計，規劃IT藍圖，基於藍圖，先打基礎，優先建設平臺能力，如配置、監控管理等，夯實平臺基礎，整體建設週期長，初期見效慢，但更利於一體化實現，實現厚積薄發。
藍鯨落地方式建議
藍鯨既能夠做爲開箱即用的運維工具，又能夠做爲承載一切研運能力和場景的平臺，平臺+場景但構建方式，充分保證了建設的靈活性。同時平臺強大的API Gateway可以有效的作到「海納百川」式的集成對接，企業沒必要擔憂因藍鯨的建設實施而推翻已有的運維管理系統，對於「老」、「舊」、「難」銀行能夠經過平臺進行相應的提換，但對於「好」、「新」、「專」類的運維繫統和工具，銀行能夠經過集成的方式實現能力對接，並經過平臺實現一體化運維和管理。
如監控故障管理，可使用藍鯨平臺的監控告警，也能夠與現有的監控工具集成對接。
配置平臺，能夠複用現有的CMDB，但不能徹底替換藍鯨自己的配置平臺，須要進行相關的數據同步和集成。
做業及管控，做爲藍鯨的核心驅動能力模塊，藍鯨經過惟一以1個Agent實現海量節點的運維管理，包括文件分發，數據提取和命令執行，因此做業平臺以及Agent須要使用藍鯨平臺自身功能。
總結
在銀行4.0時代下，平臺化運維運營管理已成爲主流趨勢，藍鯨PaaS平臺以其靈活的建設架構和強大的集成能力，爲銀行IT運維轉型提供源源不斷動力，企業能夠結合自身特性，或基於頂設從能力層逐步建設，或爲補足工具，立竿見影；或大刀闊斧推翻重構，或兼容幷包重複複用現有工具；嘉爲藍鯨解決方案，是銀行IT運維轉型的首選。
做者：李方園
其餘優質文章
-
每一个你不满意的现在，都有一个你没有努力的曾经。