本文主要介紹銀行業務的發展趨勢、應用架構演進以及在此背景下應用運維面臨的挑戰和解決方案。文章目錄如下，是筆者過去5年作爲乙方在多個銀行設計和落地應用運維自動化的經驗分享，共11000字，閱讀時長大約10分鐘。
目錄
銀行業務的發展趨勢
01 互聯網金融的興起
隨着數字化和互聯網技術的發展，用戶在“花”、“存”、“貸”等方面都在發生巨大轉變：
- 花：短短几年，移動支付已經代替了現金支付和刷卡支付。
- 存：大量的用戶資金不斷往互聯網遷移。
- 貸：用戶希望有各種貼合自己使用需求的個性化金融產品。
銀行過去標準化的產品模式已經不適應這個時代的需求，而以BATJ爲代表的互聯網企業，創造了一系列互聯網金融產品，滿足人們日常生活的各種需求，這些，對商業銀行的傳統業務形成了跨界滲透和直接衝擊，甚至具有一定的替代作用。因此，在支付、理財、信貸方面，銀行都面臨着互聯網行業不同場景的挑戰。
02 銀行業務的轉型與發展
著名美國銀行家布萊特•金(BrettKing)在《Bank 2.0 ~ 4.0》中，給出了銀行業務發展的歷程和展望，從網上銀行到智能手機，到物理網點消除，到通過開放實現與其他行業服務的融合形成泛金融服務，到在AI、AR（現實增強）、語音識別等等技術普及於大衆的背景下銀行將業務嵌入到用戶日常生活的體驗升級聚焦。
基於種種挑戰和對未來的展望，數字化轉型以及加速轉型成爲銀行業務的重要發展策略。
政府舉措方面，2015年7月，人民銀行等十部門發佈《關於促進互聯網金融健康發展的指導意見》，該指導意見按照“鼓勵創新、防範風險、趨利避害、健康發展”的總體要求，提出了一系列鼓勵創新、支持互聯網金融穩步發展的政策措施，積極鼓勵互聯網金融平臺、產品和服務創新，鼓勵從業機構相互合作，拓寬從業機構融資渠道，推動信用基礎設施建設和配套服務體系建設。
2018年10月，中國銀行保險監督管理委員會發布《中國普惠金融發展情況報告》摘編版，中國財政也加大了普惠金融發展專項資金的投放。
銀行信息系統的演進
01 互聯網金融的興起
面對業務的轉型與發展，銀行引進分佈式系統在所難免：
- 支持普惠金融服務和複雜交易模式，集中式系統的處理能力瓶頸逐漸凸顯。
- “跨界融合”、移動金融要求銀行業務創新和迭代的節奏要越來越快。
- 銀行要不斷提升用戶體驗，就需要利用先進的大數據技術對海量業務數據進行分析。
- 集中化架構的成本問題越來越突出。
- 各種閉源軟硬件產品逐步不能滿足監管安全可控的要求。
在互聯網企業的系統架構模式的啓發下，很多銀行結合互聯網金融戰略需求，引進開源軟件和技術，開始構建基於x86平臺、分佈式計算的分佈式IT技術體系。
當然，在當前業務現狀下，“集中+分佈式”的融合架構仍然是大型商業銀行的最佳架構選擇：
因此，銀行保留面向“穩態”的、基於集中式的傳統核心，注重安全、穩定，如存款一類賬戶、借記卡、傳統貸款、支付等業務，新建面向“敏態”的、基於分佈式互聯網核心，支撐海量客戶、高併發，適合管理二三類賬戶、直銷銀行等業務。
02 銀行信息系統混合式架構
繼分佈式的引進後，銀行也開始了對雲原生技術的探索，銀行的信息系統不可避免的呈現混合式的架構：
而對於銀行IT運維來說，不同架構的業務系統，對運維的能力和側重點要求並不同，運維的要求、難度和壓力也在不斷的增大。
03 銀行數據中心“雙活”或“多活”的逐步完善
《中國金融業信息技術“十三五”發展規劃》指出，金融機構主動探索系統架構完善升級，繼續深入研究數據中心“雙活”或“多活”模式應用。
截至目前，大多數銀行已經完成了“兩地三中心”的建設，並且定期進行災備演練工作，銀行系統的可用性得到進一步提升。
銀行應用運維面臨的挑戰
01 銀行應用運維的組織與職責
銀行的IT組織很大，部分銀行還成立了單獨的金融科技公司。本文主要聚焦於銀行IT運維組織中的應用運維，分析應用運維如何提升自己的運維水平和方式以適應業務轉型、信息系統架構異構化的發展要求。
應用運維的核心職責在於確保應用系統高效穩定運行，同時響應研發、業務人員訴求完成版本變更或上線的業務價值交付，並提供相關的數據和服務給到業務、運營和測試等外部人員。應用運維團隊的日常職責及與其他團隊的工作交互簡要如下：
02 銀行應用運維的面臨的挑戰
由上可見，應用運維團隊肩負着業務系統正常運轉的重大責任，也同時負擔着一系列繁雜瑣碎的運維工作。隨着銀行業務的飛速發展，應用運維團隊面臨的挑戰越來越大：
- 運維難度增加：技術棧複雜，運維技能要求高。從單體、SOA到分佈式到雲原生架構，從閉源到開源，組成應用系統的技術組件成倍增長，應用運維需要持續增加強化自己的技術能力才能滿足運維的基本要求。
- 運維工作增多：線下業務不斷線上化，應用數量也在成倍增長。
- 運維效率要求提升：業務發展也帶來了大量的更新發布需求，而發佈時間窗口並沒有延長。部分新業務也對運維提出了持續交付的實時性要求。
- 成本控制越來越嚴格：不斷增加的應用系統佔用了大量的IT資源，運維需要通過先進有效的監控和分析手段在性能和成本之間取得一個平衡，並且主動持續優化應用系統性能。
- 運維質量及安全級別要求高：在運維工作複雜度和負擔不斷增加的情況下，運維如何保持既有運維質量、保障和提升系統可用率，成爲應用運維的難題。
運維工作如此繁重，運維人員在橫向擴展自己運維技能的同時，還有時間往運維開發、大數據或AI等縱向技術領域轉型嗎？
另外，應用運維掌握了應用系統的配置、日誌、監控等數據，能否效仿一些互聯網企業，通過有效的技術手段將這些數據進行統一採集分析，爲業務/運營帶來增值服務，做到主動運營，從而提升應用運維組織的價值？
03 挑戰與機遇
銀行應用運維的轉型和運維能力提升已經迫在眉睫，但挑戰同時也是機遇，業務發展和應用架構演進賦予應用運維的責任越大，應用運維所能創造的價值也就越高，也就越發得到重視。
銀行應用運維平臺設計建議
01 如何定義應用？
應用，一般可以從兩個維度進行解讀，一個是狹義的應用，指的是應用程序，也就是由開發人員提供的二進制文件的運行時狀態；另一個是廣義的應用，指的是應用系統，也就是由一組應用程序和系統資源的有機組合。這裏的系統資源泛指支撐應用運行的數據庫、os、中間件、負載均衡甚至域名、存儲等等。
應用運維，指的是對應用系統的運維，既包含對應用程序的發佈、變更等運維工作，也包含對應用系統整體的健康巡檢、監控等運維工作。
02 做好銀行應用運維的建議
- 效率提升：建設應用運維自動化系統，將所有能自動處理的工作全部自動化掉，如發佈、巡檢、變更、啓停、數據查詢與提取、銀行跑批統一調度等等。徹底消滅重複性人工操作，釋放運維人員。
- 質量提升：面向穩態和敏態業務，以應用爲中心建設CMDB，從多個維度完成對應用系統的監控，及時發現應用系統的問題和隱患，並基於自動化手段快速處理問題，提升應用系統可用性。另外，自動化推廣的同時也會帶來操作規範的梳理和標準化，如發佈流程流程標準化、災備切換流程標準化，從而減少人工操作失誤。
- 成本控制：建設容量分析與管理系統，爲系統性能優化提供指導，提升資源使用率，控制資源成本。
- 組織轉型：以上目標的實現，不太可能通過一次性外採一個功能齊全、場景完美契合的應用運維平臺就能解決，是需要企業運維人員也持續投入到平臺上的新場景研發來滿足個性化或增長性的運維需求。在組織轉型這一塊，可以參考Google SRE組織架構，讓運維團隊中50%的人員從事着運維工具的開發。
- 智能化：基於智能化技術，實現容量預測和智能擴縮容從而應對在互聯網化和跨界融合背景下流量峯值的挑戰，實現對故障定位、故障預測以快速解決或避免業務異常或故障，提升用戶體驗。
- 從應用上線開始，自動化技術應覆蓋應用運維整個生命週期。
綜上，要做好銀行應用運維工作，需要建設一個支持雙態架構的、可擴展的、先進的、能促進組織轉型而自增長的應用自動化運維平臺。
03 銀行應用運維平臺設計建議
基於以上分析，應用運維平臺功能架構推薦如下：
服務層能力
服務層能力——效能：
- CMDB：以應用爲中心建設CMDB，應用拓撲遵照服務樹拓撲進行設計，並關聯應用系統相關的各種系統資源，使CMDB能夠服務於應用運維各種消費場景。
- 應用配置管理：基於CMDB，提供製品庫管理、配置文件管理、進程管理、環境管理等功能。
- 應用發佈：與應用配置管理集成，對應用模塊進行包、配置文件、sql文件的快速發佈或回滾，支持滾動發佈、藍綠髮布、灰度發佈等方式。同時支持在一個發佈時間窗口下的多應用發佈任務的複雜編排。
- 資源交付：與虛擬化平臺或雲平臺集成，根據應用資源配置要求自動完成各種組件資源的自動交付和軟件配置。
- 一鍵擴容：基於資源交付和應用發佈提供的能力，還可以做到對應用的一鍵擴容。
- 應用啓停：管理應用相關的所有進程，可在控制檯上進行快速進程啓停，也提供自定義的編排能力以完成對一個複雜應用的一鍵啓停。另外，也對進程異常進行監控告警。
- 銀行跑批：提供一個功能強大的、可擴展的工作流調度引擎，結合底層成熟的分佈式作業執行架構，管理銀行的大量跑批作業，提供對作業、作業流、調度任務的編排、執行、控制與監控等管理能力。
服務層能力——穩定性&可用性：
- 應用巡檢：應用系統是由一組應用程序和系統資源組成的，這些組成部件的健康性會影響着整個應用系統的健康性。基於CMDB中維護的完整應用系統信息，結合原子化的、可擴展的巡檢框架，我們可以以應用維度對整個應用系統進行健康性巡檢，從而發現應用運行的隱患或問題。
- 應用健康度監控：應用健康度監控提供了一個框架，對接企業的監控系統或告警系統，從應用維度對組成應用系統的應用程序和系統資源的監控和告警信息進行實時彙總，並以服務樹拓撲或應用邏輯拓撲的形式展現出來，以便於應用運維人員進行快速故障定位和應用異常發現。
- 應用撥測：可建立撥測任務對應用的網站、接口進行撥測監控。
- 智能業務巡檢：模擬用戶對應用功能的完整使用，從用戶端角度確認應用功能的順暢使用。由於傳統的運維通道能力（文件傳輸、命令執行、數據採集、API調用、協議驅動）未必能支持一些C端操作自動化，在這裏我們應用了rpa技術（集成selinium腳本、Windows窗口句柄識別、OCR）來適配用戶的各種ui操作場景。
- 日誌檢索：對應用系統的各種類型日誌進行統一採集、清洗、存儲、告警、分析和展示。
- 災備演練：提供靈活的災備切換和恢復流程編排框架和可擴展的原子化能力，支持多應用多步驟的一鍵切換和大屏跟蹤展示，並且對災備切換的預案進行管理，以自動化和規範化保障銀行定期災備切換活動的成功進行。
- APM：基於字節碼注入技術自動發現應用拓撲關係、應用代碼級運行性能、接口性能及調用鏈分析，基於js注入獲取和分析每個用戶對應用業務功能的使用體驗。從而對應用進行更深層次的監控和更有效的故障定位。
服務層能力——效能：
- 容量管理：對應用的資源指標、服務指標、業務指標進行統一採集存儲，並基於多關聯算法分析業務波動或吞吐量變化時對系統資源的影響，從而評估應用的容量狀況，爲性能優化、成本控制提供切實有效的指導。
服務層能力——效能：
- 故障自愈：基於自動化編排引擎，對接告警系統，實現常用的故障自動化處理，包括日誌清理、服務重啓、參數調整等操作編排。
- 故障定位：基於應用的服務調用信息、資源關聯信息，對應用系統各個時間段的告警事件進行分析，從而提供故障定位能力。
服務層能力——流程/工具
- 運維流程管理：一款面向IT人員的運維流程管理軟件，提供IT運維的請求管理、事件管理、發佈和變更管理、日常運維管理等核心模塊。使得IT運維工作更加規範和敏捷，從而提升運維的協作效率和工作質量。
- 報表可視化：報表可視化是面向運維人員的輕量的web報表製作工具，核心功能有儀表盤和報表兩大模塊，實現企業IT運維各項數據的實時呈現和分析。例如，基於報表可視化我們可以靈活構建銀行應用運維的監控儀表盤，嵌入到應用監控、APM等運維工具中。
- 大屏可視化：大屏可視化，主要應用於大屏幕投放。提供大屏可視化設計器，便於無編碼的方式快速拖拽、配置來形成前端大屏。例如，基於大屏可視化及應用健康度監控，可以構建應用牆大屏，實時展示所有應用運行狀態。
平臺層能力
- 平臺層提供服務層所需的公共模塊能力，例如CMDB、Agent、作業執行等；應用自動化工具鏈，提供滿足企業應用自動化運維生命週期的工具鏈，並基於平臺整體能力實現融合。
- iPaaS層： API GateWay（統一接入模塊），將配置管理（CMDB）平臺、作業平臺、數據平臺、挖掘平臺等原子平臺統一接入、集成、驅動和調度，供上層運維場景APP驅動和調用。
- aPaaS開發者中心（提供前後端開發框架）：開發者中心提供完整的前後端開發框架，當企業在未來出現新的運維需求的時候，企業可以快速利用開發者中心完成相應的運維繫統開發，支持一鍵部署和持續部署。
- 管控接入：提供分佈式、高可用、可擴展的通道能力：文件傳輸、命令執行、數據採集、通用協議驅動、API調用、RPA等。
銀行應用運維平臺關鍵能力建設建議
以下對嘉爲藍鯨應用運維平臺上的部分關鍵產品設計理念與功能進行一一介紹：
01 應用配置管理
面向應用運維的、以CMDB爲基礎的應用配置管理是應用運維的基石和前提，它的設計和建設決定了能否同時支持多種架構的應用的配置管理及自動化運維。簡單來講，應用配置管理需要包含以下幾個重要功能或重要原則：
以應用爲中心的CMDB
CMDB的建設需要着眼於應用，而不是以資源對象、數據中心來進行劃分。比如CMDB中的第一層級，應該是OA系統、電子商城、ERP系統等應用，而不是Windows服務器、數據庫主機或者北京數據中心、廣州數據中心。
應用拓撲應該以服務樹拓撲（或稱爲業務層次拓撲）
服務樹拓撲主要是指從縱向的角度進行模塊化劃分，並把相同功能的模塊劃分到一個子系統中，服務樹拓撲一般不要超過3層，最末端對應具體的應用模塊，模塊之下再是主機：
例如：
服務樹拓撲中關於環境和集羣的插入
- 環境概念：指生產環境、測試環境、災備環境等。
- 集羣概念：適用於分佈式系統，一般以地域劃分，如廣東集羣、北京集羣。廣東集羣提供給華南用戶優先訪問，並且在北京集羣出現故障時可以在服務樹拓撲中按需插入環境和集羣節點形成新的服務樹拓撲。
例如：
以服務樹拓撲，做好IT資源的關聯
服務樹末端爲應用模塊或資源組件，是作爲與實際IT資源實例發生關聯的節點：
編輯
CMDB中可自定義IT資源對象模型及添加實例
提供程序包管理功能
應用配置管理需要面向應用運維，首當其衝就是應用發佈。因此對於運維來說，需要把用於發佈的程序包的所有版本及其與應用模塊、部署主機的關係管理起來：
實際功能效果：程序包統一管理
多版本文件管理、上傳與自動分揀等功能
應用模塊關聯：
提供配置文件管理功能
配置文件統一管理、變更和發佈也是應用運維的重點工作之一。配置文件也需要與應用模塊進行關聯：
配置文件管理：
配置文件的版本管理、在線編輯、基於可自定義mako語法的變量管理等功能：
配置文件與應用模塊的關聯：
進程管理
針對應用模塊下的進程進行管理。進程管理在進行設計時，需要考慮到一些傳統的架構，一個模塊下的不同主機可能運行着不同的進程（或是進程不同，或是端口不同，或是啓動命令不同），但大家使用的程序包是一樣的。
進程管理主要用於一些較舊的單模塊多進程的傳統應用的發佈場景、應用啓停場景和監控場景。
其他
基於銀行分佈式和集中式架構並存的考慮，服務樹拓撲最末端可以是應用模塊，也可以是資源組件模塊，如數據庫、消息隊列等。
以上的各種資源對象模型、拓撲節點模型、包/配置文件/進程模型等均可自定義參數模型，以便於適應不同企業的應用配置管理需求。
02 應用發佈自動化
應用發佈需要基於CMDB和應用配置管理之上進行構建，將應用的各種對象資源及發佈對象管理起來後，自動化發佈就成爲一個簡單的事情了，我們可以選擇任何一個模塊按照一定的策略（並行、滾動、分批等）進行快速的發佈：
關於發佈的編排，分爲技術維度的編排和業務維度的編排。
技術維度，就是具體的一臺主機需要執行的具體步驟編排：
在上圖中，我們可以編排一個通用的發佈流程，將參數剝離出來，在應用配置管理中統一管理，這樣，不同的應用模塊就可以使用相同的執行流程進行發佈，僅需從應用配置管理中傳入應用相關的參數即可。
業務維度，是指應用模塊之間的發佈順序編排：
銀行在有限的發佈窗口中進行應用發佈時，有時會涉及到對大型應用進行批量發佈，此時應用模塊之間的發佈順序是需要嚴格定義的，包含每批應用發佈的時間設定等，此時就需要提供應用間、應用內主機間的串並行發佈順序編排能力。
在發佈過程中，我們需要實時掌握髮布任務的執行詳情，並且可以對發佈任務進行干預，如暫停、恢復、忽略、繼續、停止等。
關於發佈，可以在此基礎上繼續擴展其他的能力，如sql發佈、配置文件發佈、與工單對接、快速回滾、發佈審計、權限控制、配置回寫等等。
03 應用災備演練
在過往10年，大多數銀行致力於“兩地三中心”的災備建設，到目前，基本都已經實現了核心系統的災備建設。災備建設的根本目的在於出現不可預知災難時的應急切換，以快速恢復業務。
存儲複製技術是銀行災備建設中常用的架構，以下是基於vplex和VMware HA集羣的一種災備架構設計（所有的虛擬機及數據文件均通過存儲複製技術複製到災備機房）：
當然，有些銀行還會配合其他的技術來支撐災備架構，如基於Oracle 的Dataguard/RAC技術、基於應用層面的高可用技術等等。
災備切換一般涉及到多套應用系統、多個複雜步驟、多個業務部門，並且時間緊、質量要求高，銀行能否順利完成災備切換，不僅取決於災備系統的建設，也還取決於災備演練是否充分，災備切換步驟是否準確到位。
因此，一個好的災備演練平臺成爲銀行災備系統建設完畢之後的迫切需求。一般來講，災備演練平臺需要具備以下功能特性：
- 靈活、方便的編排能力，適用於各種災備架構。
- 強大的通道能力，能夠驅動的各種IT資源對象完成相關操作。
- 具有較好的可視化能力，能夠清晰、實時的展示各業務的災備切換過程和狀態。
- 良好的擴展性，支持與監控、應用配置管理、測試等外部運維繫統對接。
- 良好的性能，能支持整個數據中心級別災備切換時的併發作業。
災備演練平臺架構設計如下：
案例分享：贛州銀行增強科技創新，實現一鍵災備切換
04 銀行跑批
什麼是銀行跑批
銀行跑批就是產生總賬，進行總分覈對，再者就是進行大批量的非實時的交易。
銀行跑批的時間
大部分批處理在晚上完成，但白天也有批量。
銀行跑批的核心功能
進行會計覈算
銀行跑批的存在形式
一個個分佈在不同服務器上的有各種依賴關係的作業。
跑批過程詳細說明
銀行業務結算不是所有的銀行數據都是實時操作的，所有的帳都是即時入帳的，即使實時操作，後臺會計部門也需要報表數據,進行對帳清算。因此跑批就是爲此產生。跑批其實就是產生總帳,進行總分覈對，再次就是進行大批量交易，如:結息,計提,代收付等(這一步可以在各分佈平臺做)。
再次就是生成報表,導出流水數據等。批量是相對聯機來說的，並不一定是在晚上，白天也有批量，主要是完成業務處理的。批量的核心功能是進行會計覈算，如總分覈對、試算平衡等，這樣保證全行的帳務沒有偏差。
另外，爲了提高聯機交易的反應時間，一些對帳清算等不需要實時入賬的功能也由批量來完成；類似的，還有一些爲了減少櫃員工作量和減少高峯時期資源爭奪的交易，如待收代付等，也歸入批量完成的功能。一些特殊業務，如記息記提等。還有一塊批量就是爲了統計和管理的需要而出的一些報表。
銀行跑批系統，一般也稱爲ETL調度系統。
大部分銀行已經有了跑批作業管理系統，那麼爲什麼還要繼續建設？
交易的不斷增長引發巨大的數據吞吐，跑批的作業量不斷增加，核心跑批可用的時間窗口不斷受到壓縮，跑批作業的流程日益複雜，作業與作業、作業流與作業、作業流與作業流之間存在複雜的依賴關係。
業務種類不斷創新，跑批作業之間的關係也處於變化之中，涉及的系統越來越多，急切需要集中、靈活、可擴展的調度系統。
技術架構日益複雜，後臺系統有AIX、Linux、Windows、中標等各種系統平臺，主備、分佈式等多樣化的集羣也增加了銀行跑批作業管理的複雜性。
過去主要由國外產品提供跑批作業管理，國外產品逐步不滿足安全可控、國產化以及靈活擴展等要求，因此銀行需要建設更爲先進的跑批作業管理系統。
跑批作業管理系統架構設計如下：
在作業編排與作業控制方面，跑批需要滿足以下核心要求：
在作業執行架構上，跑批需要滿足高可用分佈式的要求，以支撐海量併發的跑批作業：
主要產品功能
作業流編排：
作業日曆調度：
作業控制：
作業跟蹤監控：
05 應用巡檢
應用系統是由一組應用程序和系統資源組成。當用戶訪問應用系統發生問題時，可能是應用程序運行的問題導致，也可能是相關的資源對象（如數據庫）出現問題導致。當一個應用系統越來越龐大和複雜時，確保系統中各應用程序和系統資源對象處於健康狀態是應用系統正常運行的重要前提。
對一個應用系統進行全方位巡檢，類似於醫院中的專家會診場景。應用系統的每個技術棧（資源對象類別）都會需要相應的巡檢腳本/方法支持，對應醫院的專科專家。
當對應用系統的所有資源類別都有了相應的巡檢方法，我們也從CMDB中獲取到一個應用的所有資源實例，那麼我們就可以以應用維度對應用系統進行快速整體巡檢和健康度評估。巡檢工具架構設計如下：
- 應用管理：主要對接CMDB獲取應用系統的各種資源實例。
- 指標庫：一個可擴展的框架，可針對每種資源對象定義相關的巡檢方法，包括基於腳本的巡檢，也可調用第三方運維繫統進行健康數據獲取（通用編寫python適配器）。
- 任務管理：定義巡檢哪些應用，巡檢時間等
- 報告管理：以應用角度展示巡檢結果。
巡檢示例報告如下：
巡檢錯誤概覽如下：
06 智能業務巡檢
應用巡檢是從應用內部進行巡檢，但還無法直接反饋用戶的真實使用情況。針對重要的業務系統，從特定辦公地點模擬用戶發起對該業務系統的訪問並且驗證該系統業務功能，我們稱之爲業務巡檢。
爲滿足更多的用戶模擬場景，可以採用業界流行的rpa技術。只要是用戶在電腦終端上的所有鍵鼠操作，rpa均能實現將操作流程自動化。
基於rpa的智能業務巡檢架構設計如下：
相關概念如下：
- D-bot：用於執行RPA流程的Agent
- D-Console：用於RPA流程編排和管理
- 智能業務巡檢APP：用於統一的任務管理和報告展示、告警通知等
關於智能業務巡檢的主要業務流程如下：
在D-Console上進行RPA流程編排：
流程編排實際效果：
通過智能業務巡檢，我們可以在一次任務中從多個撥測點對多個業務的多個功能進行用戶模擬訪問測試，並分析訪問的成功率和延遲，生成報告詳情發送給到相關運維人員。
07 應用健康度監控
隨着監控技術的不斷應用，企業開始逐步建立立體化監控平臺，所謂立體化監控平臺，是指從多個維度對不同層級（一般從上到下劃分爲用戶層，業務層，應用層，組件層，主機、硬件與網絡層）的監控對象進行指標採集、統一存儲和監控告警。立體化監控覆蓋的對象範圍如下：
應用健康度監控，出發點和技術實現方式與應用巡檢類似，基於立體化監控平臺之上構建的一個對應用系統的各個資源對象實例的健康狀態進行監控的上層應用，應用健康度監控的用戶故事，主要有以下幾個：
- 作爲應用運維人員，我想從應用系統維度對應用系統進行全方位的監控，並以拓撲的形式展現出來，以便於在接收到用戶報障之後，能夠快速的定位到應用系統具體哪個組件存在異常，爲解決報障提供指導。
- 作爲應用運維人員，我想把關鍵應用的關鍵健康度指標都監控、匯合展示出來，以便於我及時發現應用運行過程中的異常。
- 作爲應用運維領導，我想隨時可獲取所有應用的整體健康狀態，以便於感知我們當前應用運維的水平和運維目標達成情況
應用健康度監控的功能架構設計如下：
主要功能介紹：
- 應用運行拓撲展示（服務樹拓撲、邏輯拓撲）。拓撲自動生成、應用資源對象實例會自動填充到各拓撲節點上。
- 可自定義監控儀表盤，通過拖拽各種圖表控件生成儀表盤，控件可接入外部數據源。
- 告警查詢，以應用維度展示告警動態。支持多種查詢。
- 應用牆，根據資源實例信息生成應用牆，如下圖：
08 APM
APM是應用運維體系中必不可少的能力。嘉爲藍鯨APM解決方案共有五大能力：
- Server監控：以字節碼注入爲核心技術，通過應用服務器上的Agent實現應用拓撲自動生成、實現服務間的調用鏈監控、實現服務內方法級的調用鏈監控。
- 瀏覽器監控：用戶通過瀏覽器訪問應用時，會自動下發js探針到真實用戶瀏覽器上，從而獲取用戶對應用的各種訪問行爲和效率，形成對真實瀏覽器用戶的使用體驗監控。
- Mobile SDK監控：在APP開發中嵌入SDK，手機用戶使用APP時，SDK獲取用戶對應用的各種訪問行爲和效率，形成對真實手機用戶的使用體驗監控。
- 互聯網瀏覽器用戶模擬訪問：主要面向互聯網應用，利用全球十萬級以上瀏覽器撥測點實現。
- 互聯網手機用戶模擬訪問：主要面向互聯網應用，利用全球十萬級以上手機撥測點實現。
APM系統架構設計如下：
09 應用啓停
應用啓停是一個小工具，主要提供以下功能：
- 進程定義
- 進程管理。快速啓停
- 進程監控。異常停止時發出告警
- 應用一鍵啓停。對應用各模塊、各主機進程的啓停提供編排能力，實現應用的一鍵啓停
10 應用自動化運維關鍵能力一覽
11 其他
本文先聚焦於銀行應用運維的關鍵場景和相應產品能力。文中提及的嘉爲藍鯨資源交付、藍鯨立體化監控平臺、告警中心、日誌檢索、報表可視化、大屏可視化、容量管理、故障自愈等產品後續再進行詳細介紹。
銀行應用運維的展望
銀行業務正處於飛速發展和變革的階段，支持業務系統的信息技術也在發生翻天覆地的變化，傳統運維方式已完全無法應付業務和技術變革帶來的挑戰，銀行應用運維只有與時俱進，不斷吸收國內外頂級互聯網企業的先進運維理念與技術，實現組織轉型，運維不再侷限於運維，運維要投入到構建動態發展的、契合銀行業務發展需求應用運維平臺中來，向自動化、數據化、智能化穩步邁進，才能最終實現應用運維組織效能與價值。
出品：嘉爲科技