踐行深度用云主機上云運維現代化核心能力編制委員會主

編

單

位

華為云計算技術有限公司編

委

顧

問

尚海峰胡玉海編

審

組

成

員

支新輝貢徐青俊劉征輝林麗鑫王飛主

編

人

員

郭曉征耿麗麗馬曉明毛明強張志炯王進行石松參

編

人

員

黃征彬熊洪槐張聞毅濤馬韜錢石姚張沛沛博凱秦丹濤張瀚文張胡劉王江堃杰瑞王珂李松李晉彭永紅程紫東張任遠田應軍席彬王樂曉關建峰趙靜敏責

任

編

輯（排名不分先后）序言尚海峰華為主機上云軍團CEO、混合云總裁過去三四十年，金融核心系統主要采用集中式主機架構進行建設。隨著金融業務數字化轉型需求的不斷深化，云計算技術的持續演進，金融機構普遍采用了云原生相關技術進行業務改造，更有不少頭部大行作為先行者，率先將主機承載的核心系統業務也遷移上云，加速了金融行業數智化、自主創新進程。目前，大部分國有銀行和股份制銀行已經完成了從一般類業務上云到核心類業務上云改造的試點工作，進入到核心業務批量上云改造階段。柜面系統、網銀系統、信貸系統、投資理財系統、信用卡系統等核心交易系統陸續遷移到云上，使得金融云平臺承載的業務規模不斷擴大，重要性不斷攀升。隨之而來的是，業務對持續高可用的要求更加苛刻，尤其是核心業務上云后，任何業務中斷都會引發重大的影響。金融對公眾開放的核心業務一旦中斷會造成嚴重的社會影響甚至引發信用危機。除業務中斷外，業務的劣化，如卡頓、報錯等，也會造成最終用戶的不滿和投訴。這就對承載核心業務的云平臺提出了更高的穩定性、可靠性要求。除了穩定的產品外，強大的運維體系是保障云平臺穩定性最直接、最有效的手段。在主機核心業務逐步上云后，如何加強運維全鏈路監控能力，快速定位、定界和解決問題，如何變被動運維為主動故障預防從而大幅減少潛在故障與運維投入，如何將應用運維與平臺運維進行有效協同從而保障系統性業務高可靠高可用，如何應對平臺運維安全與租戶安全帶來的雙重挑戰等問題，成為了擺在金融運維人面前的關鍵挑戰。華為云基于自身云平臺運維經驗，以及服務上百家金融客戶數字化轉型的實踐，持續積累主機上云場景的運維核心能力，并沉淀了一套全面構建穩定可靠的現代化運維能力的路徑和方法，期望助力金融企業加快實現主機業務的全面云化。目錄105-08主機上云帶來的運維新挑戰21.1挑戰1：如何基于應用視角設計高可用上云方案與高可靠運維保障方案1.2挑戰2：云平臺技術?？焖僭龊?，如何有效進行全鏈路可視監控1.3挑戰3：云網深度融合，如何快速發現、定位、恢復問題1.4挑戰4：如何應對運維安全與租戶安全的雙重挑戰09-43主機上云運維現代化核心能力2.1平臺運維現代化2.1.1全鏈路運維監控構建從應用到云平臺的全棧感知能力2.1.2基于故障模式庫和云網一體化運維實現確定性故障恢復2.1.3基于一體化風險庫和混沌工程進行預見性風險治理2.2應用運維現代化2.2.1運維規劃前置到設計階段，業務可靠性來源于運維與設計的融合2.2.2借助運維數倉構建應用可用性監控管理體系，實現業務故障實時感知定界2.2.3面向故障全生命周期，全方位提升故障感知、診斷、恢復智能化水平32.3安全運維現代化2.3.1全視角運維安全體系設計構筑金融云運維安全堤壩2.3.2體系化、智能化安全運營為云上業務保駕護航44結語主機上云帶來的運維新挑戰挑戰1：如何基于應用視角設計高可用上云方案與高可靠運維保障方案據庫、中間件、AI、大模型等各種云原生技術被廣泛應用。新服務、新技術的迭代加速，猶如一柄雙刃劍，在助力業務快速發展、快速創新的同時，也帶來了系統技術棧復雜度的急劇提升，給傳統的IT運維方式帶來巨大沖擊。主機上云的最大挑戰就是核心應用上云后的可用性管理。隨著原來運行在大機上的應用不斷遷移上云，云上的業務可用性等級要求被提升到了新的高度，傳統的運維手段已經無法滿足核心業務N個9的可用性目標。可用性管理前置到了系統設計乃至應用設計階段。例如，應用的微服務化改造，帶來微服務數量的指數級增長，應用的調用層次和調用關系變得冗長；分布式云原生的深度應用，使得業務鏈路更加復雜。當上層業務應用出現故障時，排障過程可能涉及從應用到網絡的完整鏈路，這其中包含業務應用、云服務實例、云基礎設施和服務器、網絡、存儲等物理設備。即便如此，可用性管理依然面臨著成本、技術和管理的三重挑戰。首先，無論是備份、主備、多活還是業務單元化改造，所有的高可用的架構設計都需要投入高昂的成本，高可用的效果和技術方案的投入成本成正相關關系。如何平衡高可用的投入與產出就成為IT管理者在高可用管理過程中的重要難題。典型的業務流量路徑如：應用>容器>PaaS實例>虛擬機>服務器>虛擬網絡>物理網絡。在針對這個路徑的運維實際工作中，應用、虛擬機軟件提供方、服務器和網絡設備提供方常常是各管一段，整個業務從上到下的全棧調用路徑往往是個黑盒，導致故障定位定界困難，或者恢復時長無法控制。其次，高可用設計是一系列技術方案的組合，從底層網絡設計、到云服務的有效運用以及高可用技術工具的選型，從業務部署架構的改造到上層業務的單元化改造，每個層次都涉及多種技術的使用與配合。如何讓現有的技術手段以及云服務發揮最大的效能，如何基于先進的單元化設計理念達成核心應用N個9的可靠性也是IT管理者面臨的難題。面對IT系統復雜的技術棧及海量的運維對象，做到軟硬件運維對象的統一管理，指標、告警、日志、調用鏈、拓撲等運維數據的統一匯聚和分析，構建全鏈路故障感知、全棧故障可視的運維體驗，對于金融主機上云過程中的運維工作至關重要。最后，服務SLA（ServiceLevelAgreement,服務水平協議）的達成還需要有相匹配的管理手段與工具，如故障模式庫、演練工具等資源作為支撐，不但要能有效跟蹤度量SLA的實際效果，還需要持續、主動發現可用性風險的機制與工具，在可用性管理的過程中實現數據積累和能力演進。挑戰3：云網深度融合，如何快速發現、定位、恢復問題過去一年，在互聯網領域發生過多起頗為嚴重的宕機事故：2023年3月，某互聯網服務商發生機房故障，多個互聯網核心應用受到影響，事故持續7個小時，影響約十幾億用戶。挑戰2：云平臺技術?？焖僭龊?，如何有效進行全鏈路可視監控2023年11月，某云服務商旗下多款應用出現無法登錄故障，事故持續4個小時，這是該云服務商時隨著主機上云和業務云化轉型的持續深入，分布式數06隔一年之后第二次出現嚴重故障。如何解決云網絡問題在云網絡和物理網絡深度融合的場景下，應用級的網絡可視、云網絡端到端的故障探測是解決云網絡問題的關鍵所在。2023年11月，某互聯網服務公司核心應用業務癱瘓接近12個小時，流失千萬訂單，直接損失上億元，引發了廣泛的社會關注?？偨Y上述這些事故，它們都具備了如下幾個特點：挑戰4：如何應對運維安全與租戶安全的雙重挑戰事故影響范圍巨大，社會反響強烈，更有甚者還會對社會的衣食住行產生嚴重影響。主機上云的過程中，應用與云平臺的運維會同時受到運維安全和租戶安全的雙重挑戰。事故影響時間較長，業務恢復周期以數小時計，嚴重者故障恢復時長達到了12小時。在運維安全方面常見的挑戰包括：造成巨額經濟損失，負責人被處分、問責。運維安全意識不足運維管理者缺乏對運維安全的完整規劃，在制度、流程和技術規范方面缺少對變更的嚴格管控。在缺乏對變更的嚴格審控機制的情況下，隨意的變更為引發后續事故埋下了隱患。隨著上云進程的逐漸深入，金融企業開始將核心應用搬遷上云。核心應用一般有著規模大、分布式、架構復雜等特點，這一點和互聯網業務非常相似，上述互聯網的故障也在時刻給金融核心應用的運維敲響警鐘。在此背景下，近年來金融領域客戶提出了核心業務的“1-5-10”目標，即：1分鐘發現故障、5分鐘定位、10分鐘恢復。要實現這個目標必須要解決以下關鍵問題：運維安全管控的技術手段不足主要表現為，對運維操作入口沒有進行技術管控，缺乏對運維操作過程的有效監管，缺乏對高危操作的攔截，缺乏對運維操作的記錄與審計，缺乏識別惡意操作的評估手段。如何盡可能地少出問題首先，需要有一個完善的運維規范和流程來保障運維流程合規；其次，核心應用需要全局的高可用設計，從架構層面避免單點故障；最后，企業還應具備完善的風險管理體系，可以對識別到的風險舉一反三快速閉環，持續提升核心應用的韌性。權責不匹配運維人員的權限過大或者超越自己的職責范圍，很容易引發超出職責范圍的誤操作，從而帶來不必要的運維風險。在租戶安全方面的挑戰包括：如何快速恢復故障基于核心應用黃金指標的秒級故障感知是故障恢復的前提；基于調用鏈分析、日志解析、云服務實例快速診斷的分鐘級故障定位是故障恢復的基礎；基于應急處理預案的一鍵式故障恢復是行之有效的手段。安全攻擊無法避免希望一勞永逸地解決租戶安全問題是不切實際的。人類的操作永遠無法做到完美，系統和技術總在不斷演進，新的漏洞會不斷出現，完全消除漏洞是不可能的。所以，0日攻擊、釣魚攻擊以及賬戶被破解都無法被避免。07租戶安全防護難以全局統籌理解威脅的本質，以制定有效的處置策略。有時候安全團隊還會面臨技術上的限制，從而需要花費更多時間來研究和實施解決方案。現代企業和組織的網絡環境越發復雜，涉及眾多設備、應用、數據類型。同時安全威脅也在不斷演變，包括網絡攻擊、釣魚、木馬、病毒、社會工程學攻擊等多種形式。安全團隊需要同時跟蹤多種威脅情報，及時調整安全策略和措施，以應對各種各樣的威脅。在實際業務場景中，由于安全管理不善造成重大事故和業務損失的案例并不鮮見，如誤刪數據庫賬戶造成結算業務失效，誤刪虛擬機造成業務中斷，租戶權限管理不當誤刪OBS桶等等。云化、集中化雖然提升了業務的創新速度，也讓運維安全的管控以及租戶安全的治理變得更加復雜，所以運維安全是業務可靠性保障的基石，也是運維現代化的基礎。安全威脅處置緩慢安全威脅普遍具有隱蔽性強的特點，不易被及時發現。現代安全威脅越來越復雜和多樣化，攻擊手段和方式不斷演變，安全團隊需要花費更多時間來分析和主機上云運維現代化核心能力主機上云運維現代化旨在圍繞核心系統云平臺運維、應用運維及安全運維三大領域系統性構建上云后的云運維保障能力，全面支撐金融核心應用通過平遷、改造或核心重構三種方式遷移上云后的穩定可靠運行，助力金融機構平滑穩健地深化數智業務創新，構筑面向自主創新的高質量發展基座。存貸款消費信貸支付結算中間業務現金管理理財管理資金交易主動預防運行穩定安全可靠1.平臺運維現代化2.應用運維現代化3.安全運維現代化全鏈路確定性預見性高可用智能化全視角體系化運維監控故障恢復風險治理架構設計應用運維運維安全安全運營全鏈路可觀測面向應用運維極簡信息匯聚云網定位定界故障精準診斷一鍵故障恢復主動風險預防變更風控管控混沌工程演練高可用SLA規劃應用高可用設計持續高可用治理運維數據治理可用性指標構建運維故障分析用戶授權可控制作業過程可信賴潛在風險可識別立體防御體系主動智能安全全面安全運營主機上云新基座應用平遷上云應用改造上云核心重構圖2.1運維現代化三大核心能力平臺運維現代化平臺運維的現代化轉型重點要考慮如下三方面的能力建設：華為云給出了通過全鏈路檢測、故障模式庫和云網結合快速定界故障的思路，以此提升核心應用上云后云平臺故障恢復的確定性。全鏈路運維監控核心業務上云的過程中，云與應用的耦合度逐步提高，應用與云平臺的關系愈加復雜，因而云運維必須實現應用到云平臺乃至物理設備的全鏈路覆蓋。同時需要梳理出應用與云平臺間的依賴關系，當應用出現故障的時候能夠基于應用的視角快速感知和診斷故障。預見性風險治理實現風險的提前感知與預防始終是運維管理者長期的期望，也是運維人員一直面臨的難題。這個問題同樣擺在華為面前。在十多年運維工作中，華為云通過大量項目實踐摸索出了一套預見性風險治理的思路，不但覆蓋了運行時的風險治理，也覆蓋了對變更的風險治理方法，以及對未知風險的識別與預防手段，本文將詳細闡釋通過數字化到自動化的轉換實現云平臺風險預見性治理的思考。確定性故障恢復快速創新的金融業務場景增加了云平臺技術棧復雜度，也因此提升了故障定界、故障快速恢復的難度。10應用運維現代化當前，越來越多金融云運維管理者的關注點從以云與設備為核心的運維轉向以應用為核心的運維，尤其是核心應用的運維受到格外的重視。在應用運維領域，存在多種多樣的工具與技術，然而工具之間數據割裂無法形成全局視野，因而會直接影響應用運維的效率與效果。只有打破各個工具間的數據孤島才能統籌洞察應用的完整運行態勢，對應用進行全方位的監控與分析。在本文中，華為云提出要將應用的可靠性保障前置到設計階段，通過高可用設計提升應用的可靠性，同時也給出了應用高可用設計的思路，幫助金融企業選擇合適的高可用方案平衡成本與效益的矛盾。安全運維現代化運維安全是保障業務可靠性的基石，也是運維現代化的基礎。在運維安全領域需要通過對運維過程無死角的安全管控來保障運維安全，具體來說，需要實現事前對權限的有效規劃和管理，事中對運維操作的嚴格管控，以及事后對運維操作的審計與分析，減少由于運維誤操作給云業務帶來的風險。除了云平臺本身的安全保障，在租戶安全維度，也應構建完整的安全防護體系，端到端保障云租戶的安全。2.1平臺運維現代化核心能力2.1.1全鏈路監控構建從應用到云平臺的全棧感知能力應用層通過在容器集群、彈性云服務器、裸金屬服務器上部署復雜的應用，實現某些業務功能；從應用視角到平臺視角，構建全面的指標體系，快速感知故障PaaS實例層主要是指云平臺提供的容器集群、中間件、數據庫等實例資源；核心應用部署上云，從上到下可以分為四層，分別為終端層、應用層、PaaS實例層和IaaS基礎設施層。如下圖：IaaS基礎設施層主要指提供計算、存儲、網絡的基礎資源池，如云數據中心的存儲池、虛擬網元、計算資源池或者傳統數據中心的服務器、網絡設備、存儲設備等。終端層嚴格意義上并不在云上部署，主要部署在端側，通過APP或者瀏覽器實現應用訪問；簡單應用訪問流程示例微服務架構復雜應用訪問流程示例終端層訂單處理120ms102msuser-mgrMySQL102msELB應用層102msapi-gw200mscache-mgrAPPSAPPSAPPSAPPAPPAPP102ms102msRabbitMQRedisproduct-mgr數據庫實例層緩存容器節點云硬盤云主機宿主機緩存云主機云硬盤容器節點數據庫層宿主機網元存儲池宿主機網元存儲池宿主機物理主機網元存儲池云數據中心1云數據中心2傳統數據中心如上圖所示，針對簡單應用（綠色線條），可以直接以應用云上部署架構來構建全鏈路監控；針對微服務架構的復雜應用（紅色線條），需要借助APM工具解析微服務間交互流程來構建全鏈路監控。圖2.2典型云上應用部署模型12構建核心應用可觀測體系，需要根據應用部署層級分別進行設計：端，對應用進行周期性撥測，快速感知邊緣網絡故障。終端可觀測終端層常見指標舉例：終端層需重點關注用戶的使用體驗，采集終端應用運行報告、訪問成功率、接口延時等體驗類指標，通過終端內置的軟件工具包(SDK)上報到應用可觀測平臺。必要時需要部署一定數量的云撥測終a.APP體驗指標：如下載成功率、安裝成功率、用戶搜索耗時、用戶下載速率等表征最終用戶體驗的指標b.API性能指標：調用成功率、調用量、時延等App/ServerKitAccountkitAudiokit…邊緣網絡c.邊緣網絡性能指標：丟包率、延時、帶寬、流量消耗等Internet/骨干網&CDN應用可觀測APP體驗指標API性能指標邊緣網絡指標應用層需要根據應用的核心功能，構建表征功能健康度的黃金指標。不同應用功能存在差異，梳理出的指標不盡相同，指標越能精細表征健康度，越能快速感知故障，反之亦然。下載成功率安裝成功率首頁打開耗時首頁圖片耗時用戶搜索耗時應用詳情耗時用戶下載速率…API時延調用量成功率…帶寬流量速率CDN…以某互聯網視頻應用為例，需要基于應用接口日志定義接口請求量、接口成功率、接口時延、播放卡頓率等指標，針對指標數據進行治理，最終呈現不同時間維度的視圖，同時支持針對流量的趨勢進行動態閾值調整，準確產生指標告警。圖2.3典型終端指標設計流程維度：APP版本、視頻分類度量：請求結果標識、時延視頻登錄請求成功次數/視頻登錄請求次數視頻登錄請求成功次數視頻登錄請求次數視頻登錄請求成功率長視頻登錄請求成功率邏輯主體基礎指標派生指標指標疊加公式組合指標派生組合指標APP版本視頻請求分類結果......時延視頻登錄請求次數視頻登錄請求成功次數視頻登錄請求成功率長視頻登錄請求成功率1.0.11.0.21.0.11.0.3長視頻成功短視頻成功短視頻成功長視頻失敗30503540X（次）X（次）XX（%）XX（%）圖2.4指標設計流程示例13應用指標定義完成之后，還需要構建應用全鏈路拓撲視圖，發生故障時，能夠在拓撲視圖中直觀呈現，運維人員可以從多個維度快速感知故障影響范圍，并對故障進行簡單定界。全鏈路拓撲一般可以分成應用調用拓撲和網絡流量拓撲：-應用調用視圖：基于APM(applicationperformancemanagement，應用性能管理)調用鏈能力，追蹤應用進程內部的函數調用路徑，用于跨線程和異步場景故障感知。-網絡流量視圖：基于eBPF(extendedBerkeleyPacketFilter)內核組件和網絡報文染色能力，無侵入式覆蓋網關、基礎服務、網絡路徑、跨語言服務場景的故障感知。應用調用視圖33calls|120ms133calls|200ms503calls|568msuser-mgr31calls|102ms31calls|102msMySQL31calls|102msRabbitMQ31calls|102msapi-gwcache-mgr29calls|1014ms31calls|102msproduct-mgrRedis0%/8usGuestOS0%/10us3%/20usapi-gwGuestOSRabbitMQ網絡流量視圖subnetELBVPC源端源端subnet目的端目的端subnet0%/15us0%/8us0%/8usvSwitchELB源端0%/15usvSwitch0%/15usvSwitch0%/8us0%/8us0%/8us0%/15usvSwitch目的端0%/8us源端目的端圖2.5全鏈路應用拓撲視圖14PaaS實例可觀測式數據庫的長事務、慢SQL執行等指標。云平臺通常能夠提供豐富的PaaS實例，如容器集群、消息隊列、數據庫、分布式緩存、分布式事務等中間件，這一類PaaS實例由云平臺側提供開箱即用的SLI(servicelevelindicator,服務質量指標)，通過API或者監控對接等方式接入到應用運維平臺。此類指標以云平臺提供的客戶可感知的服務實例為中心，直觀體現實例狀態的監控指標，與實例類型強相關，通常以業務請求消息統計的形式獲取對應指標。-Error(錯誤率)：代表執行某一業務的錯誤率是多少，如分布式緩存高危命令、大Key使用等指標。-Ticket(工單)：代表某一功能是否需要人工介入，人工介入越多，可用性越差。PaaS實例SLI指標體系建設遵照VALET原則構建五個維度的指標：容量-Volume(容量)：是指服務承諾的最大容量是多少，如數據庫連接數、容器集群可用節點數等。可用性工單實例SLI指標-Availablity(可用性)：代表服務是否正常，如實例主備狀態、實例可用副本數量等。延時錯誤率-Latency(時延)：代表響應是否足夠快，如分布圖2.6遵照VALET模型建設SLI指標體系云服務（索引）功能點功能平面VALET類別指標名稱指標

指標

監控單位

周期

方式閾值規則重復次數影響說明連接使用率大于90%查詢服務過去1分鐘內為一個統計周監控期，至少3次檢測連接使上述指標表征DCS實例連接使用率情況，超過使用率可能導致實例新建連接失敗，可用性產生異常。DCS實例可連接性DCS實例連接使用率DCS數據面可用性%1分鐘3用率達到95%。查詢過去1分鐘內為一個統DCS實例可連接性DCS實例命令時延服務計周期，每分鐘統計的最監控大時延超過10ms，連續實例命令時延過長，阻塞后續命令執行，影響實例功能。DCSDCS數據面延時毫秒1分鐘31三次上報告警。查詢過去1分鐘內為一個統計周期，存在高危命令、大Key使用的告警。需要考慮告警聚合策略。DCS實例可連接性DCS實例使用規范性布爾類型數據面錯誤率1分鐘告警高危命令、大Key使用可能影響實例可用性。圖2.7可用性指標設計舉例15基礎設施可觀測綜上所述，構建核心應用的可觀測體系，應該從業務應用視角到云平臺資源視角進行分層設計。應用視角主要包含終端層和應用層，基于應用的核心功能，由業務開發人員、運維人員、測試人員組成“鐵三角”共同設計。云平臺資源層主要包含PaaS層實例和IaaS層基礎設施，由云平臺提供開箱即用的標準SLI指標，應用指標和資源指標匯聚接入到應用可觀測平臺中，由應用可觀測平臺統一對外呈現?；A設施指標主要是指以公共的基礎設施類資源為中心，用于體現基礎資源當前運行狀態的指標。此類指標只有出現瓶頸時才可能會影響上層業務，但很難定義出與上層業務之間明確的必然性以及關聯度，如：CPU使用率、內存使用率、IOPS、網卡發送速度等指標。此類指標無業務含義，重點體現的是基礎設施資源的運行狀態，而指標的異常也無法明確對上層業務的具體影響。由于比較通用，這類指標可通過公共能力統一提供。業務應用視角應用可觀測平臺端側可觀測終端應用日志指標事件終端體驗類指標端側數據采集APP瀏覽器撥測云撥測運營數據業務數據移動端JS錯誤端側體驗類撥測端側運行監控異常分析用戶旅程應用可觀測業務應用日志指標trace事件應用黃金指標應用數據匯聚全局拓撲鏈路追蹤代碼級診斷應用請求成功率應用功能響應時延應用請求吞吐量Profiling多語言接入實例可觀測云服務實例日志指標事件云實例可用性指標云實例數據匯聚容器集群可觀測中間件可觀測實例可連接性實例讀寫時延實例狀態集群監控Pod監控消息隊列RDS節點監控網絡監控GaussDB緩存基礎設施可觀測資源池日志指標事件基礎設施指標平臺CPU利用率內存利用率資源池數據匯聚管理虛擬機操作系統主機網絡網絡帶寬使用率存儲IO使用率存儲圖2.8四層指標體系16極簡信息匯聚，一站式觸達運維態勢，提升運維體驗和故障處理效率監控匯聚狀態可視：展現被管對象及內部組件的告警信息。基于告警可以快速感知對象的異常狀態；此外，運維平臺還應支持查看被管對象及內部組件的指標信息。如前所述，金融客戶在日常運維信息的獲取上，存在兩個關鍵痛點，一是運維體驗圍繞功能展開，對運維對象的操作需要在不同界面來回切換，體驗不暢；二是信息分散，比如描述狀態的告警指標信息、用于定位的日志和調用鏈信息、各類操作的狀態信息需要從不同的運維界面上獲取，導致故障處理效率低。因此需要持續構建極簡信息獲取的能力，使運維人員可以快速獲取所需的運維態勢信息，從而提升運維體驗和故障處理效率，進而解決企業運維要求高和運維能力不足的矛盾。拓撲關聯故障定界：展現被管對象與內部組件、底層部署依賴、周邊調用依賴等關系的拓撲圖，并在拓撲圖中展示各個對象的告警狀態。創建的拓撲應包括應用的物理拓撲、云服務物理拓撲、云服務部署拓撲等。通過對關聯對象的異常狀態分析，可以支撐運維人員進行故障定界。組件分析逐層下鉆：故障定界定位猶如抽絲剝繭，極簡運維要支持從故障表現的點開始，對齊內部組件和依賴資源，逐步、逐層進行下鉆分析，一步步接近問題根因。極簡信息獲取的設計理念信息集約：面向運維對象進行運維操作功能的體驗設計，例如，在同一個操作界面上集成運維對象的狀態信息、組件關聯、操作維護等信息。操作維護快速直達：集成被管對象的常見操作，如自動作業、節點診斷、撥測等，在日常運維和故障處理時，能夠快速完成操作。對象關聯：圍繞同一個運維對象，可向下關聯依賴的容器、物理設備等底層資源信息，向上關聯被依賴的應用組件信息，從而快速獲取與該運維對象相關聯的運維信息。2.1.2基于故障模式庫和云網一體化運維實現確定性故障恢復逐層下鉆：在呈現運維狀態信息時，界面應圍繞運維對象關系，展示逐層下鉆的內部組件和依賴資源相關的分析信息，以便逐步逼近問題根因。確定性故障恢復需要從應用系統視角和云平臺資源視角分別定義。一致體驗：所有被管理對象都有一致的全景360視圖體驗，從一個關聯對象可以一鍵跳轉至其全景360監控信息界面?；谠品展收夏Ｊ交€庫，對云服務實例進行全面診斷，以便精確定位、快速恢復故障應用可觀測平臺感知故障之后，通過指標的匯聚和算法處理，可以對故障進行初步的定界，輸出可能存在故障的資源實例，此時需要云平臺具備針對資源實例端到端的精確故障診斷和快速恢復能力。實現資源實例的診斷，需要大量的運維專家經驗，從實例的資源、依賴、歷史故障模式等多個維度進行分析，因此，構建云服務的故障模式庫至關重要。極簡信息獲取的目標效果運維信息展示要能夠圍繞運維對象進行匯聚，使運維人員可以方便且快速獲取需要的運維信息。對象狀態一屏概覽：被管對象概覽界面，要能夠展示對象關鍵信息，包括基本信息、告警、關鍵指標等內容。故障模式庫生成機制故障模式庫是在產品設計階段，對構成產品的組件進17行逐一分析，找出潛在的失效模式，并分析其可能造成的影響，根據組件的薄弱環節，輸出的預防措施列表。構建一個完善的故障模式庫需要至少包含如下三個方面：確定分析對象描述系統功能定義嚴酷等級建立框圖故障模式清單白盒化的故障模式分析：端到端梳理組件架構，根據組件在架構中的位置，分析可能的故障點。梳理云服務核心功能，并和組件架構有機結合，以實現對某一核心功能對應故障點的可視化呈現。此外，還應規劃對應故障點的自動化診斷、一鍵式恢復能力。FMEA分析圖2.9系統級FMEA故障模式分析流程黑盒化的功能性撥測：包括關鍵進程和端口的探測、網絡組件交互性撥測、及AA集群流量負載均衡的診斷。續積累故障模式庫。故障模式庫的推廣機制梳理故障模式庫只是故障處理的一種手段，讓站點能夠基于故障模式庫快速診斷、恢復故障才是最終目的。因此基于故障模式庫中定義的每一種故障模式都需要開發對應的內容包，內容包中應至少包含一套診斷腳本和一套恢復腳本。故障模式內容包應該與產品解耦，既可以集成到產品中支持新建站點的開箱即用，又可以單獨發布支撐存量站點的持續迭代更新。現網歷史故障補充：基于產品組件在現網中的歷史重大故障進行逆向覆蓋，確保重大質量問題全覆蓋，改進措施對應指標可診斷?？墒褂孟到y級FMEA(failuremodeandeffectanalysis，失效模式及效應分)故障模式分析流程持針對一類服務的某個核心功能的故障模式庫梳理故障模式描述產品對象核心功能點云服務名稱分布式緩存分布式緩存分布式緩存故障對象Redis實例Redis節點Redis實例故障模式故障影響嚴酷等級I類觀測方式應急恢復措施實例重啟Redis訪問Redis訪問Redis訪問實例狀態異常節點狀態異常實例拒絕連接影響業務訪問Redis影響業務訪問Redis影響業務訪問Redis實例狀態異常告警實例節點異常告警I類實例節點重啟調整實例最大連接數監控實例活躍客戶端連接數超規格I類故障模式適配包開發故障模式適配包推廣├─resource_{云服務索引}_{version}.zip│├─alarm#故障適配包#告警目錄開箱││├─{云服務索引}_alarm.json│├─monitor#告警靜態信息#監控目錄十統一新建站點即用故障模式內容包

適配包│├─script#非必選│││├─config.json│││├─{script}│├─operations#配置腳本范圍#腳本邏輯#運維操作目錄#操作配置│││├─actions.json││├─i18n#國際化目錄#自動作業目錄#操作目錄運維持續迭代存量站點│├─autoops治理包││├─operations││├─flows#編排目錄││├─i18n#國際化目錄圖2.10故障模式庫推廣機制故障模式庫運行機制運維人員在運維平臺上針對故障進行一鍵式診斷，對于診斷不通過項，進行一鍵式故障恢復。這樣可以減少運維人員對環境接入及運維能力的依賴，使他們可以更加聚焦業務。分布式緩存服務關系數據庫服務XXX服務告警監控指標監控自動作業狀態診斷腳本信息收集腳本快速恢復腳本狀態診斷腳本信息收集腳本快速恢復腳本狀態診斷腳本信息收集腳本快速恢復腳本局點運維人員圖2.11故障模式庫運行機制19圖2.12一鍵式故障診斷恢復示例云網一體化運維實現應用、虛擬鏈路、物理路由的一致性監控和運維用端點無損監測和iFIT真實業務流鏈路監測兩大核心功能實現。云網一體化運維是指將云計算與網絡技術相結合，對云計算環境中的網絡資源進行統一管理和維護的一種模式。在這種模式下，網絡管理員可以通過云計算平臺提供的工具和接口，對網絡資源進行實時監控、故障排查、性能優化等操作。虛擬&物理網絡可視診斷定界：主要通過Cloud-NetDebug虛擬網絡撥測和FabricInsight物理網絡定界兩大核心功能實現。（一）應用網絡真實業務流一屏監控云網一體化運維的實現依賴于云平臺和網絡設備的協同工作，云平臺需要提供相應的API接口，以便管理員可以訪問和操作網絡資源，同時網絡設備也需要支持相應的功能，如網絡監控、故障診斷、流量分析等，以實現對網絡資源的有效管理，從而實現云上Overlay資源與Underlay網絡設備的統一運維。1）eBPF應用端點無損監測eBPF是一種在Linux內核中運行的虛擬機，它允許用戶在不修改內核源代碼的情況下，動態地加載和執行代碼。eBPF最初是為了網絡數據包過濾而設計，已擴展到其他領域，如安全、跟蹤和性能分析。云網一體化運維通過如下兩個機制實現高效監控與問題定位：eBPF的運維涉及到許多方面，包括部署、監控、調試和排查。具體的實現機制是：eBPF以字節碼形式注入到應用內核中并掛載到特定鉤子(hook)掛載點應用網絡真實業務流一屏監控：主要通過eBPF應20上。當內核或應用程序執行到某個掛載點時，產生特定事件并觸發程序運行。eBPF技術的代碼無侵入、語言無關、高性能、強關聯、數據端到端覆蓋等特征，可滿足可觀測性標準和觀測數據采集的要求?；趀BPF內核觀測技術生成的網絡級丟包、時延、吞吐量等方面指標，可以實現流級的應用路況可視化監控能力。應用訪問拓撲可視：訪問關系圖、訪問量、訪問時間BPFProgramReaderLLVM/Clang應用網絡質量可視：重傳、擁塞、0窗口Prog.bfpbpfBytecodeUserspaceKernel2）iFIT真實業務流鏈路監測bpfIFIT(In-situFlowInformationTelemetry)是一種用于網絡流量監控和分析的技術，可以實時收集網絡中數據包的元數據信息，如源地址、目的地址、協議類型、源端口、目的端口等，及數據包的時間戳。通過分析這些元數據信息，可以了解網絡中流量的實時情況，識別流量模式和趨勢，檢測異常流量和故障，從而實現網絡的智能運維。eBPFBPFMapsBPFBytecodeVerifier+JITKernelFunctionsNativeCode圖2.13eBPF掛載原理iFIT主要基于在被檢測業務流報文中添加iFIT檢測頭，實現隨流的業務質量檢測，反映業務流的真實業務質量。R1(Source)1588v2/G8275.1R2(Destination)Tx[i+1]Tx[i]Rx[i+1]Rx[i]000111110000010001110100001T:染色周期每周期統計點后移，屏蔽亂序干擾：T+6T/10，后移6T/10時點圖2.14iFIT監測原理21借鑒IPFPM(FlowPerformanceMeasurement，流性能測量)染色機制，iFIT染色報文帶內測量技術可以構建流級的網絡路況追蹤和診斷能力，實現基于包粒度的真實業務流全鏈路檢測。這項技術具有以下幾方面特點：部署，自動按需E2E/逐跳檢測丟包位置：基于每節點的報文計數，分析丟包點逐跳時延/抖動：基于每節點的時戳記錄，分析鏈路/節點時延支持多種業務場景：L3VPN/EVPN/SRv6/SR-MPLS/MPLS路徑還原：基于每節點上報信息，呈現業務真實路徑易部署運維：頭節點按需定制，中間/尾節點一次圖2.15iFIT業務流監測實例如圖所示，實例中實現了網絡丟包、時延、抖動、帶寬等真實業務流路徑的可視監控。（二）虛擬&物理網絡可視診斷定界1）CloudNetDebug虛擬網絡撥測CloudNetDebug是面向運維人員的虛擬網絡診斷工具，幫助網絡管理員和開發人員快速診斷和解決云網絡中的問題。通過收集和分析云網絡中的數據包、流量和性能指標等信息，提供全面的視圖，使用戶能夠快速定位和解決網絡問題，包括數據包捕獲、流量分析、集成撥測和抓包、性能監測和故障排查等。通過客戶報文模擬撥測，應用報文抓取等方式，實現可視化撥測快速診斷定界。22正常周期撥測---覆蓋所有鏈路CNA1vRouter1BorderRouter1①CNA2···交換機1vRouter2···交換機3···BorderRouter2······BMSGW1交換機2ENAT1交換機4BorderRouter15BMSGW2預置探針ENAT2BorderRouter16出現故障場景---自動匯聚告警CNA1vRouter1BorderRouter1②CNA2···交換機1···vRouter2交換機3···BorderRouter2······BMSGW1交換機2ENAT1交換機4BorderRouter15BMSGW2預置探針ENAT2BorderRouter16圖2.16CloudNetDebug撥測原理軟件撥測定位是利用染色標記技術主動撥測抓包，通過跟蹤染色報文經過的路徑，覆蓋資源(IP)>虛擬交換網絡>物理交換網絡進行全景網絡拓撲的可視化撥測診斷。實際應用中，有如下兩種監控診斷模式：物理網絡診斷通過調用FabricInsight的接口獲取業務流路徑指標，包括流狀態以及交換機異常信息等，實現從控制面>虛擬網絡>物理網絡的三層穿透故障診斷。2）FabricInsight物理網絡定界LinkMonitor主動鏈路監控：通過在計算節點創建探針，創建出VPCL2、VPCL3、VPC-Peering、EIP和DC流量的撥測任務，自動周期性探測虛擬網元的轉發質量，以及網絡服務的鏈路質量，從被動問題處理轉變為主動發現鏈路質量問題，進而提前發現問題風險點。FabricInsight是一種用于物理網絡分析和監控的工具。這個工具支持實時監控和警報，幫助用戶快速發現和解決問題，更好地理解和管理他們的網絡鏈路系統，還提供了豐富的分析功能，幫助用戶深入了解網絡的性能和行為，并識別潛在的瓶頸和優化機會。此外，FabricInsight工具還支持多種物理設備組網的管理、控制和分析，支持網絡仿真校驗及虛擬感知，支持NetConf，OpenFlow，OVSDB，SNMP等協議，從而實現物理和虛擬網絡設備的可視化管理。FullLink全鏈路診斷：進行全鏈路復雜流量疊加場景的網絡問題定位。通過控制面診斷租戶的云服務配置、路由表、安全組和網絡ACL等配置，檢測每個網元的時延和丟包率實現虛擬網絡診斷。23網絡路徑設備KPI故障風險TCPSYN/FIN/RST報文采集逐跳真實路徑還原丟包/時延變更檢測網絡路況分析TCP連通性分析關聯逐跳故障分析關聯逐跳網絡質量分析逐跳配置變更檢測VMVMVMVMVMVMVMVMVMVMVMVMVM自動輸出故障定位結論圖2.17FabricInsight物理網絡故障定界硬件診斷定位是通過業務物理路徑指標，包括流狀態以及交換機設備故障、鏈路故障、轉發過載等，實現業務流路徑物理網絡端到端路徑的可視及異常定位。分析指標、日志、告警、配置、容量等運維數據，從風險隱患、性能規格、系統容量、系統可靠性、最佳實踐、版本生命周期、安全漏洞等多個維度對系統進行全面的評估。Fabric內業務流路徑可視：通過關聯分析逐跳設備信息感知故障斷點，故障一鍵式診斷，定位網絡路由、策略類故障根因。變更風險控制：通過建立變更前的風險識別和評審機制，提前識別變更的潛在風險；通過自動化及漸進式的變更過程，確保變更不引入風險。質差主動發現：基于網絡路況開放，實現應用網絡協同，通過技術分析微突發、丟包、光模塊異常等現象快速定界定位問題。未知風險挖掘：通過混沌工程識別系統的薄弱環節并改進，持續提升系統韌性。變“被動救火”為主動預防，構建運行態風險主動預防體系2.1.3基于一體化風險庫和混沌工程進行預見性風險治理面向未來，“被動救火”式運維將成為過去式，主動運維將成為保障系統高可用的重要手段預見性風險治理是一種前瞻性的風險管理方法，旨在通過事前的預測和診斷識別潛在風險，提前制定風險消減措施，保障系統的穩定運行。根據風險場景，預見性風險治理主要分為運行態風險預防，變更風險控制和未知風險挖掘三部分內容?！妒酚洝吩d，魏文侯問扁鵲“你們三兄弟誰的醫術最為高明？”扁鵲言“長兄最善，中兄次之，扁鵲為下?！蔽暮詈闷娴馈昂纬龃搜?？”扁鵲答“大哥治病，常以望聞問切，診斷隱患，在病害形成之前就能鏟除病因，因此一般人不知道大哥的厲害，是以聲名不顯。二哥治病于初起之時，大家以為他只能看看小病，所以他只聞名于鄉里。而我治病于運行態風險預防：建立完善的運行態風險主動預防體系，定期進行風險評估和監測。通過收集和24嚴重之時，用針刺猛藥，救人于危機之時，所以大家都以為我醫術最高明，因此名傳天下。金融云風險主動預防機制的核心思想是通過構筑中心化的風險庫，從風險規則的生成、風險診斷到風險的預警推送，構筑服務化的風險主動預防能力。實施層面可按如下思路展開建設：上工治未病，扁鵲長兄治病于未發，是為事前；中兄治病于漸發，是為事中；扁鵲治病于嚴重，是為事后。治病如此，運維亦是如此。運維的核心目標是保障業務可用，減少和避免故障發生。傳統的救火式運維，運維人員的工作內容和工作重心往往聚焦在事件和故障處理，偏向事后，這種運維方式無異于減少和避免故障，無法滿足現代化云運維的要求。從故障事前、事中和事后的角度看，事后恢復不如事中控制，事中控制不如事前預防。因此，必須摒棄傳統的救火式運維，變被動為主動，預防和減少故障發生，防患于未然。1.構建中心化風險庫構建中心化風險庫的目的在于將風險集中管理，防止風險管理的無序和散亂。風險庫的建設需遵循全面性、實時性和持續性原則。全面性：風險庫需要涵蓋明確的風險類型和范圍，如產品缺陷、性能過載、組網非標、配置隱患、版本配套、硬件適配、安全漏洞等，確保風險范圍覆蓋全面，防止遺漏。建設金融云風險主動預防體系，實現站點故障早發現實時性：風險動態實時更新，即風險從發現到入庫的時效性需要得到保證，確?，F網應用的風險庫時刻保持最新。主動運維并不是一個新鮮的概念，但在大部分的企業中，主動運維仍是一句口號，對于一個云平臺，如何能讓主動運維真正落地并產生效果？本質上來講，主動運維的目的在于事前預防，治病于未發是關鍵，因此需要重點構建事前的風險識別和預防能力。持續性：制定明確的風險庫管理制度，包括風險庫的更新和維護機制，確保風險庫的有效運行和持續更新。2.建立風險評估機制1986年，美國挑戰者號航天飛機發射后發生爆炸，事故造成7名宇航員喪生，發射活動以失敗告終。為了實現故障先預警，隱患早發現，NASA建立了航天器故障預防診斷平臺，旨在提前通過診斷檢查發現異常事件，保障航天器可靠運行，避免事故發生。對于云平臺這種大型的分布式軟件系統來說，建立風險檢測預防機制同樣是重中之重。風險評估機制是通過收集和分析信息數據，結合風險庫規則來識別風險隱患的過程，其目的是為了有效地識別系統風險。風險評估機制的主要步驟包括：信息收集：收集生產環境的指標、日志、告警、配置、資源、容量等運維數據，作為風險診斷分析的數據輸入。傳統IT系統的風險主動預防通常會以產品化的方式發布巡檢工具，通過在現網部署巡檢工具進行巡檢來識別風險，這種方式受限于工具的發布節奏，風險無法實時更新，無法保證現網時刻都可以應用到最新的風險庫。診斷分析：對收集的運維數據進行分析診斷，識別系統劣化指標，匹配風險庫規則進行風險冒泡，評估風險等級及影響，輸出健康度評估報告。253.建立風險預警流程變更前建立完善的風險預警機制，通過定期的風險評估報告方式將風險預警推送到現網，確保風險信息可以及時準確地傳遞給相關組織。同時，提供相應的風險規避措施，持續跟蹤風險在現網的閉環情況。-變更準入：建立變更準入機制，在變更申請階段對變更的準入條件進行控制，包括變更必要性評估，標準化變更方案制定，變更影響分析，回退方案、變更授權等；基于變更模型提前攔截變更態風險，通過全流程自動化實現變更態風險有效控制-風險識別：變更前對變更風險進行識別，包括變更歷史問題風險、變更方案風險、業務影響風險、高危操作風險等；變更風險控制是系統變更過程中至關重要的一環，旨在減少因系統變更而帶來的不利影響，提高變更的成功率。隨著業務數量和業務規模的持續擴大，現網的變更數量和變更頻次不斷增長，而頻繁的變更常常會給運維帶來不可預知的風險。據數據統計，70%的線上故障都是由變更引起，變更可能引起功能失效、性能下降、數據丟失甚至系統崩潰。如何有效管控變更風險，是運維工作面臨的巨大挑戰。面向現代化的變更風險控制能力構建可按下面思路進行考量：-變更評審：變更評審階段，由評審人對變更方案和變更風險進行評審，確保變更實施方案正確，變更影響和變更風險評估準確。變更中-灰度變更：構筑變更實施階段的灰度變更能力，按需控制變更范圍，可以盡早發現并解決變更問題，有效降低變更帶來的風險；1.變更風險控制需要在變更的不同階段構筑不同的控制能力-風險控制：在變更實施過程中控制變更操作的風險。對于高危操作、未授權操作實施攔截，對于變更過程中的異常和非預期結果，應實施變更自動終止操作。-變更監控：對變更過程實施監控，通過狀態、指標和告警，快速發現變更帶來的非預期影響。流程，使得變更在各個階段都能得到有效的跟蹤和控制。變更后變更申請階段，基于變更模型創建變更申請單，變更申請單自動獲取變更模型關聯的風險規則，同時根據風險規則識別變更風險。風險規則可以是特定的匹配規則或腳本，通過自動化流程運行風險規則或腳本，給出本變更所識別出的風險集合。-安全回退：構筑變更回退能力，包括變更全量回退以及按階段、按工步的局部回退，支持靈活的回退策略制定；-撥測驗證：建立變更后的業務撥測能力，在變更后通過業務撥測驗證變更業務是否可用，及時發現問題。變更評審階段，對于變更單所識別變更風險的閉環情況進行審核，確保變更風險全部閉環，變更流程才能進入變更實施階段。在變更申請和變更評審階段，重點構筑變更風險的識別和攔截能力。2.建立變更模型+風險規則的風險識別機制，確保變更風險提前識別首先，對不同類型的變更建立不同的變更模型，并對變更模型設定相應的風險規則，風險規則可來源于此類型變更的歷史問題和專家經驗，或與此類變更相關的狀態、指標和配置等。變更實施階段，基于工具構筑自動化變更及控制能力。工具應具備作業編排、灰度分批、高危攔截、熔斷回退等核心功能?；叶确峙兏湫偷膽眯问酵ǔＨ缦拢捍送?，應建立變更模型和風險規則的關聯機制，持續積累風險規則，通過工具能力自動識別風險，使得風險識別不依賴人，基于變更模型建立標準化的風險識別流程和能力，確保變更前風險有效識別。-灰度測試環境：提供獨立的灰度壞境。變更在生產環境實施前，在灰度環境上提前實施變更，進行業務驗證；3.基于流程和工具構筑變更風險控制能力，確保風險控制有效落地-生產環境分批實施：在生產環境中分批實施變更，優先選擇小范圍、重要性較低或影響可控對象實施變更，根據變更結果逐步放開批次。具體來說，應建立數字化的變更流程系統，從變更申請、變更評審、變更實施到變更驗證建立完善的變更推送、閉環執行腳本/規則流程變更實施風險評審識別風險創建變更單拉取風險信息導入模型變更模型風險腳本/規則圖2.18變更申請、評審流程27變更作業流水線變更作業子流程N變更作業子流程N+1生產批安全回滾灰度批批次2準入條件預檢查批次1生產批灰度批批次2安全回滾準入條件批次1預檢查安全回滾工具能力灰度分批安全回滾模板編排熔斷機制高危攔截生產驗證圖2.19典型灰度分批變更應用形式變更驗證階段，通過功能驗證、業務撥測等驗證手段，對變更后的業務進行可用性驗證，及時發現可能的風險。從系統架構層面，混沌工程可以驗證系統的容錯能力，推動提升系統的架構可用性；測試層面，混沌工程可以提前暴露線上問題，防止帶病上線；運維層面，混沌工程可以讓我們更好地理解和掌握系統的運行邏輯和規律，提升應急恢復效率，降低故障影響和損失，增強團隊應急能力，建立系統抵御未知風險的信心?；诨煦绻こ掏诰蛭粗L險，識別系統薄弱環節，持續提升系統韌性混沌工程核心思想：識別系統隱患，減少故障影響，提升系統韌性混沌工程的實施實踐混沌工程實踐可以按照如下步驟開展：混沌工程是一種實驗性的可靠性工程提升方法，是通過主動模擬故障場景來驗證系統在各種異常場景下的行為，通過比較假設行為和實際行為，發現系統存在的薄弱環節。在復雜的分布式系統中，交互關系和服務依賴錯綜復雜，難免會出現各種不可預料的突發事件，系統越復雜，越容易出現無法預知的故障?；煦绻こ讨荚谔崆白R別系統的未知風險，針對性地進行防范加強，讓系統在每一次故障中獲益，不斷優化，持續提升系統的韌性，保障業務的連續可用。制定試驗目標開展混沌演練之前，首先需要明確試驗目標及假設，確保實驗的有效性及針對性。例如，驗證某應用系統在過載場景下的保護機制，假設當流量過載時，系統的哪些指標會發生什么變化，預期會有什么保護措施會觸發等。28故障模式分析故障模式分析是混沌工程實踐的關鍵環節，通過6維故障分析法，從冗余、容災、備份、過載、依賴和安全維度，剖析系統的部署架構，邏輯架構和內外部的依賴關系，分析風險場景，選定故障模式，作為混沌演練的場景輸入。云平臺故障場景識別xx會議系統故障場景識別冗余lvs視頻網關APIGnginx故障點故障場景分析故障場景分析容災依賴安全備份前端負載均衡consoleframe6維故障分析法故障點故障點視頻前端web01視頻前端web02視頻后端servicehaproxyhaproxy視頻后端serviceapicomimsimsvpc故障點故障點pub-dbpub-db過載視頻數據庫DB圖2.206維故障場景分析法如圖所示，6維故障分析法對于云平臺和業務應用場景的故障模式分析均適用。例如，對于應用系統中的關鍵模塊，如web前端，在業務過載場景下，分析系統是否具備限流、降級或彈性擴容能力；對于數據庫，在業務過載場景下，分析系統是否具備自我保護能力等條件。演練復盤進行演練復盤總結，從產品質量、預案質量和運作流程等方面識別改進點并優化?；煦绻こ唐脚_構建混沌工程平是進行混沌演練的基礎，完整的混沌工程平臺需要具備故障模式管理、故障場景編排、故障注入、演練指揮、演練復盤等能力：制定應急預案根據故障場景，分析故障發生后的系統行為及影響，制定對應的應急預案。應急預案應包括故障的識別、影響范圍確認、故障隔離、恢復驗證等方面。故障模式管理提供豐富的故障模式庫，如過載類故障、網絡類故障、狀態變化類故障等，基于故障模式可以構造業務故障場景。過載類故障包括磁盤IO高，CPU負載高，內存利用率高，網卡流量高等。網絡類故障典型如網絡丟包、網絡時延、網絡中斷、網絡錯報、亂序、重復包等。狀態變化類故障有kill進程、關機、重啟、磁盤只讀、停止服務等。故障演練根據故障場景實施故障注入，觀察系統的行為是否符合預期，例如穩態指標觀察，容錯行為驗證等，同時驗證處置策略，恢復手段是否有效。29故障場景編排2.2應用運維現代化基于故障模式和資源對象，進行故障場景的靈活編排。2.2.1運維規劃前置到設計階段，業務可靠性來源于運維與設計的融合故障注入基于故障模式或故障場景，對資源對象進行故障注入，為系統引入錯誤行為。由于云上資源的多樣性，故障注入需要支持各種類型的資源，包括主機、虛機、容器、數據庫、中間件、進程等。隨著核心業務持續上云，金融企業對應用高可用要求達到了5個9。業務一旦出現故障不但會影響經濟效益，甚至會影響到國計民生，所以如何縮小應用故障的影響范圍，保障核心業務數據不丟失就成了企業面臨的頭等問題。因此，應用高可用設計成為應用與基礎設施現代化轉型的關鍵。演練指揮設置演練指揮中心，制定演練計劃，演練排班和應急預案，演練過程全程監控。然而，單純依靠傳統的運維方式已經難以保障業務的高可靠要求，運維需要前置到設計階段，業務可靠性來源于運維與設計的融合。演練復盤分析演練數據，對演練過程進行復盤總結，輸出演練報告，發掘改進環節并持續跟蹤。1.業務容災等級評估高可用設計并非單純的技術問題，成本也是影響鍵。由于高可用設計需要大量的費用投入，而其產出并不能立竿見影地被直接感知到，所以對于高可用設計往往需要先解決“高可用設計成本與業務預期的沖突”問題。演練文化混沌工程要在企業內部有效落地，首先需要認可其所帶來的價值，從組織、流程、文化建設方面引導，從上到下建立混沌演練文化。只有持續例行地開展演練工作，才能持續提升系統的容錯性和可恢復性，系統的韌性才能得到不斷提升。在投入成本方面，應用可用性要求越高，對應技術方案需要投入的成本也會越高。成本數據丟失損失成本數據可靠性成本應用可靠性成本應用宕機損失成本業務側期望業務側期望當前現狀當前現狀平衡點數據丟失時長(RPO)應用恢復時間(RTO)分鐘0分鐘普通業務重要業務關鍵業務重要業務普通業務圖2.21高可用設計與業務沖突預期沖突分析30如圖所示：當RPO和RTO都為0時，對應的高可用設計成本達到峰值；相反RPO和RTO時間比較高時，對應的高可用成本也會相應降低。如果所有業務都按照最高的高可用目標建設，金融企業將面臨巨大的高可用投入成本，所以在技術設計前，首先要對業務災備等級進行評估分類?；趹玫闹匾潭?，數據一致性要求，時延敏感性等因素可以將業務劃分為“關鍵業務”、“重要業務”和“普通業務”三個等級，重要程度依次降低。端邊縱向可觀測體系設計端側監控請求量日志傳輸指標三方服務業務指標體系搭建時延吞吐2.業務容災策略不同重要程度的業務選擇不同的容災策略：運維數倉匯聚運維數據關鍵業務的高可用設計原則是通過應用架構改造+部署架構改造，實現數據0丟失，同城多活，異地容災，并縮小故障爆炸半徑；配置告警圖2.22典型運維數據治理流程重要業務則需通過調整應用的部署架構（無需調整應用架構），實現數據丟失趨于0，同城主備，異地容災；進于一體的開箱即用的可觀測性平臺至關重要。構建這樣一個應用可用性觀測體系首先需要具備一個統一的運維數據倉庫，以及完善的業務可觀測指標設計。典型的運維數據治理流程主要包括運維數倉匯聚運維數據、業務指標體系搭建、端邊縱向可觀測體系設計三個步驟。運維數倉匯聚運維數據是基礎，業務指標體系搭建是核心，端邊縱向可觀測體系設計是補充。普通業務無需對應用和部署架構作任何調整，僅需進行關鍵數據的定時備份即可。3.高可用的持續治理應用高可用的保障過程是一個持續的治理過程。在經歷了前期的技術選型、方案設計、方案實施和方案驗證后，還需建立完善的容災管理制度，并通過專業的高可用技術團隊持續跟蹤和優化業務高可用的達成情況。所以應用高可用治理還涉及容災團隊建設、容災狀態監控、容災演練以及知識管理等一系列工作，才能真正保障應用高可用目標的達成。運維數倉匯聚運維數據應用運行過程中會產生大量的運維數據，包括端側數據、撥測網絡數據、實例指標數據(Metrics)、日志數據(Logs)、調用鏈數據(Traces)等。這些運維數據需要一個統一的運維數據倉庫進行承載。運維數倉主要由數據集成、ETL、數據湖、MPPDB、數據應用等功能組件構成，典型數據處理流程如下：2.2.2借助運維數倉構建應用可用性監控管理體系，實現業務故障實時感知定界應用可用性監控管理是面向應用運維的一個重要方面。著眼于持續現代化演進的應用可用性監控，建設一個圍繞故障生命周期集預防、檢測、診斷、恢復、通報和改數據集成：這些數據并非全部是結構化的數據，因此需要有完備的數據集成平臺，支持多種運維數據接入，如消息隊列、API集成、SFTP集成等。31數據抽?。簲祿尤胫笥蒃TL對單條數據進行過濾、切分、擴展、格式化等操作，統一放到消息隊列中。數據湖處理：不同的數據主體消費消息隊列中的數據，完成不同的數據存儲，如原始日志或者指標存放到OBS中、單條粒度數據直接入庫或者通過格式定義存放到ClickHouse中、時序多維度量數據需要依據一定的數據治理規則分多個表保存在MPPDB中。數據應用：所有運維數據治理完成之后，由數據應用對數據進行API封裝，提供對外統一查詢接口。UniQueryServer運維數倉數據應用單條粒度運維數據[ClickHouse]時序多維度量數據離線數據分析數據倉庫數據湖ETL后端數據訂閱分發[Kafka]日志原始文件[HDFS/OBS]單條粒度運維數據單條數據過濾、切分、擴展、格式化[SparkStreaming/Flink]數據集成接入[Kafka/SFTP/HTTPS]數據集成端側數據采集APMS撥測服務EchoTest指標監控系統Prometheus日志服務LogService調用鏈服務NuwaTrace自定義數據圖2.23應用運維數倉典型架構業務指標體系搭建例，針對這些測試用例梳理黑盒化指標，如撥測類指標、規格類指標等；運維人員則根據運維過程中的問題持續對指標進行優化，三者相互配合，構建完備的業務可觀測指標。業務可觀測性指標是指在企業的業務層面上，通過監測、分析和理解數據，設計出來的用以表征業務運行情況、用戶體驗的業務指標。業務可觀測性更加關注運行過程、用戶旅程和客戶交互等方面的可視化，從而幫助企業更好地理解業務的健康狀況，給最終用戶提供更好的用戶體驗。業務可觀測性指標設計步驟通常情況下，業務可觀測指標體系搭建主要分成如下四個步驟：業務可觀測性指標梳理參與角色設計可觀測性指標的前提是對業務系統功能有非常深入的理解，因此應用開發人員、測試人員、運維人員組成的“鐵三角”缺一不可。開發人員可以對系統功能的實現邏輯進行白盒化剖析，通過監控和日志手段在開發階段預埋相應的指標；測試人員更多從用戶體驗視角設計相應的測試用a.數據調研，分解業務要素指標設計人員將業務系統的功能進行拆解，梳理出業務核心功能點，每個功能點會產生的數據類型（結構化數據、日志、指標等），以及明確這些數據的作用。32b.梳理概念模型，構建總線矩陣每個核心功能點識別之后，就需要開發人員對每個核心功能點的業務過程進行白盒化梳理，包括每個業務過程需要關注的數據維度，以及每個維度對應的字段。以互聯網應用“設備登錄”業務過程為例，應用需要獲取設備類型、設備品牌、登錄地域、登錄運營商、HTTP響應狀態碼、業務響應狀態碼等維度的數據。一致性維度業務過程業務過程一級二級請求來源Apple設備類型DevtypeProductID品類地理區域http響應碼業務響應碼運營商北向設備注冊南向直連設備注冊南向下掛設備注冊南向批量下掛注冊南向設備登陸設備注冊設備登陸北向藍牙設備數據上報北向三方設備數據上報南向設備數據上報設備數據上報設備查詢設備控制設備認證北向設備注銷南向設備注銷設備注銷南向鴻蒙設備重置圖2.24設備登錄業務過程總線矩陣舉例c.邏輯模型設計根據總線矩陣，進行數據倉庫邏輯模型設計，在維度建模中，有以下一些關鍵概念和組件：維度(Dimension)：維度是描述業務過程的屬性或特征，用于對事實進行分類和分組。事實表(FactTable)：事實表是數據倉庫中的核心表，包含了與業務過程相關的數值型度量或指標。事實表中的每一行通常表示一個業務事件或交易，并與一個或多個維度表相關聯。在實際應用時，應該盡量將來源于同一個業務過程的底層度量結果存儲于一個維度模型中。維度表(DimensionTable)：維度表包含了描述事實表中度量的上下文信息，它們用于描述與“who、what、where、when、how、why”有關的事件，用于對事實進行分組和篩選的屬性。33維度表事實表維度表層次結構(Hierarchy)：維度可以具有層次結構，即組織成多個級別的數據。例如，時間維度可以包含年、季度、月等層次。維度表維度表維度表維度表度量/原子指標(Measure)：原子指標和度量含義相同，是事實表中的數值型數據，表示業務過程的性能或結果，是用戶在數據倉庫中分析的關鍵指標。維度表維度表圖2.25數據倉庫維度模型——星形維度模型設備維度表歌曲播放事務事實表日期維度表維度設備編號DID設備內部型號設備產品傳播名設備品牌日期[FK]設備編號DID[FK]設備產品傳播名時間[FK]時間維度表設備品類華為賬號編號UP_ID[FK]歌曲代理IO[FK]歌曲名稱設備價格范圍設備上市日期…歌曲專輯代理ID[FK]藝術家[FK]藝術家維度表賬號維度表度量播放時長歌曲維度表有效播放時長播放次數…...歌曲專輯維度表圖2.26星形維度模型實踐舉例34d.物理模型開發與上線應用完整的全鏈路監控是非常有價值的工作：物理模型開發就是在邏輯模型中填充數據的過程，填充的數據就是在總線矩陣中定義的數據，這些數據的來源主要是業務系統的數據庫、日志、調用鏈(本質上也是日志)、指標數據等。而這些數據并非結構化數據，需要經過清洗，匯聚到數據倉庫的物理表中，才能夠讓指標設計人員對指標進行進一步處理(如打標簽或者派生指標設計)，最終完成業務可觀測性指標上線。可以提升故障主動發現率，減少故障對業務的影響，提高系統的穩定性和可靠性。通過逐層下鉆的數據分析能力，幫助快速定位和解決問題。通過對系統的實時監測和數據分析，提供決策支持，優化系統性能和資源利用率。端邊縱向可觀測體系設計應用運維的運維對象是應用，即是將“應用”作為一個獨立的邏輯實體。所有該應用所使用的資源，如VM、Docker、中間件、數據庫等，都是該“應用”的組成部分。所以對于應用運維來說，構建該上一章節主要闡釋了指標體系如何構建，下面介紹如何根據這些能力構建一個典型應用的全鏈路監控模型。App/ServerKit邊緣網絡服務&微服務二方/三方AccountkitAudioKit…ELBWeb服務器數據庫三方服務二方服務SLB應用NoSQL服務器Internet/骨干網&CDNAPP體驗指標API性能指標邊緣網指標服務&微服務性能依賴方性能下載成功率安裝成功率首頁打開耗時首頁圖片耗時用戶搜索耗時應用詳情耗時用戶下載速率…API時延調用量成功率…帶寬流量速率CDN…API時延主機性能中間件數據庫基礎設施…API時延調用量成功率…圖2.28典型應用全鏈路監控模型：端邊云縱向可觀測體系35根據上圖我們可以看出，一個應用要對最終用戶產生價值，整個數據流是從端側發起，經過接入側、廣域網、數據中心傳輸后，最終到達云上的服務端完成邏輯處理，再返回到端側，完成一次完整的數據交互。其中在云上服務端處理的過程中，還存在與第三方外部服務調用的場景。在這個交互過程中，任何一個環節都可能影響到最終用戶的使用和體驗。所以對于應用的全鏈路監控來說，每個環節都應該盡可能地做好監控。處理，掌握傳輸過程的數據有利于在協同處理中更高效地完成故障修復。由于無法在傳輸節點上采集數據，這部分的時延數據一般可通過云側與端側的指標通過復合計算得到。而邊緣加速網絡的數據可以通過供應商的標準監控能力獲取。云側監控應用的云側監控除了應用黃金指標外，還應包括構建該應用的資源監控。這部分的監控數據來源于云基礎設施監控能力，但要