2024年主機上云運維現(xiàn)代化核心能力白皮書

踐行深度用云主機上云運維現(xiàn)代化核心能力 目錄CONTENTS目錄05-08主機上云帶來的運維新挑戰(zhàn)挑戰(zhàn)1：如何基于應(yīng)用視角設(shè)計高可用上云方案與高可靠運維保障方案挑戰(zhàn)2：云平臺技術(shù)棧快速增厚，如何有效進行全鏈路可視監(jiān)控挑戰(zhàn)3：云網(wǎng)深度融合，如何快速發(fā)現(xiàn)、定位、恢復(fù)問題挑戰(zhàn)4：如何應(yīng)對運維安全與租戶安全的雙重挑戰(zhàn)09-43主機上云運維現(xiàn)代化核心能力平臺運維現(xiàn)代化全鏈路運維監(jiān)控構(gòu)建從應(yīng)用到云平臺的全棧感知能力基于故障模式庫和云網(wǎng)一體化運維實現(xiàn)確定性故障恢復(fù)基于一體化風險庫和混沌工程進行預(yù)見性風險治理應(yīng)用運維現(xiàn)代化運維規(guī)劃前置到設(shè)計階段，業(yè)務(wù)可靠性來源于運維與設(shè)計的融合借助運維數(shù)倉構(gòu)建應(yīng)用可用性監(jiān)控管理體系，實現(xiàn)業(yè)務(wù)故障實時感知定界面向故障全生命周期，全方位提升故障感知、診斷、恢復(fù)智能化水平安全運維現(xiàn)代化全視角運維安全體系設(shè)計構(gòu)筑金融云運維安全堤壩體系化、智能化安全運營為云上業(yè)務(wù)保駕護航44結(jié)語主機上云帶來的運維新挑戰(zhàn)挑戰(zhàn)1：如何基于應(yīng)用視角設(shè)計高可用上云方案與高可靠運維保障方案主機上云的最大挑戰(zhàn)就是核心應(yīng)用上云后的可用性管理。隨著原來運行在大機上的應(yīng)用不斷遷移上云，云上的業(yè)務(wù)可用性等級要求被提升到了新的高度，傳統(tǒng)的運維手段已經(jīng)無法滿足核心業(yè)務(wù)N個9的可用性目標。可用性管理前置到了系統(tǒng)設(shè)計乃至應(yīng)用設(shè)計階段。即便如此，可用性管理依然面臨著成本、技術(shù)和管理的三重挑戰(zhàn)。首先，無論是備份、主備、多活還是業(yè)務(wù)單元化改造，所有的高可用的架構(gòu)設(shè)計都需要投入高昂的成本，高可用的效果和技術(shù)方案的投入成本成正相關(guān)關(guān)系。如何平衡高可用的投入與產(chǎn)出就成為IT管理者在高可用管理過程中的重要難題?；谙冗M的單元化設(shè)計理念達成核心應(yīng)用N個9的可靠性也是IT管理者面臨的難題。最后，服務(wù)SLA（ServiceLevelAgreement,服務(wù)水平協(xié)議）的達成還需要有相匹配的管理手段與工具，如故障模式庫、演練工具等資源作為支撐，不但要能有效跟蹤度量SLA的實際效果，還需要持續(xù)、主動發(fā)現(xiàn)可用性風險的機制與工具，在可用性管理的過程中實現(xiàn)數(shù)據(jù)積累和能力演進。挑戰(zhàn)2：有效進行全鏈路可視監(jiān)控隨著主機上云和業(yè)務(wù)云化轉(zhuǎn)型的持續(xù)深入，分布式數(shù)

據(jù)庫、中間件、AI、大模型等各種云原生技術(shù)被廣泛應(yīng)用。新服務(wù)、新技術(shù)的迭代加速，猶如一柄雙刃劍，在助力業(yè)務(wù)快速發(fā)展、快速創(chuàng)新的同時，也帶來了系統(tǒng)技術(shù)棧復(fù)雜度的急劇提升，給傳統(tǒng)的IT運維方式帶來巨大沖擊。例如，應(yīng)用的微服務(wù)化改造，帶來微服務(wù)數(shù)量的指數(shù)級增長，應(yīng)用的調(diào)用層次和調(diào)用關(guān)系變得冗長；分布式云原生的深度應(yīng)用，使得業(yè)務(wù)鏈路更加復(fù)雜。當上層業(yè)務(wù)應(yīng)用出現(xiàn)故障時，排障過程可能涉及從應(yīng)用到網(wǎng)絡(luò)的完整鏈路，這其中包含業(yè)務(wù)應(yīng)用、云服務(wù)實例、云基礎(chǔ)設(shè)施和服務(wù)器、網(wǎng)絡(luò)、存儲等物理設(shè)備。典型的業(yè)務(wù)流量路徑如：應(yīng)用>容器>PaaS擬機>服務(wù)器>虛擬網(wǎng)絡(luò)>物理網(wǎng)絡(luò)。在針對這個路徑的運維實際工作中，應(yīng)用、虛擬機軟件提供方、服務(wù)器和網(wǎng)絡(luò)設(shè)備提供方常常是各管一段，整個業(yè)務(wù)從上到下的全棧調(diào)用路徑往往是個黑盒，導(dǎo)致故障定位定界困難，或者恢復(fù)時長無法控制。面對IT系統(tǒng)復(fù)雜的技術(shù)棧及海量的運維對象，做到軟硬件運維對象的統(tǒng)一管理，指標、告警、日志、調(diào)用鏈、拓撲等運維數(shù)據(jù)的統(tǒng)一匯聚和分析，構(gòu)建全鏈路故障感知、全棧故障可視的運維體驗，對于金融主機上云過程中的運維工作至關(guān)重要。挑戰(zhàn)3：云網(wǎng)深度融合，如何快速發(fā)現(xiàn)、定位、恢復(fù)問題過去一年，在互聯(lián)網(wǎng)領(lǐng)域發(fā)生過多起頗為嚴重的宕機事故：2023年3月，某互聯(lián)網(wǎng)服務(wù)商發(fā)生機房故障，多個互聯(lián)網(wǎng)核心應(yīng)用受到影響，事故持續(xù)7個小時，影響約十幾億用戶。2023年11月，某云服務(wù)商旗下多款應(yīng)用出現(xiàn)無法登錄故障，事故持續(xù)4個小時，這是該云服務(wù)商時隔一年之后第二次出現(xiàn)嚴重故障。2023年11月，某互聯(lián)網(wǎng)服務(wù)公司核心應(yīng)用業(yè)務(wù)癱瘓接近12個小時，流失千萬訂單，直接損失上億元，引發(fā)了廣泛的社會關(guān)注?？偨Y(jié)上述這些事故，它們都具備了如下幾個特點：事故影響范圍巨大，社會反響強烈，更有甚者還會對社會的衣食住行產(chǎn)生嚴重影響。事故影響時間較長，業(yè)務(wù)恢復(fù)周期以數(shù)小時計，嚴重者故障恢復(fù)時長達到了12小時。造成巨額經(jīng)濟損失，負責人被處分、問責。隨著上云進程的逐漸深入，金融企業(yè)開始將核心應(yīng)用搬遷上云。核心應(yīng)用一般有著規(guī)模大、分布式、架構(gòu)復(fù)雜等特點，這一點和互聯(lián)網(wǎng)業(yè)務(wù)非常相似，上述互聯(lián)網(wǎng)的故障也在時刻給金融核心應(yīng)用的運維敲響警鐘。在此背景下，近年來金融領(lǐng)域客戶提出了核心業(yè)務(wù)的“1-5-10”目標，即：1分鐘發(fā)現(xiàn)故障、5分鐘定位、10分鐘恢復(fù)。要實現(xiàn)這個目標必須要解決以下關(guān)鍵問題：如何盡可能地少出問題首先，需要有一個完善的運維規(guī)范和流程來保障運維流程合規(guī)；其次，核心應(yīng)用需要全局的高可用設(shè)計，從架構(gòu)層面避免單點故障；最后，企業(yè)還應(yīng)具備完善的風險管理體系，可以對識別到的風險舉一反三快速閉環(huán)，持續(xù)提升核心應(yīng)用的韌性。如何快速恢復(fù)故障基于核心應(yīng)用黃金指標的秒級故障感知是故障恢復(fù)的前提；基于調(diào)用鏈分析、日志解析、云服務(wù)實例快速診斷的分鐘級故障定位是故障恢復(fù)的基礎(chǔ)；基于應(yīng)急處理預(yù)案的一鍵式故障恢復(fù)是行之有效的手段。

如何解決云網(wǎng)絡(luò)問題在云網(wǎng)絡(luò)和物理網(wǎng)絡(luò)深度融合的場景下，應(yīng)用級的網(wǎng)絡(luò)可視、云網(wǎng)絡(luò)端到端的故障探測是解決云網(wǎng)絡(luò)問題的關(guān)鍵所在。挑戰(zhàn)4：如何應(yīng)對運維安全與租戶安全的雙重挑戰(zhàn)主機上云的過程中，應(yīng)用與云平臺的運維會同時受到運維安全和租戶安全的雙重挑戰(zhàn)。在運維安全方面常見的挑戰(zhàn)包括：運維安全意識不足運維管理者缺乏對運維安全的完整規(guī)劃，在制度、流程和技術(shù)規(guī)范方面缺少對變更的嚴格管控。在缺乏對變更的嚴格審控機制的情況下，隨意的變更為引發(fā)后續(xù)事故埋下了隱患。運維安全管控的技術(shù)手段不足主要表現(xiàn)為，對運維操作入口沒有進行技術(shù)管控，缺乏對運維操作過程的有效監(jiān)管，缺乏對高危操作的攔截，缺乏對運維操作的記錄與審計，缺乏識別惡意操作的評估手段。權(quán)責不匹配運維人員的權(quán)限過大或者超越自己的職責范圍，很容易引發(fā)超出職責范圍的誤操作，從而帶來不必要的運維風險。在租戶安全方面的挑戰(zhàn)包括：安全攻擊無法避免希望一勞永逸地解決租戶安全問題是不切實際的。人類的操作永遠無法做到完美，系統(tǒng)和技術(shù)總在不斷演進，新的漏洞會不斷出現(xiàn)，完全消除漏洞是不可能的。所以，0日攻擊、釣魚攻擊以及賬戶被破解都無法被避免。租戶安全防護難以全局統(tǒng)籌現(xiàn)代企業(yè)和組織的網(wǎng)絡(luò)環(huán)境越發(fā)復(fù)雜，涉及眾多設(shè)備、應(yīng)用、數(shù)據(jù)類型。同時安全威脅也在不斷演變，包括網(wǎng)絡(luò)攻擊、釣魚、木馬、病毒、社會工程學攻擊等多種形式。安全團隊需要同時跟蹤多種威脅情報，及時調(diào)整安全策略和措施，以應(yīng)對各種各樣的威脅。安全威脅處置緩慢安全威脅普遍具有隱蔽性強的特點，不易被及時發(fā)現(xiàn)?，F(xiàn)代安全威脅越來越復(fù)雜和多樣化，攻擊手段和方式不斷演變，安全團隊需要花費更多時間來分析和

理解威脅的本質(zhì)，以制定有效的處置策略。有時候安全團隊還會面臨技術(shù)上的限制，從而需要花費更多時間來研究和實施解決方案。在實際業(yè)務(wù)場景中，由于安全管理不善造成重大事故和業(yè)務(wù)損失的案例并不鮮見，如誤刪數(shù)據(jù)庫賬戶造成結(jié)算業(yè)務(wù)失效，誤刪虛擬機造成業(yè)務(wù)中斷，租戶權(quán)限管理不當誤刪OBS桶等等。云化、集中化雖然提升了業(yè)務(wù)的創(chuàng)新速度，也讓運維安全的管控以及租戶安全的治理變得更加復(fù)雜，所以運維安全是業(yè)務(wù)可靠性保障的基石，也是運維現(xiàn)代化的基礎(chǔ)。主機上云運維現(xiàn)代化核心能力主動預(yù)防運行穩(wěn)定主動預(yù)防運行穩(wěn)定安全可靠1.2.3.存貸款存貸款支付結(jié)算現(xiàn)金管理理財管理資金交易中間業(yè)務(wù)消費信貸全鏈路運維監(jiān)控確定性故障恢復(fù)全鏈路運維監(jiān)控確定性故障恢復(fù)預(yù)見性風險治理全鏈路可觀測云網(wǎng)定位定界主動風險預(yù)防面向應(yīng)用運維故障精準診斷變更風控管控極簡信息匯聚一鍵故障恢復(fù)混沌工程演練高可用架構(gòu)設(shè)計智能化應(yīng)用運維高可用SLA規(guī)劃運維數(shù)據(jù)治理應(yīng)用高可用設(shè)計可用性指標構(gòu)建持續(xù)高可用治理運維故障分析全視角運維安全體系化安全運營用戶授權(quán)可控制立體防御體系作業(yè)過程可信賴主動智能安全潛在風險可識別全面安全運營主機上云新基座應(yīng)用平遷上云應(yīng)用改造上云核心重構(gòu)圖2.1運維現(xiàn)代化三大核心能力平臺運維現(xiàn)代化平臺運維的現(xiàn)代化轉(zhuǎn)型重點要考慮如下三方面的能力建設(shè)：全鏈路運維監(jiān)控核心業(yè)務(wù)上云的過程中，云與應(yīng)用的耦合度逐步提高，應(yīng)用與云平臺的關(guān)系愈加復(fù)雜，因而云運維必須實現(xiàn)應(yīng)用到云平臺乃至物理設(shè)備的全鏈路覆蓋。同時需要梳理出應(yīng)用與云平臺間的依賴關(guān)系，當應(yīng)用出現(xiàn)故障的時候能夠基于應(yīng)用的視角快速感知和診斷故障。確定性故障恢復(fù)快速創(chuàng)新的金融業(yè)務(wù)場景增加了云平臺技術(shù)棧復(fù)雜度，也因此提升了故障定界、故障快速恢復(fù)的難度。

華為云給出了通過全鏈路檢測、故障模式庫和云網(wǎng)結(jié)合快速定界故障的思路，以此提升核心應(yīng)用上云后云平臺故障恢復(fù)的確定性。預(yù)見性風險治理實現(xiàn)風險的提前感知與預(yù)防始終是運維管理者長期的期望，也是運維人員一直面臨的難題。這個問題同樣擺在華為面前。在十多年運維工作中，華為云通過大量項目實踐摸索出了一套預(yù)見性風險治理的思路，不但覆蓋了運行時的風險治理，也覆蓋了對變更的風險治理方法，以及對未知風險的識別與預(yù)防手段，本文將詳細闡釋通過數(shù)字化到自動化的轉(zhuǎn)換實現(xiàn)云平臺風險預(yù)見性治理的思考。10應(yīng)用運維現(xiàn)代化只有打破各個工具間的數(shù)據(jù)孤島才能統(tǒng)籌洞察應(yīng)用的完整運行態(tài)勢，對應(yīng)用進行全方位的監(jiān)控與分析。在本文中，華為云提出要將應(yīng)用的可靠性保障前置到設(shè)計階段，通過高可用設(shè)計提升應(yīng)用的可靠性，同時也給出了應(yīng)用高可用設(shè)計的思路，幫助金融企業(yè)選擇合適的高可用方案平衡成本與效益的矛盾。安全運維現(xiàn)代化運維安全是保障業(yè)務(wù)可靠性的基石，也是運維現(xiàn)代化的基礎(chǔ)。在運維安全領(lǐng)域需要通過對運維過程無死角的安全管控來保障運維安全，具體來說，需要實現(xiàn)事前對權(quán)限的有效規(guī)劃和管理，事中對運維操作的嚴格管控，以及事后對運維操作的審計與分析，減少由于運維誤操作給云業(yè)務(wù)帶來的風險。除了云平臺本身的安全保障，在租戶安全維度，也應(yīng)構(gòu)建完整的安全防護體系，端到端保障云租戶的安全。平臺運維現(xiàn)代化核心能力全棧感知能力從應(yīng)用視角到平臺視角，構(gòu)建全面的指標體系，快速感知故障核心應(yīng)用部署上云，從上到下可以分為四層，分別為終端層、應(yīng)用層、PaaS實例層和IaaS基礎(chǔ)設(shè)施層。如下圖：終端層嚴格意義上并不在云上部署，主要部署在端側(cè)，通過APP或者瀏覽器實現(xiàn)應(yīng)用訪問；

應(yīng)用層通過在容器集群、彈性云服務(wù)器、裸金屬服務(wù)器上部署復(fù)雜的應(yīng)用，實現(xiàn)某些業(yè)務(wù)功能；PaaS實例層主要是指云平臺提供的容器集群、中間件、數(shù)據(jù)庫等實例資源；IaaS基礎(chǔ)設(shè)施層主要指提供計算、存儲、網(wǎng)絡(luò)的基礎(chǔ)資源池，如云數(shù)據(jù)中心的存儲池、虛擬網(wǎng)元、計算資源池或者傳統(tǒng)數(shù)據(jù)中心的服務(wù)器、網(wǎng)絡(luò)設(shè)備、存儲設(shè)備等。訂單處理2msELB102msapi-gwcache-mgrAPP APP APP訂單處理2msELB102msapi-gwcache-mgrAPP APP APP200ms102ms102msRabbitMQ數(shù)據(jù)庫product-mgrRedis緩存 容器節(jié)點 云硬盤 云主機宿主機 網(wǎng)元存儲池 宿主機宿主機網(wǎng)元存儲池 宿主機物理主機網(wǎng)元存儲池終端層應(yīng)用層120msuser-mgr102msMySQL10實例層層paaslaas云數(shù)據(jù)中心1 云數(shù)據(jù)中心2 傳統(tǒng)數(shù)據(jù)中心實例層層paaslaas圖2.2典型云上應(yīng)用部署模型構(gòu)建核心應(yīng)用可觀測體系，需要根據(jù)應(yīng)用部署層級分別進行設(shè)計：終端可觀測終端層需重點關(guān)注用戶的使用體驗，采集終端應(yīng)用運行報告、訪問成功率、接口延時等體驗類指標，通過終端內(nèi)置的軟件工具包(SDK)上報到應(yīng)用可觀測平臺。必要時需要部署一定數(shù)量的云撥測終App/ServerApp/ServerKit邊緣網(wǎng)絡(luò)AccountkitAudiokit…Internet/骨干網(wǎng)&CDN

端，對應(yīng)用進行周期性撥測，快速感知邊緣網(wǎng)絡(luò)故障。終端層常見指標舉例：APP用戶搜索耗時、用戶下載速率等表征最終用戶體驗的指標量消耗等應(yīng)用可觀測應(yīng)用層需要根據(jù)應(yīng)用的核心功能，構(gòu)建表征功能健康度的黃金指標。不同應(yīng)用功能存在差異，梳理出的指標不盡相同，指標越能精細表征健康度，越能快速感知故障，反之亦然。以某互聯(lián)網(wǎng)視頻應(yīng)用為例，需要基于應(yīng)用接口日志定義接口請求量、接口成功率、接口時延、播放卡頓率等指標，針對指標數(shù)據(jù)進行治理，最終呈現(xiàn)不同時間維度的視圖，同時支持針對流量的趨勢進行動態(tài)閾值調(diào)整，準確產(chǎn)生指標告警。APP體驗指標API性能指標APP體驗指標API性能指標邊緣網(wǎng)絡(luò)指標下載成功率API時延帶寬安裝成功率調(diào)用量流量首頁打開耗時成功率速率首頁圖片耗時…CDN用戶搜索耗時……APP...視頻分類請求結(jié)果...時延1.0.1長視頻成功301.0.2短視頻成功501.0.1短視頻成功351.0.3長視頻失敗40維度：APP版本、視頻分類度量：請求結(jié)果標識、時延 視頻登錄請求次數(shù)維度：APP版本、視頻分類度量：請求結(jié)果標識、時延 視頻登錄請求次數(shù)視頻登錄請求成功次數(shù)/視頻登錄請求成功次數(shù) 視頻登錄請求次數(shù) 視頻登錄請求成功率 長視頻登錄請求成功率邏輯主體基礎(chǔ)指標派生指標指標疊加公式組合指標派生組合指標XX（%）長視頻登錄請求成功率XX（%）視頻登錄請求成功率X（次）視頻登錄X（次）視頻登錄請求次數(shù)應(yīng)用指標定義完成之后，還需要構(gòu)建應(yīng)用全鏈路拓撲視圖，發(fā)生故障時，能夠在拓撲視圖中直觀呈現(xiàn)，運維人員可以從多個維度快速感知故障影響范圍，并對故障進行簡單定界。全鏈路拓撲一般可以分成應(yīng)用調(diào)用拓撲和網(wǎng)絡(luò)流量拓撲：-應(yīng)用調(diào)用視圖：基于APM(applicationperformancemanagement，應(yīng)用性能管理)調(diào)用鏈能力，追蹤應(yīng)用進程內(nèi)部的函數(shù)調(diào)用路徑，用于跨線程和異步場景故障感知。-網(wǎng)絡(luò)流量視圖：基于eBPF(extendedBerkeleyPacketFilter)內(nèi)核組件和網(wǎng)絡(luò)報文染色能力，無侵入式覆蓋網(wǎng)關(guān)、基礎(chǔ)服務(wù)、網(wǎng)絡(luò)路徑、跨語言服務(wù)場景的故障感知。應(yīng)用調(diào)用視圖應(yīng)用調(diào)用視圖33calls|120msuser-mgr31calls|102ms31calls|102ms31calls|102msMySQLapi-gw133calls|200ms31calls|102ms503calls|568msRabbitMQ29calls|1014mscache-mgrproduct31calls|102ms-mgrRedis0%/8us0%/10usapi-gw 3%/20usGuestOSGuestOSRabbitMQ網(wǎng)絡(luò)流量視圖網(wǎng)絡(luò)流量視圖subnetELB源端subnet目的端subnet VPC源端目的端0%/15us0%/8usvSwitchELB源端0%/8us0%/8us0%/15usvSwitch0%/15us0%/8us0%/8us0%/8us0%/15us目的端vSwitchvSwitch源端目的端圖2.5全鏈路應(yīng)用拓撲視圖PaaS實例可觀測云平臺通常能夠提供豐富的PaaS實例，如容器集群、消息隊列、數(shù)據(jù)庫、分布式緩存、分布式事務(wù)等中間件，這一類PaaS實例由云平臺側(cè)提供開箱即用的SLI(servicelevelindicator指標)，通過API或者監(jiān)控對接等方式接入到應(yīng)用運維平臺。此類指標以云平臺提供的客戶可感知的服務(wù)實例為中心，直觀體現(xiàn)實例狀態(tài)的監(jiān)控指標，與實例類型強相關(guān)，通常以業(yè)務(wù)請求消息統(tǒng)計的形式獲取對應(yīng)指標。PaaS實例SLI指標體系建設(shè)遵照VALET原則構(gòu)建五個維度的指標：-Volume(容量)：是指服務(wù)承諾的最大容量是多少，如數(shù)據(jù)庫連接數(shù)、容器集群可用節(jié)點數(shù)等。-Availablity(可用性)：代表服務(wù)是否正常，如實例主備狀態(tài)、實例可用副本數(shù)量等。-Latency(時延)：代表響應(yīng)是否足夠快，如分布

式數(shù)據(jù)庫的長事務(wù)、慢SQL執(zhí)行等指標。-Error(錯誤率)：代表執(zhí)行某一業(yè)務(wù)的錯誤率是多少，如分布式緩存高危命令、大Key使用等指標。-Ticket(工單)：代表某一功能是否需要人工介入，人工介入越多，可用性越差。容量可用性工單實例SLI指標容量可用性工單實例SLI指標延時錯誤率云服務(wù)（索引功能點功能平面VALET類別指標名稱指標單位指標周期監(jiān)控方式閾值規(guī)則重復(fù)次數(shù)影響說明DCSDCS實例可連接性數(shù)據(jù)面可用性DCS實例連接使用率%1分鐘服務(wù)監(jiān)控連接使用率大于90%查詢過去1分鐘內(nèi)為一個統(tǒng)計周期，至少3次檢測連接使用率達到95%。3上述指標表征DCS實例連接使用率情況，超過使用率可能導(dǎo)致實例新建連接失敗，可用性產(chǎn)生異常。DCSDCS實例可連接性數(shù)據(jù)面延時DCS實例命令時延毫秒1分鐘服務(wù)監(jiān)控查詢過去1分鐘內(nèi)為一個統(tǒng)計周期，每分鐘統(tǒng)計的最大時延超過10ms，連續(xù)三次上報告警。3實例命令時延過長，阻塞后續(xù)命令執(zhí)行，影響實例功能。DCSDCS實例可連接性數(shù)據(jù)面錯誤率DCS實例使用規(guī)范性布爾類型1分鐘告警查詢過去1分鐘內(nèi)為一個統(tǒng)計周期，存在高危命令、大Key使用的告警。需要考慮告警聚合策略。1高危命令、大Key使用可能影響實例可用性。圖2.7基礎(chǔ)設(shè)施可觀測IOPS類指標可通過公共能力統(tǒng)一提供。

綜上所述，構(gòu)建核心應(yīng)用的可觀測體系，應(yīng)該從業(yè)務(wù)應(yīng)用視角到云平臺資源視角進行分層設(shè)計。應(yīng)用視角主要包含終端層和應(yīng)用層，基于應(yīng)用的核心功能，由業(yè)務(wù)開發(fā)人員、運維人員、測試人員組成“鐵三角”共同設(shè)計。云平臺資源層主要包含PaaS層實例和IaaS層基礎(chǔ)設(shè)施，由云平臺提供開箱即用的標準SLI指標，應(yīng)用指標和資源指標匯聚接入到應(yīng)用可觀測平臺中，由應(yīng)用可觀測平臺統(tǒng)一對外呈現(xiàn)。終端體驗類指標應(yīng)用黃金指標應(yīng)用請求成功率應(yīng)用請求吞吐量端側(cè)體驗類撥測端側(cè)運行監(jiān)控端側(cè)可觀測終端體驗類指標應(yīng)用黃金指標應(yīng)用請求成功率應(yīng)用請求吞吐量端側(cè)體驗類撥測端側(cè)運行監(jiān)控端側(cè)可觀測日志指標事件應(yīng)用可觀測日志指標trace事件實例可觀測日志指標事件基礎(chǔ)設(shè)施可觀測日志指標事件終端應(yīng)用業(yè)務(wù)應(yīng)用視角APP移動端瀏覽器撥測云撥測運營數(shù)據(jù)業(yè)務(wù)數(shù)據(jù)JS錯誤異常分析用戶旅程業(yè)務(wù)應(yīng)用全局拓撲鏈路追蹤業(yè)務(wù)應(yīng)用全局拓撲鏈路追蹤代碼級診斷Profiling多語言接入云實例可用性指標實例可連接性實例讀寫時延實例狀態(tài)云服務(wù)實例容器集群可觀測云實例可用性指標實例可連接性實例讀寫時延實例狀態(tài)云服務(wù)實例容器集群可觀測中間件可觀測集群監(jiān)控Pod監(jiān)控RDS節(jié)點監(jiān)控網(wǎng)絡(luò)監(jiān)控緩存基礎(chǔ)設(shè)施指標CPU利用率內(nèi)存利用率網(wǎng)絡(luò)帶寬使用率存儲IO使用率資源池基礎(chǔ)設(shè)施指標CPU利用率內(nèi)存利用率網(wǎng)絡(luò)帶寬使用率存儲IO使用率資源池平臺資源視角管理虛擬機操作系統(tǒng)主機存儲網(wǎng)絡(luò)

應(yīng)用可觀測平臺

圖2.8四層指標體系極簡信息匯聚，一站式觸達運維態(tài)勢，提升運維體驗和故障處理效率如前所述，金融客戶在日常運維信息的獲取上，存在兩個關(guān)鍵痛點，一是運維體驗圍繞功能展開，對運維對象的操作需要在不同界面來回切換，體驗不暢；二是信息分散，比如描述狀態(tài)的告警指標信息、用于定位的日志和調(diào)用鏈信息、各類操作的狀態(tài)信息需要從不同的運維界面上獲取，導(dǎo)致故障處理效率低。因此需要持續(xù)構(gòu)建極簡信息獲取的能力，使運維人員可以快速獲取所需的運維態(tài)勢信息，從而提升運維體驗和故障處理效率，進而解決企業(yè)運維要求高和運維能力不足的矛盾。極簡信息獲取的設(shè)計理念信息集約：面向運維對象進行運維操作功能的體驗設(shè)計，例如，在同一個操作界面上集成運維對象的狀態(tài)信息、組件關(guān)聯(lián)、操作維護等信息。對象關(guān)聯(lián)：圍繞同一個運維對象，可向下關(guān)聯(lián)依賴的容器、物理設(shè)備等底層資源信息，向上關(guān)聯(lián)被依賴的應(yīng)用組件信息，從而快速獲取與該運維對象相關(guān)聯(lián)的運維信息。逐層下鉆：在呈現(xiàn)運維狀態(tài)信息時，界面應(yīng)圍繞運維對象關(guān)系，展示逐層下鉆的內(nèi)部組件和依賴資源相關(guān)的分析信息，以便逐步逼近問題根因。一致體驗：所有被管理對象都有一致的全景360視圖體驗，從一個關(guān)聯(lián)對象可以一鍵跳轉(zhuǎn)至其全景360監(jiān)控信息界面。極簡信息獲取的目標效果運維信息展示要能夠圍繞運維對象進行匯聚，使運維人員可以方便且快速獲取需要的運維信息。對象狀態(tài)一屏概覽：被管對象概覽界面，要能夠展示對象關(guān)鍵信息，包括基本信息、告警、關(guān)鍵指標等內(nèi)容。

監(jiān)控匯聚狀態(tài)可視：展現(xiàn)被管對象及內(nèi)部組件的告警信息。基于告警可以快速感知對象的異常狀態(tài)；此外，運維平臺還應(yīng)支持查看被管對象及內(nèi)部組件的指標信息。拓撲關(guān)聯(lián)故障定界：展現(xiàn)被管對象與內(nèi)部組件、底層部署依賴、周邊調(diào)用依賴等關(guān)系的拓撲圖，并在拓撲圖中展示各個對象的告警狀態(tài)。創(chuàng)建的拓撲應(yīng)包括應(yīng)用的物理拓撲、云服務(wù)物理拓撲、云服務(wù)部署拓撲等。通過對關(guān)聯(lián)對象的異常狀態(tài)分析，可以支撐運維人員進行故障定界。組件分析逐層下鉆：故障定界定位猶如抽絲剝繭，極簡運維要支持從故障表現(xiàn)的點開始，對齊內(nèi)部組件和依賴資源，逐步、逐層進行下鉆分析，一步步接近問題根因。操作維護快速直達：集成被管對象的常見操作，如自動作業(yè)、節(jié)點診斷、撥測等，在日常運維和故障處理時，能夠快速完成操作。實現(xiàn)確定性故障恢復(fù)確定性故障恢復(fù)需要從應(yīng)用系統(tǒng)視角和云平臺資源視角分別定義?；谠品?wù)故障模式基線庫，對云服務(wù)實例進行全面診斷，以便精確定位、快速恢復(fù)故障應(yīng)用可觀測平臺感知故障之后，通過指標的匯聚和算法處理，可以對故障進行初步的定界，輸出可能存在故障的資源實例，此時需要云平臺具備針對資源實例端到端的精確故障診斷和快速恢復(fù)能力。實現(xiàn)資源實例的診斷，需要大量的運維專家經(jīng)驗，從實例的資源、依賴、歷史故障模式等多個維度進行分析，因此，構(gòu)建云服務(wù)的故障模式庫至關(guān)重要。故障模式庫生成機制故障模式庫是在產(chǎn)品設(shè)計階段，對構(gòu)成產(chǎn)品的組件進確定分析對象建立框圖描述系統(tǒng)功能定義嚴酷等級故障模式清單確定分析對象建立框圖描述系統(tǒng)功能定義嚴酷等級故障模式清單白盒化的故障模式分析：端到端梳理組件架構(gòu)，根據(jù)組件在架構(gòu)中的位置，分析可能的故障點。梳理云服務(wù)核心功能，并和組件架構(gòu)有機結(jié)合，以實現(xiàn)對某一核心功能對應(yīng)故障點的可視化呈現(xiàn)。此外，還應(yīng)規(guī)劃對應(yīng)故障點的自動化診斷、一鍵式恢復(fù)能力。黑盒化的功能性撥測：包括關(guān)鍵進程和端口的探測、網(wǎng)絡(luò)組件交互性撥測、及AA集群流量負載均衡的診斷?，F(xiàn)網(wǎng)歷史故障補充：基于產(chǎn)品組件在現(xiàn)網(wǎng)中的歷史重大故障進行逆向覆蓋，確保重大質(zhì)量問題全覆蓋，改進措施對應(yīng)指標可診斷?？墒褂孟到y(tǒng)級FMEA(failuremodeandanalysis，失效模式及效應(yīng)分)故障模式分析流程持

FMEA分析FMEA分析圖2.9系統(tǒng)級FMEA故障模式分析流程續(xù)積累故障模式庫。故障模式庫的推廣機制梳理故障模式庫只是故障處理的一種手段，讓站點能夠基于故障模式庫快速診斷、恢復(fù)故障才是最終目的。因此基于故障模式庫中定義的每一種故障模式都需要開發(fā)對應(yīng)的內(nèi)容包，內(nèi)容包中應(yīng)至少包含一套診斷腳本和一套恢復(fù)腳本。故障模式內(nèi)容包應(yīng)該與產(chǎn)品解耦，既可以集成到產(chǎn)品中支持新建站點的開箱即用，又可以單獨發(fā)布支撐存量站點的持續(xù)迭代更新。針對一類服務(wù)的某個核心功能的故障模式庫梳理針對一類服務(wù)的某個核心功能的故障模式庫梳理產(chǎn)品對象故障模式描述云服務(wù)名稱核心功能點故障對象 故障模式故障影響嚴酷等級觀測方式應(yīng)急恢復(fù)措施分布式緩存Redis訪問Redis實例 實例狀態(tài)異常影響業(yè)務(wù)訪問RedisI類實例狀態(tài)異常告警實例重啟分布式緩存Redis訪問Redis節(jié)點 節(jié)點狀態(tài)異常影響業(yè)務(wù)訪問RedisI類實例節(jié)點異常告警實例節(jié)點重啟分布式緩存Redis訪問Redis實例 實例拒絕連接影響業(yè)務(wù)訪問RedisI類監(jiān)控實例活躍客戶端連接數(shù)超規(guī)格調(diào)整實例最大連接數(shù)故障模式適配包開發(fā)├─故障模式適配包開發(fā)├─resource_{云服務(wù)索引}_{version}.zip #故障適配包alarm ││├─{云服務(wù)索引}_alarm.json #告警靜態(tài)信息monitor script config.json {script} operations actions.json i18n autoops operations flows i18n 故障模式適配包推廣十統(tǒng)一適配包故障模式適配包推廣十統(tǒng)一適配包開箱即用新建站點運維治理包持續(xù)迭代存量站點故障模式內(nèi)容包故障模式庫運行機制狀態(tài)診斷腳本狀態(tài)診斷腳本狀態(tài)診斷腳本狀態(tài)診斷腳本狀態(tài)診斷腳本信息收集腳本信息收集腳本信息收集腳本局點運維人員快速恢復(fù)腳本快速恢復(fù)腳本快速恢復(fù)腳本XXX服務(wù)關(guān)系數(shù)據(jù)庫服務(wù)分布式緩存服務(wù)自動作業(yè)指標監(jiān)控告警監(jiān)控圖2.11故障模式庫運行機制自動作業(yè)指標監(jiān)控告警監(jiān)控圖2.12一鍵式故障診斷恢復(fù)示例云網(wǎng)一體化運維實現(xiàn)應(yīng)用、虛擬鏈路、物理路由的一致性監(jiān)控和運維云網(wǎng)一體化運維是指將云計算與網(wǎng)絡(luò)技術(shù)相結(jié)合，對云計算環(huán)境中的網(wǎng)絡(luò)資源進行統(tǒng)一管理和維護的一種模式。在這種模式下，網(wǎng)絡(luò)管理員可以通過云計算平臺提供的工具和接口，對網(wǎng)絡(luò)資源進行實時監(jiān)控、故障排查、性能優(yōu)化等操作。云網(wǎng)一體化運維的實現(xiàn)依賴于云平臺和網(wǎng)絡(luò)設(shè)備的協(xié)同工作，云平臺需要提供相應(yīng)的API接口，以便管理員可以訪問和操作網(wǎng)絡(luò)資源，同時網(wǎng)絡(luò)設(shè)備也需要支持相應(yīng)的功能，如網(wǎng)絡(luò)監(jiān)控、故障診斷、流量分析等，以實現(xiàn)對網(wǎng)絡(luò)資源的有效管理，從而實現(xiàn)云上Overlay資源與Underlay網(wǎng)絡(luò)設(shè)備的統(tǒng)一運維。云網(wǎng)一體化運維通過如下兩個機制實現(xiàn)高效監(jiān)控與問題定位：應(yīng)用網(wǎng)絡(luò)真實業(yè)務(wù)流一屏監(jiān)控：主要通過eBPF應(yīng)

心功能實現(xiàn)。虛擬&物理網(wǎng)絡(luò)可視診斷定界：主要通過Cloud-NetDebug虛擬網(wǎng)絡(luò)撥測和FabricInsight物理網(wǎng)絡(luò)定界兩大核心功能實現(xiàn)。（一）應(yīng)用網(wǎng)絡(luò)真實業(yè)務(wù)流一屏監(jiān)控1）eBPF應(yīng)用端點無損監(jiān)測eBPF是一種在Linux內(nèi)核中運行的虛擬機，它允許用戶在不修改內(nèi)核源代碼的情況下，動態(tài)地加載和執(zhí)行代碼。eBPF最初是為了網(wǎng)絡(luò)數(shù)據(jù)包過濾而設(shè)計，已擴展到其他領(lǐng)域，如安全、跟蹤和性能分析。eBPF試和排查。具體的實現(xiàn)機制是：eBPF注入到應(yīng)用內(nèi)核中并掛載到特定鉤子(hook)掛載點上。當內(nèi)核或應(yīng)用程序執(zhí)行到某個掛載點時，產(chǎn)生特定事件并觸發(fā)程序運行。eBPF技術(shù)的代碼無侵入、語言無關(guān)、高性能、強關(guān)聯(lián)、數(shù)據(jù)端到端覆蓋等特征，可滿足可觀測性標準和觀測數(shù)據(jù)采集的要求。BPFBPFProgramReaderLLVM/ClangLLVM/ClangProg.bfp Userspacebpf KernelbpfeBPFBPFMapsBPFBytecodeKernelFunctionsNativeCodeVerifier+JIT圖2.13eBPF掛載原理

基于eBPF內(nèi)核觀測技術(shù)生成的網(wǎng)絡(luò)級丟包、時延、吞吐量等方面指標，可以實現(xiàn)流級的應(yīng)用路況可視化監(jiān)控能力。應(yīng)用訪問拓撲可視：訪問關(guān)系圖、訪問量、訪問時間應(yīng)用網(wǎng)絡(luò)質(zhì)量可視：重傳、擁塞、0窗口2）iFIT真實業(yè)務(wù)流鏈路監(jiān)測IFIT(In-situFlowInformationTelemetry)是一種用于網(wǎng)絡(luò)流量監(jiān)控和分析的技術(shù)，可以實時收集網(wǎng)絡(luò)中數(shù)據(jù)包的元數(shù)據(jù)信息，如源地址、目的地址、協(xié)議類型、源端口、目的端口等，及數(shù)據(jù)包的時間戳。通過分析這些元數(shù)據(jù)信息，可以了解網(wǎng)絡(luò)中流量的實時情況，識別流量模式和趨勢，檢測異常流量和故障，從而實現(xiàn)網(wǎng)絡(luò)的智能運維。iFIT主要基于在被檢測業(yè)務(wù)流報文中添加iFIT檢測頭，實現(xiàn)隨流的業(yè)務(wù)質(zhì)量檢測，反映業(yè)務(wù)流的真實業(yè)務(wù)質(zhì)量。R1(Source)

1588v2/G8275.1

R2(Destination)00110011111000000T:染色周期

Tx[i]

Rx[i+1] Rx[i]110000 1 1 1 0 10000 1每周期統(tǒng)計點后移，屏蔽亂序干擾：T+6T/10，后移6T/10時點流性能測量)染色機制，iFIT染色報文帶內(nèi)測量技術(shù)可以構(gòu)建流級的網(wǎng)絡(luò)路況追蹤和診斷能力，實現(xiàn)基于包粒度的真實業(yè)務(wù)流全鏈路檢測。這項技術(shù)具有以下幾方面特點：支持多種業(yè)務(wù)場景：L3VPN/EVPN/SRv6/SR-MPLS/MPLS易部署運維：頭節(jié)點按需定制，中間/尾節(jié)點一次

部署，自動按需E2E/逐跳檢測丟包位置：基于每節(jié)點的報文計數(shù)，分析丟包點逐跳時延/抖動：基于每節(jié)點的時戳記錄，分析鏈路/節(jié)點時延路徑還原：基于每節(jié)點上報信息，呈現(xiàn)業(yè)務(wù)真實路徑圖2.15iFIT業(yè)務(wù)流監(jiān)測實例如圖所示，實例中實現(xiàn)了網(wǎng)絡(luò)丟包、時延、抖動、帶寬等真實業(yè)務(wù)流路徑的可視監(jiān)控。（二）&物理網(wǎng)絡(luò)可視診斷定界1）CloudNetDebugCloudNetDebug是面向運維人員的虛擬網(wǎng)絡(luò)診斷工具，幫助網(wǎng)絡(luò)管理員和開發(fā)人員快速診斷和解決云網(wǎng)絡(luò)中的問題。通過收集和分析云網(wǎng)絡(luò)中的數(shù)據(jù)包、流量和性能指標等信息，提供全面的視圖，使用戶能夠快速定位和解決網(wǎng)絡(luò)問題，包括數(shù)據(jù)包捕獲、流量分析、集成撥測和抓包、性能監(jiān)測和故障排查等。通過客戶報文模擬撥測，應(yīng)用報文抓取等方式，實現(xiàn)可視化撥測快速診斷定界。正常周期撥測---覆蓋所有鏈路正常周期撥測---覆蓋所有鏈路CNA1vRouter1①CNA2 交換機1 vRouter2 交換機3 ··· ··· ··· ··· ···BMSGW1交換機2ENAT1交換機4BMSGW2預(yù)置探針ENAT2出現(xiàn)故障場景---自動匯聚告警CNA1vRouter1②CNA2···交換機1vRouter2···交換機3······BMSGW1交換機2ENAT1交換機4BMSGW2預(yù)置探針ENAT2···圖2.16CloudNetDebug撥測原理軟件撥測定位是利用染色標記技術(shù)主動撥測抓包，通過跟蹤染色報文經(jīng)過的路徑，覆蓋資源(IP)>虛擬交換網(wǎng)絡(luò)>物理交換網(wǎng)絡(luò)進行全景網(wǎng)絡(luò)拓撲的可視化撥測診斷。實際應(yīng)用中，有如下兩種監(jiān)控診斷模式：FullLink全鏈路診斷：進行全鏈路復(fù)雜流量疊加場景的網(wǎng)絡(luò)問題定位。通過控制面診斷租戶的云服務(wù)配置、路由表、安全組和網(wǎng)絡(luò)ACL等配置，檢測每個網(wǎng)元的時延和丟包率實現(xiàn)虛擬網(wǎng)絡(luò)診斷。

物理網(wǎng)絡(luò)診斷通過調(diào)用FabricInsight的接口獲取業(yè)務(wù)流路徑指標，包括流狀態(tài)以及交換機異常信2）FabricInsight物理網(wǎng)絡(luò)定界FabricInsight是一種用于物理網(wǎng)絡(luò)分析和監(jiān)控的工具。這個工具支持實時監(jiān)控和警報，幫助用戶快速發(fā)現(xiàn)和解決問題，更好地理解和管理他們的網(wǎng)絡(luò)鏈路系統(tǒng)，還提供了豐富的分析功能，幫助用戶深入了解網(wǎng)絡(luò)的性能和行為，并識別潛在的瓶頸和優(yōu)化機會。此外，F(xiàn)abricInsight工具還支持多種物理設(shè)備組網(wǎng)的管理、控制和分析，支持網(wǎng)絡(luò)仿真校驗及虛擬感知，支持NetConf，OpenFlow，OVSDB，SNMP等協(xié)議，從而實現(xiàn)物理和虛擬網(wǎng)絡(luò)設(shè)備的可視化管理。網(wǎng)絡(luò)路徑網(wǎng)絡(luò)路徑設(shè)備KPI故障風險TCPSYN/FIN/RST報文采集丟包/時延變更檢測逐跳真實路徑還原網(wǎng)絡(luò)路況分析TCP連通性分析關(guān)聯(lián)逐跳故障分析VMVMVMVMVMVMVMVMVMVM逐跳配置變更檢測VMVMVM自動輸出故障定位結(jié)論圖2.17FabricInsight物理網(wǎng)絡(luò)故障定界硬件診斷定位是通過業(yè)務(wù)物理路徑指標，包括流狀態(tài)以及交換機設(shè)備故障、鏈路故障、轉(zhuǎn)發(fā)過載等，實現(xiàn)業(yè)務(wù)流路徑物理網(wǎng)絡(luò)端到端路徑的可視及異常定位。Fabric內(nèi)業(yè)務(wù)流路徑可視：通過關(guān)聯(lián)分析逐跳設(shè)備信息感知故障斷點，故障一鍵式診斷，定位網(wǎng)絡(luò)路由、策略類故障根因。質(zhì)差主動發(fā)現(xiàn)：基于網(wǎng)絡(luò)路況開放，實現(xiàn)應(yīng)用網(wǎng)絡(luò)協(xié)同，通過技術(shù)分析微突發(fā)、丟包、光模塊異常等現(xiàn)象快速定界定位問題。預(yù)見性風險治理預(yù)見性風險治理是一種前瞻性的風險管理方法，旨在通過事前的預(yù)測和診斷識別潛在風險，提前制定風險消減措施，保障系統(tǒng)的穩(wěn)定運行。根據(jù)風險場景，預(yù)見性風險治理主要分為運行態(tài)風險預(yù)防，變更風險控制和未知風險挖掘三部分內(nèi)容。運行態(tài)風險預(yù)防：建立完善的運行態(tài)風險主動預(yù)防體系，定期進行風險評估和監(jiān)測。通過收集和

分析指標、日志、告警、配置、容量等運維數(shù)據(jù)，從風險隱患、性能規(guī)格、系統(tǒng)容量、系統(tǒng)可靠性、最佳實踐、版本生命周期、安全漏洞等多個維度對系統(tǒng)進行全面的評估。變更風險控制：通過建立變更前的風險識別和評審機制，提前識別變更的潛在風險；通過自動化及漸進式的變更過程，確保變更不引入風險。未知風險挖掘：通過混沌工程識別系統(tǒng)的薄弱環(huán)節(jié)并改進，持續(xù)提升系統(tǒng)韌性。變“被動救火”為主動預(yù)防，構(gòu)建運行態(tài)風險主動預(yù)防體系面向未來，“被動救火”式運維將成為過去式，主動運維將成為保障系統(tǒng)高可用的重要手段《史記》曾載，魏文侯問扁鵲“你們?nèi)值苷l的醫(yī)術(shù)最為高明？”扁鵲言“長兄最善，中兄次之，扁鵲為下。”文侯好奇道“何出此言？”扁鵲答“大哥治病，常以望聞問切，診斷隱患，在病害形成之前就能鏟除病因，因此一般人不知道大哥的厲害，是以聲名不顯。二哥治病于初起之時，大家以為他只能看看小病，所以他只聞名于鄉(xiāng)里。而我治病于嚴重之時，用針刺猛藥，救人于危機之時，所以大家都以為我醫(yī)術(shù)最高明，因此名傳天下。上工治未病，扁鵲長兄治病于未發(fā)，是為事前；中兄治病于漸發(fā)，是為事中；扁鵲治病于嚴重，是為事后。治病如此，運維亦是如此。運維的核心目標是保障業(yè)務(wù)可用，減少和避免故障發(fā)生。傳統(tǒng)的救火式運維，運維人員的工作內(nèi)容和工作重心往往聚焦在事件和故障處理，偏向事后，這種運維方式無異于減少和避免故障，無法滿足現(xiàn)代化云運維的要求。從故障事前、事中和事后的角度看，事后恢復(fù)不如事中控制，事中控制不如事前預(yù)防。因此，必須摒棄傳統(tǒng)的救火式運維，變被動為主動，預(yù)防和減少故障發(fā)生，防患于未然。建設(shè)金融云風險主動預(yù)防體系，實現(xiàn)站點故障早發(fā)現(xiàn)主動運維并不是一個新鮮的概念，但在大部分的企業(yè)中，主動運維仍是一句口號，對于一個云平臺，如何能讓主動運維真正落地并產(chǎn)生效果？本質(zhì)上來講，主動運維的目的在于事前預(yù)防，治病于未發(fā)是關(guān)鍵，因此需要重點構(gòu)建事前的風險識別和預(yù)防能力。1986年，美國挑戰(zhàn)者號航天飛機發(fā)射后發(fā)生爆炸，事故造成7名宇航員喪生，發(fā)射活動以失敗告終。為了實現(xiàn)故障先預(yù)警，隱患早發(fā)現(xiàn)，NASA建立了航天器故障預(yù)防診斷平臺，旨在提前通過診斷檢查發(fā)現(xiàn)異常事件，保障航天器可靠運行，避免事故發(fā)生。對于云平臺這種大型的分布式軟件系統(tǒng)來說，建立風險檢測預(yù)防機制同樣是重中之重。傳統(tǒng)IT系統(tǒng)的風險主動預(yù)防通常會以產(chǎn)品化的方式發(fā)布巡檢工具，通過在現(xiàn)網(wǎng)部署巡檢工具進行巡檢來識別風險，這種方式受限于工具的發(fā)布節(jié)奏，風險無法實時更新，無法保證現(xiàn)網(wǎng)時刻都可以應(yīng)用到最新的風險庫。

金融云風險主動預(yù)防機制的核心思想是通過構(gòu)筑中心化的風險庫，從風險規(guī)則的生成、風險診斷到風險的預(yù)警推送，構(gòu)筑服務(wù)化的風險主動預(yù)防能力。實施層面可按如下思路展開建設(shè)：構(gòu)建中心化風險庫構(gòu)建中心化風險庫的目的在于將風險集中管理，防止風險管理的無序和散亂。風險庫的建設(shè)需遵循全面性、實時性和持續(xù)性原則。全面性：風險庫需要涵蓋明確的風險類型和范圍，如產(chǎn)品缺陷、性能過載、組網(wǎng)非標、配置隱患、版本配套、硬件適配、安全漏洞等，確保風險范圍覆蓋全面，防止遺漏。實時性：風險動態(tài)實時更新，即風險從發(fā)現(xiàn)到入庫的時效性需要得到保證，確?，F(xiàn)網(wǎng)應(yīng)用的風險庫時刻保持最新。持續(xù)性：制定明確的風險庫管理制度，包括風險庫的更新和維護機制，確保風險庫的有效運行和持續(xù)更新。建立風險評估機制風險評估機制是通過收集和分析信息數(shù)據(jù)，結(jié)合風險庫規(guī)則來識別風險隱患的過程，其目的是為了有效地識別系統(tǒng)風險。風險評估機制的主要步驟包括：信息收集：收集生產(chǎn)環(huán)境的指標、日志、告警、配置、資源、容量等運維數(shù)據(jù)，作為風險診斷分析的數(shù)據(jù)輸入。診斷分析：對收集的運維數(shù)據(jù)進行分析診斷，識別系統(tǒng)劣化指標，匹配風險庫規(guī)則進行風險冒泡，評估風險等級及影響，輸出健康度評估報告。26建立風險預(yù)警流程26建立完善的風險預(yù)警機制，通過定期的風險評估報告方式將風險預(yù)警推送到現(xiàn)網(wǎng)，確保風險信息可以及時準確地傳遞給相關(guān)組織。同時，提供相應(yīng)的風險規(guī)避措施，持續(xù)跟蹤風險在現(xiàn)網(wǎng)的閉環(huán)情況?；谧兏Ｐ吞崆皵r截變更態(tài)風險，通過全流程自動化實現(xiàn)變更態(tài)風險有效控制變更風險控制是系統(tǒng)變更過程中至關(guān)重要的一環(huán)，旨在減少因系統(tǒng)變更而帶來的不利影響，提高變更的成功率。隨著業(yè)務(wù)數(shù)量和業(yè)務(wù)規(guī)模的持續(xù)擴大，現(xiàn)網(wǎng)的變更數(shù)量和變更頻次不斷增長，而頻繁的變更常常會給運維帶來不可預(yù)知的風險。據(jù)數(shù)據(jù)統(tǒng)計，70%的線上故障都是由變更引起，變更可能引起功能失效、性能下降、數(shù)據(jù)丟失甚至系統(tǒng)崩潰。如何有效管控變更風險，是運維工作面臨的巨大挑戰(zhàn)。面向現(xiàn)代化的變更風險控制能力構(gòu)建可按下面思路進行考量：控制能力

變更前變更準入：建立變更準入機制，在變更申請階段對變更的準入條件進行控制，包括變更必要性評估，標準化變更方案制定，變更影響分析，回退方案、變更授權(quán)等；風險識別：變更前對變更風險進行識別，包括變更歷史問題風險、變更方案風險、業(yè)務(wù)影響風險、高危操作風險等；變更評審：變更評審階段，由評審人對變更方案和變更風險進行評審，確保變更實施方案正確，變更影響和變更風險評估準確。變更中灰度變更：構(gòu)筑變更實施階段的灰度變更能力，按需控制變更范圍，可以盡早發(fā)現(xiàn)并解決變更問題，有效降低變更帶來的風險；風險控制：在變更實施過程中控制變更操作的風險。對于高危操作、未授權(quán)操作實施攔截，對于變更過程中的異常和非預(yù)期結(jié)果，應(yīng)實施變更自動終止操作。標和告警，快速發(fā)現(xiàn)變更帶來的非預(yù)期影響。變更后退以及按階段、按工步的局部回退，支持靈活的回退策略制定；后通過業(yè)務(wù)撥測驗證變更業(yè)務(wù)是否可用，及時發(fā)現(xiàn)問題。更風險提前識別首先，對不同類型的變更建立不同的變更模型，并對變更模型設(shè)定相應(yīng)的風險規(guī)則，風險規(guī)則可來源于此類型變更的歷史問題和專家經(jīng)驗，或與此類變更相關(guān)的狀態(tài)、指標和配置等。此外，應(yīng)建立變更模型和風險規(guī)則的關(guān)聯(lián)機制，持續(xù)積累風險規(guī)則，通過工具能力自動識別風險，使得風險識別不依賴人，基于變更模型建立標準化的風險識別流程和能力，確保變更前風險有效識別。險控制有效落地流程具體來說，應(yīng)建立數(shù)字化的變更流程系統(tǒng)，從變更申請、變更評審、變更實施到變更驗證建立完善的變更流程

流程，使得變更在各個階段都能得到有效的跟蹤和控制。變更申請階段，基于變更模型創(chuàng)建變更申請單，變更申請單自動獲取變更模型關(guān)聯(lián)的風險規(guī)則，同時根據(jù)風險規(guī)則識別變更風險。風險規(guī)則可以是特定的匹配規(guī)則或腳本，通過自動化流程運行風險規(guī)則或腳本，給出本變更所識別出的風險集合。變更評審階段，對于變更單所識別變更風險的閉環(huán)情況進行審核，確保變更風險全部閉環(huán)，變更流程才能進入變更實施階段。在變更申請和變更評審階段，重點構(gòu)筑變更風險的識別和攔截能力。變更實施階段，基于工具構(gòu)筑自動化變更及控制能力。工具應(yīng)具備作業(yè)編排、灰度分批、高危攔截、熔斷回退等核心功能?；叶确峙兏湫偷膽?yīng)用形式通常如下：產(chǎn)環(huán)境實施前，在灰度環(huán)境上提前實施變更，進行業(yè)務(wù)驗證；生產(chǎn)環(huán)境分批實施：在生產(chǎn)環(huán)境中分批實施變更，優(yōu)先選擇小范圍、重要性較低或影響可控對象實施變更，根據(jù)變更結(jié)果逐步放開批次。推送、閉環(huán)執(zhí)行腳本/規(guī)則變更實施風險評審?fù)扑汀㈤]環(huán)執(zhí)行腳本/規(guī)則變更實施風險評審識別風險創(chuàng)建變更單拉取風險信息導(dǎo)入變更模型風險腳本/規(guī)則模型變更作業(yè)流水線變更作業(yè)流水線變更作業(yè)子流程N變更作業(yè)子流程N+1安全回滾灰度批批次1生產(chǎn)批批次2生產(chǎn)批批次2準入條件預(yù)檢查準入條件預(yù)檢查灰度批批次1安全回滾安全回滾工具能力工具能力模板編排灰度分批高危攔截熔斷機制安全回滾生產(chǎn)驗證圖2.19典型灰度分批變更應(yīng)用形式變更驗證階段，通過功能驗證、業(yè)務(wù)撥測等驗證手段，對變更后的業(yè)務(wù)進行可用性驗證，及時發(fā)現(xiàn)可能的風險。持續(xù)提升系統(tǒng)韌性混沌工程核心思想：識別系統(tǒng)隱患，減少故障影響，提升系統(tǒng)韌性

從系統(tǒng)架構(gòu)層面，混沌工程可以驗證系統(tǒng)的容錯能力，推動提升系統(tǒng)的架構(gòu)可用性；測試層面，混沌工程可以提前暴露線上問題，防止帶病上線；運維層面，混沌工程可以讓我們更好地理解和掌握系統(tǒng)的運行邏輯和規(guī)律，提升應(yīng)急恢復(fù)效率，降低故障影響和損失，增強團隊應(yīng)急能力，建立系統(tǒng)抵御未知風險的信心。混沌工程的實施實踐混沌工程實踐可以按照如下步驟開展：制定試驗?zāi)繕碎_展混沌演練之前，首先需要明確試驗?zāi)繕思凹僭O(shè)，確保實驗的有效性及針對性。例如，驗證某應(yīng)用系統(tǒng)在過載場景下的保護機制，假設(shè)當流量過載時，系統(tǒng)的哪些指標會發(fā)生什么變化，預(yù)期會有什么保護措施會觸發(fā)等。故障模式分析故障模式分析是混沌工程實踐的關(guān)鍵環(huán)節(jié)，通過6維故障分析法，從冗余、容災(zāi)、備份、過載、依賴和安全的場景輸入。云平臺故障場景識別xx會議系統(tǒng)故障場景識別lvs冗余云平臺故障場景識別xx會議系統(tǒng)故障場景識別lvs冗余視頻網(wǎng)關(guān)APIGnginx故障點consoleframe容災(zāi)安全前端負載均衡故障點6維故障分析法故障點視頻前端web01 視頻前端web02haproxyhaproxy依賴備份視頻后端service 視頻后端service故障點pub-dbpub-db過載故障點視頻數(shù)據(jù)庫DBimsapicomvpcims故障場景分析故障場景分析如圖所示，6維故障分析法對于云平臺和業(yè)務(wù)應(yīng)用場景的故障模式分析均適用。例如，對于應(yīng)用系統(tǒng)中的關(guān)鍵模塊，如web前端，在業(yè)務(wù)過載場景下，分析系統(tǒng)是否具備限流、降級或彈性擴容能力；對于數(shù)據(jù)庫，在業(yè)務(wù)過載場景下，分析系統(tǒng)是否具備自我保護能力等條件。制定應(yīng)急預(yù)案根據(jù)故障場景，分析故障發(fā)生后的系統(tǒng)行為及影響，制定對應(yīng)的應(yīng)急預(yù)案。應(yīng)急預(yù)案應(yīng)包括故障的識別、影響范圍確認、故障隔離、恢復(fù)驗證等方面。故障演練根據(jù)故障場景實施故障注入，觀察系統(tǒng)的行為是否符合預(yù)期，例如穩(wěn)態(tài)指標觀察，容錯行為驗證等，同時驗證處置策略，恢復(fù)手段是否有效。

演練復(fù)盤進行演練復(fù)盤總結(jié)，從產(chǎn)品質(zhì)量、預(yù)案質(zhì)量和運作流程等方面識別改進點并優(yōu)化?；煦绻こ唐脚_構(gòu)建混沌工程平是進行混沌演練的基礎(chǔ)，完整的混沌工程平臺需要具備故障模式管理、故障場景編排、故障注入、演練指揮、演練復(fù)盤等能力：故障模式管理提供豐富的故障模式庫，如過載類故障、網(wǎng)絡(luò)類故障、狀態(tài)變化類故障等，基于故障模式可以構(gòu)造業(yè)務(wù)故障場景。過載類故障包括磁盤IO高，CPU負載高，內(nèi)存利用率高，網(wǎng)卡流量高等。網(wǎng)絡(luò)類故障典型如網(wǎng)絡(luò)丟包、網(wǎng)絡(luò)時延、網(wǎng)絡(luò)中斷、網(wǎng)絡(luò)錯報、亂序、重復(fù)包等。狀態(tài)變化類故障有kill進程、關(guān)機、重啟、磁盤只讀、停止服務(wù)等。故障場景編排基于故障模式和資源對象，進行故障場景的靈活編排。故障注入基于故障模式或故障場景，對資源對象進行故障注入，為系統(tǒng)引入錯誤行為。由于云上資源的多樣性，故障注入需要支持各種類型的資源，包括主機、虛機、容器、數(shù)據(jù)庫、中間件、進程等。演練指揮設(shè)置演練指揮中心，制定演練計劃，演練排班和應(yīng)急預(yù)案，演練過程全程監(jiān)控。演練復(fù)盤分析演練數(shù)據(jù)，對演練過程進行復(fù)盤總結(jié)，輸出演練報告，發(fā)掘改進環(huán)節(jié)并持續(xù)跟蹤。演練文化混沌工程要在企業(yè)內(nèi)部有效落地，首先需要認可其所帶來的價值，從組織、流程、文化建設(shè)方面引導(dǎo)，從上到下建立混沌演練文化。只有持續(xù)例行地開展演練工作，才能持續(xù)提升系統(tǒng)的容錯性和可恢復(fù)性，系統(tǒng)的韌性才能得到不斷提升。

應(yīng)用運維現(xiàn)代化靠性來源于運維與設(shè)計的融合隨著核心業(yè)務(wù)持續(xù)上云，金融企業(yè)對應(yīng)用高可用要求達到了5個9。業(yè)務(wù)一旦出現(xiàn)故障不但會影響經(jīng)濟效益，甚至會影響到國計民生，所以如何縮小應(yīng)用故障的影響范圍，保障核心業(yè)務(wù)數(shù)據(jù)不丟失就成了企業(yè)面臨的頭等問題。因此，應(yīng)用高可用設(shè)計成為應(yīng)用與基礎(chǔ)設(shè)施現(xiàn)代化轉(zhuǎn)型的關(guān)鍵。然而，單純依靠傳統(tǒng)的運維方式已經(jīng)難以保障業(yè)務(wù)的高可靠要求，運維需要前置到設(shè)計階段，業(yè)務(wù)可靠性來源于運維與設(shè)計的融合。業(yè)務(wù)容災(zāi)等級評估高可用設(shè)計并非單純的技術(shù)問題，成本也是影響鍵。由于高可用設(shè)計需要大量的費用投入，而其產(chǎn)出并不能立竿見影地被直接感知到，所以對于高可用設(shè)計往往需要先解決“高可用設(shè)計成本與業(yè)務(wù)預(yù)期的沖突”問題。在投入成本方面，應(yīng)用可用性要求越高，對應(yīng)技術(shù)方案需要投入的成本也會越高。成本數(shù)據(jù)丟失損失成本數(shù)據(jù)丟失損失成本數(shù)據(jù)可靠性成本應(yīng)用可靠性成本應(yīng)用宕機損失成本業(yè)務(wù)側(cè)期望業(yè)務(wù)側(cè)期望當前現(xiàn)狀平衡點當前現(xiàn)狀數(shù)據(jù)丟失時長(RPO) 應(yīng)用恢復(fù)時間(RTO)分鐘 0 分普通業(yè)務(wù) 重要業(yè)務(wù) 關(guān)鍵業(yè)務(wù) 重要業(yè)務(wù) 普通業(yè)務(wù)圖2.21高可用設(shè)計與業(yè)務(wù)沖突預(yù)期沖突分析如圖所示：當RPO和RTO都為0時，對應(yīng)的高可用設(shè)計成本達到峰值；相反RPO和RTO時間比較高時，對應(yīng)的高可用成本也會相應(yīng)降低。如果所有業(yè)務(wù)都按照最高的高可用目標建設(shè)，金融企業(yè)將面臨巨大的高可用投入成本，所以在技術(shù)設(shè)計前，首先要對業(yè)務(wù)災(zāi)備等級進行評估分類?；趹?yīng)用的重要程度，數(shù)據(jù)一致性要求，時延敏感性等因素可以將業(yè)務(wù)劃分為“關(guān)鍵業(yè)務(wù)”、“重要業(yè)務(wù)”和“普通業(yè)務(wù)”三個等級，重要程度依次降低。業(yè)務(wù)容災(zāi)策略不同重要程度的業(yè)務(wù)選擇不同的容災(zāi)策略：關(guān)鍵業(yè)務(wù)的高可用設(shè)計原則是通過應(yīng)用架構(gòu)改造+部署架構(gòu)改造，實現(xiàn)數(shù)據(jù)0丟失，同城多活，異地容災(zāi)，并縮小故障爆炸半徑；重要業(yè)務(wù)則需通過調(diào)整應(yīng)用的部署架構(gòu)（無需調(diào)整應(yīng)用架構(gòu)），實現(xiàn)數(shù)據(jù)丟失趨于0，同城主備，異地容災(zāi)；普通業(yè)務(wù)無需對應(yīng)用和部署架構(gòu)作任何調(diào)整，僅需進行關(guān)鍵數(shù)據(jù)的定時備份即可。高可用的持續(xù)治理應(yīng)用高可用的保障過程是一個持續(xù)的治理過程。在經(jīng)歷了前期的技術(shù)選型、方案設(shè)計、方案實施和方案驗證后，還需建立完善的容災(zāi)管理制度，并通過專業(yè)的高可用技術(shù)團隊持續(xù)跟蹤和優(yōu)化業(yè)務(wù)高可用的達成情況。所以應(yīng)用高可用治理還涉及容災(zāi)團隊建設(shè)、容災(zāi)狀態(tài)監(jiān)控、容災(zāi)演練以及知識管理等一系列工作，才能真正保障應(yīng)用高可用目標的達成。管理體系，實現(xiàn)業(yè)務(wù)故障實時感知定界

端邊縱向可觀測體系設(shè)計端邊縱向可觀測體系設(shè)計端側(cè)監(jiān)控傳輸指標三方服務(wù)業(yè)務(wù)指標體系搭建請求量時延業(yè)務(wù)指標體系搭建請求量時延吞吐運維數(shù)倉匯聚運維數(shù)據(jù)日志配置告警圖2.22典型運維數(shù)據(jù)治理流程進于一體的開箱即用的可觀測性平臺至關(guān)重要。運維數(shù)倉匯聚運維數(shù)據(jù)應(yīng)用運行過程中會產(chǎn)生大量的運維數(shù)據(jù)，包括端側(cè)數(shù)據(jù)、撥測網(wǎng)絡(luò)數(shù)據(jù)、實例指標數(shù)據(jù)(Metrics)、日志數(shù)據(jù)(Logs)、調(diào)用鏈數(shù)據(jù)(Traces)等。這些運維數(shù)據(jù)需要一個統(tǒng)一的運維數(shù)據(jù)倉庫進行承載。運維數(shù)倉主要由數(shù)據(jù)集成、ETL、數(shù)據(jù)湖、MPPDB、數(shù)據(jù)應(yīng)用等功能組件構(gòu)成，典型數(shù)據(jù)處理流程如下：接入，如消息隊列、API集成、SFTP集成等。數(shù)據(jù)抽?。簲?shù)據(jù)接入之后由ETL對單條數(shù)據(jù)進行過濾、切分、擴展、格式化等操作，統(tǒng)一放到消息隊列中。數(shù)據(jù)湖處理：不同的數(shù)據(jù)主體消費消息隊列中的數(shù)據(jù)，完成不同的數(shù)據(jù)存儲，如原始日志或者指標存放到OBS中、單條粒度數(shù)據(jù)直接入庫或者通過格式定義存放到ClickHouse中、時序多維度量數(shù)據(jù)需要依據(jù)一定的數(shù)據(jù)治理規(guī)則分多個表保存在MPPDB中。數(shù)據(jù)應(yīng)用：所有運維數(shù)據(jù)治理完成之后，由數(shù)據(jù)應(yīng)用對數(shù)據(jù)進行API封裝，提供對外統(tǒng)一查詢接口。運維數(shù)倉數(shù)據(jù)應(yīng)用數(shù)據(jù)倉庫運維數(shù)倉數(shù)據(jù)應(yīng)用數(shù)據(jù)倉庫數(shù)據(jù)湖ETL數(shù)據(jù)集成UniQueryServer單條粒度運維數(shù)據(jù)[ClickHouse]時序多維度量數(shù)據(jù)離線數(shù)據(jù)分析單條粒度運維數(shù)據(jù)后端數(shù)據(jù)訂閱分發(fā)[Kafka]日志原始文件[HDFS/OBS]單條數(shù)據(jù)過濾、切分、擴展、格式化[SparkStreaming/Flink]數(shù)據(jù)集成接入[Kafka/SFTP/HTTPS]端側(cè)數(shù)據(jù)采集端側(cè)數(shù)據(jù)采集APMS撥測服務(wù)EchoTest指標監(jiān)控系統(tǒng)Prometheus日志服務(wù)LogService調(diào)用鏈服務(wù)NuwaTrace自定義數(shù)據(jù)圖2.23應(yīng)用運維數(shù)倉典型架構(gòu)業(yè)務(wù)指標體系搭建業(yè)務(wù)可觀測性指標是指在企業(yè)的業(yè)務(wù)層面上，通過監(jiān)測、分析和理解數(shù)據(jù)，設(shè)計出來的用以表征業(yè)務(wù)運行情況、用戶體驗的業(yè)務(wù)指標。業(yè)務(wù)可觀測性更加關(guān)注運行過程、用戶旅程和客戶交互等方面的可視化，從而幫助企業(yè)更好地理解業(yè)務(wù)的健康狀況，給最終用戶提供更好的用戶體驗。業(yè)務(wù)可觀測性指標梳理參與角色設(shè)計可觀測性指標的前提是對業(yè)務(wù)系統(tǒng)功能有非常深入的理解，因此應(yīng)用開發(fā)人員、測試人員、運維人員組成的“鐵三角”缺一不可。開發(fā)人員可以對系統(tǒng)功能的實現(xiàn)邏輯進行白盒化剖析，通過監(jiān)控和日志手段在開發(fā)階段預(yù)埋相應(yīng)的指標；測試人員更多從用戶體驗視角設(shè)計相應(yīng)的測試用

例，針對這些測試用例梳理黑盒化指標，如撥測類指標、規(guī)格類指標等；運維人員則根據(jù)運維過程中的問題持續(xù)對指標進行優(yōu)化，三者相互配合，構(gòu)建完備的業(yè)務(wù)可觀測指標。業(yè)務(wù)可觀測性指標設(shè)計步驟通常情況下，業(yè)務(wù)可觀測指標體系搭建主要分成如下四個步驟：數(shù)據(jù)調(diào)研，分解業(yè)務(wù)要素指標設(shè)計人員將業(yè)務(wù)系統(tǒng)的功能進行拆解，梳理出業(yè)務(wù)核心功能點，每個功能點會產(chǎn)生的數(shù)據(jù)類型（結(jié)構(gòu)化數(shù)據(jù)、日志、指標等），以及明確這些數(shù)據(jù)的作用。梳理概念模型，構(gòu)建總線矩陣每個核心功能點識別之后，就需要開發(fā)人員對每個核心功能點的業(yè)務(wù)過程進行白盒化梳理，包括每個業(yè)務(wù)過程需要關(guān)注的數(shù)據(jù)維度，以及每個維度對應(yīng)的字段。以互聯(lián)網(wǎng)應(yīng)用“設(shè)備登錄”業(yè)務(wù)過程為例，應(yīng)用需要獲取設(shè)備類型、設(shè)備品牌、登錄地域、登錄運營商、HTTP響應(yīng)狀態(tài)碼、業(yè)務(wù)響應(yīng)狀態(tài)碼等維度的數(shù)據(jù)。業(yè)務(wù)過程一級設(shè)備注冊業(yè)務(wù)過程二級北向設(shè)備注冊一致性維度請求來源Apple設(shè)備類型Devtype品類ProductID地理區(qū)域運營商http響應(yīng)碼業(yè)務(wù)響應(yīng)碼南向直連設(shè)備注冊南向下掛設(shè)備注冊南向批量下掛注冊設(shè)備登陸南向設(shè)備登陸設(shè)備數(shù)據(jù)上報北向藍牙設(shè)備數(shù)據(jù)上報北向三方設(shè)備數(shù)據(jù)上報南向設(shè)備數(shù)據(jù)上報設(shè)備查詢設(shè)備控制設(shè)備認證設(shè)備注銷北向設(shè)備注銷南向設(shè)備注銷南向鴻蒙設(shè)備重置圖2.24設(shè)備登錄業(yè)務(wù)過程總線矩陣舉例邏輯模型設(shè)計根據(jù)總線矩陣，進行數(shù)據(jù)倉庫邏輯模型設(shè)計，在維度建模中，有以下一些關(guān)鍵概念和組件：事實表(FactTable)：事實表是數(shù)據(jù)倉庫中的核心表，包含了與業(yè)務(wù)過程相關(guān)的數(shù)值型度量或指標。事實表中的每一行通常表示一個業(yè)務(wù)事件或交易，并與一個或多個維度表相關(guān)聯(lián)。在實際應(yīng)用時，應(yīng)該盡量將來源于同一個業(yè)務(wù)過程的底層度量結(jié)果存儲于一個維度模型中。

維度(Dimension)：維度是描述業(yè)務(wù)過程的屬性或特征，用于對事實進行分類和分組。維度表(DimensionTable)：維度表包含了描述事實表中度量的上下文信息，它們用于描述與“who、what、where、when、how、why”有關(guān)的事件，用于對事實進行分組和篩選的屬性。時間維度表藝術(shù)家維度表時間維度表藝術(shù)家維度表維度表維度表維度表維度表維度表維度表維度表維度表事實表維度表維度表維度表維度表度量/原子指標(Measure)：原子指標和度量含義相同，是事實表中的數(shù)值型數(shù)據(jù)，表示業(yè)務(wù)過程的性能或結(jié)果，是用戶在數(shù)據(jù)倉庫中分析的關(guān)鍵指標。設(shè)備維度表設(shè)備編號DID設(shè)備內(nèi)部型號設(shè)備產(chǎn)品傳播名設(shè)備維度表設(shè)備編號DID設(shè)備內(nèi)部型號設(shè)備產(chǎn)品傳播名設(shè)備品牌設(shè)備品類…日期維度表歌曲播放事務(wù)事實表維度日期[FK]設(shè)備編號DID[FK]設(shè)備產(chǎn)品傳播名時間[FK] 歌曲播放事務(wù)事實表維度日期[FK]設(shè)備編號DID[FK]設(shè)備產(chǎn)品傳播名時間[FK] UP_ID[FK]歌曲代理IO[FK]歌曲名稱歌曲專輯代理ID[FK]藝術(shù)家[FK]度量播放時長播放次數(shù)…賬號維度表...歌曲維度表歌曲專輯維度表物理模型開發(fā)與上線物理模型開發(fā)就是在邏輯模型中填充數(shù)據(jù)的過程，填充的數(shù)據(jù)就是在總線矩陣中定義的數(shù)據(jù)，這些數(shù)據(jù)的來源主要是業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫、日志、調(diào)用鏈(本質(zhì)上也是日志)、指標數(shù)據(jù)等。而這些數(shù)據(jù)并非結(jié)構(gòu)化數(shù)據(jù)，需要經(jīng)過清洗，匯聚到數(shù)據(jù)倉庫的物理表中，才能夠讓指標設(shè)計人員對指標進行進一步處理(如打標簽或者派生指標設(shè)計)，最終完成業(yè)務(wù)可觀測性指標上線。端邊縱向可觀測體系設(shè)計應(yīng)用運維的運維對象是應(yīng)用，即是將“應(yīng)用”作為一個獨立的邏輯實體。所有該應(yīng)用所使用的資源，如VM、Docker、中間件、數(shù)據(jù)庫等，都是該“應(yīng)用”的組成部分。所以對于應(yīng)用運維來說，構(gòu)建該

應(yīng)用完整的全鏈路監(jiān)控是非常有價值的工作：可以提升故障主動發(fā)現(xiàn)率，減少故障對業(yè)務(wù)的影響，提高系統(tǒng)的穩(wěn)定性和可靠性。通過逐層下鉆的數(shù)據(jù)分析能力，幫助快速定位和解決問題。通過對系統(tǒng)的實時監(jiān)測和數(shù)據(jù)分析，提供決策支持，優(yōu)化系統(tǒng)性能和資源利用率。上一章節(jié)主要闡釋了指標體系如何構(gòu)建，下面介紹如何根據(jù)這些能力構(gòu)建一個典型應(yīng)用的全鏈路監(jiān)控模型。App/ServerKitAccountkitAudioKit…邊緣網(wǎng)絡(luò)Internet/骨干網(wǎng)&CDN服務(wù)&微服務(wù)ELB Web服務(wù)器SLB App/ServerKitAccountkitAudioKit…邊緣網(wǎng)絡(luò)Internet/骨干網(wǎng)&CDN服務(wù)&微服務(wù)ELB Web服務(wù)器SLB 應(yīng)用服務(wù)器二方/三方三方服務(wù)二方服務(wù)APP體驗指標下載成功率安裝成功率…API性能指標API時延調(diào)用量成功率…邊緣網(wǎng)指標帶寬流量速率CDN…APP體驗指標下載成功率安裝成功率…API性能指標API時延調(diào)用量成功率…邊緣網(wǎng)指標帶寬流量速率CDN…服務(wù)&微服務(wù)性能API時延中間件數(shù)據(jù)庫…依賴方性能API調(diào)用量成功率…圖2.28根據(jù)上圖我們可以看出，一個應(yīng)用要對最終用戶產(chǎn)生價值，整個數(shù)據(jù)流是從端側(cè)發(fā)起，經(jīng)過接入側(cè)、廣域網(wǎng)、數(shù)據(jù)中心傳輸后，最終到達云上的服務(wù)端完成邏輯處理，再返回到端側(cè)，完成一次完整的數(shù)據(jù)交互。其中在云上服務(wù)端處理的過程中，還存在與第三方外部服務(wù)調(diào)用的場景。在這個交互過程中，任何一個環(huán)節(jié)都可能影響到最終用戶的使用和體驗。所以對于應(yīng)用的全鏈路監(jiān)控來說，每個環(huán)節(jié)都應(yīng)該盡可能地做好監(jiān)控。端側(cè)監(jiān)控通常采用埋點方式完成對端側(cè)數(shù)據(jù)的采集。端側(cè)的指標是應(yīng)用監(jiān)控指標中最能直接反應(yīng)最終用戶體驗的數(shù)據(jù)，比如打開應(yīng)用的時延、訪問成功率等。如果傳輸質(zhì)量降低，云側(cè)成功率指標可能沒有明顯波動，而通過端側(cè)指標則可迅速感知。傳輸網(wǎng)絡(luò)應(yīng)用運維需要感知本應(yīng)用在傳輸過程中的質(zhì)量數(shù)據(jù)，比如涉及地域、線路、邊緣網(wǎng)絡(luò)加速等數(shù)據(jù)，但不必過度關(guān)注底層傳輸指標。網(wǎng)絡(luò)傳輸過程中的質(zhì)量問題往往需要與運營商或供應(yīng)商協(xié)同

處理，掌握傳輸過程的數(shù)據(jù)有利于在協(xié)同處理中更高效地完成故障修復(fù)。由于無法在傳輸節(jié)點上采集數(shù)據(jù)，這部分的時延數(shù)據(jù)一般可通過云側(cè)與端側(cè)的指標通過復(fù)合計算得到。而邊緣加速網(wǎng)絡(luò)的數(shù)據(jù)可以通過供應(yīng)商的標準監(jiān)控能力獲取。云側(cè)監(jiān)控應(yīng)用的云側(cè)監(jiān)控除了應(yīng)用黃金指標外，還應(yīng)包括構(gòu)建該應(yīng)用的資源監(jiān)控。這部分的監(jiān)控數(shù)據(jù)來源于云基礎(chǔ)設(shè)施監(jiān)控能力，但要按應(yīng)用緯度進行切割、匯聚，即應(yīng)用看到的數(shù)據(jù)應(yīng)該是以本應(yīng)用為顆粒度的整體數(shù)據(jù)。三方服務(wù)指本應(yīng)用之外的調(diào)用或交互。這部分數(shù)據(jù)的獲取不能依賴對端服務(wù)，而應(yīng)該從自己應(yīng)用的調(diào)用過程中采集，例如可以通過對調(diào)用對端接口的日志進行分析的方式獲取。經(jīng)過多輪的業(yè)務(wù)可觀測指標設(shè)計之后，就可以將指標根據(jù)業(yè)務(wù)核心功能在監(jiān)控大屏中進一步呈現(xiàn)。圖2.29業(yè)務(wù)可觀測大屏展示面向故障全生命周期，全方位提升故障感知、診斷、恢復(fù)智能化水平圍繞故障生命周期，構(gòu)建開箱即用的一體化可觀測性平臺，有助于提升典型故障的故障定界、分析診斷和恢復(fù)閉環(huán)的效率。故障預(yù)防故障診斷故障診斷故障恢復(fù)故障改進自動巡檢專家診斷工具 AI輔助診斷通報自恢復(fù)事后分析鏈路診斷DB診斷性能診斷網(wǎng)絡(luò)診斷……鏈路診斷DB診斷性能診斷網(wǎng)絡(luò)診斷……WarRoom應(yīng)急預(yù)案工單管理故障生命周期管理故障處理策略管理故障模式庫(VM故障/容器故障/網(wǎng)絡(luò)故障/中間件故障/DB故障/微服務(wù)故障/…)智能運維RPA(roboticprocessautomation)智能化故障管理圖2.30應(yīng)用智能化故障管理流程智能化故障管理基于監(jiān)控指標的智能化故障呈現(xiàn)在構(gòu)建全鏈路監(jiān)控后，應(yīng)用運維就具備了精細化的業(yè)務(wù)指標監(jiān)控能力，下一步就是要能及時感知故障。傳統(tǒng)的異常檢測基于閾值開關(guān)，這樣常常會使

得閾值配置過于保守而產(chǎn)生大量的無效告警。為解決上述問題，可通過業(yè)務(wù)特征的曲線歷史形態(tài)(周期性、徒增突降、趨勢性)進行建模，從而通過動態(tài)擬合的閾值精準識別異常，1分鐘發(fā)現(xiàn)業(yè)務(wù)故障。1據(jù)和模型超參23456xx天的歷史數(shù)據(jù)123、數(shù)據(jù)平滑&插值1、周期性識別（2、波動性識別3、平穩(wěn)性識別1boxplot2DSPOT3SVM 4小樣本算法5、MAD…1（毛刺點）2、突變3、長時間掉零…8、存入模型7訓練12推理345最近xx個點的實時數(shù)據(jù)12、數(shù)據(jù)平滑&插值126111097返回實時數(shù)據(jù)推理結(jié)果（包含測量值、閾值）123告警進入標記位、告警退出標記位8圖2.31智能化感知故障建模智能化感知故障建模主要分為訓練和推理兩個階段：訓練：通過加載一定時期的歷史數(shù)據(jù)(如一個月的歷史數(shù)據(jù))，進行異常數(shù)據(jù)剔除、數(shù)據(jù)插值、數(shù)據(jù)重采等數(shù)據(jù)預(yù)處理，識別出數(shù)據(jù)特征，基于一定的模型算法，輸出訓練的閾值，形成業(yè)務(wù)運行的典型模型。閾值對比，對存在異常的指標進行標記(包含窗口突變告警等異常標記)，確定最終告警標記位，進而生成最能呈現(xiàn)指標變化的推理結(jié)果?；诒O(jiān)控指標的智能化根因診斷當應(yīng)用運維監(jiān)控指標構(gòu)建的足夠完善，就可以通過智能化分析進行故障根因診斷。故障根因診斷通常有以下幾個步驟：

告警聚合成事件，以最新告警和歷史事件作為告警聚合的輸入；并將診斷算法產(chǎn)生的根因記錄到事件中；事件中診斷的根因結(jié)果會被用來進行新告警的聚合；智能決策引擎進行事件的總結(jié)，包括事件描述的總結(jié)、事件根因的總結(jié)等。告警告警聚合告警告警聚合調(diào)用鏈根因診斷多維下鉆診斷事件日志根因診斷根因智能決策引擎流量溯源分析診斷事件總結(jié)智能診斷能力構(gòu)建中常用到的算法有AdtributorMDRCA等，用于診斷的數(shù)據(jù)來源可以是業(yè)務(wù)黃金指標、日志、流量、調(diào)用鏈等等。基于作業(yè)編排的自動化故障恢復(fù)業(yè)務(wù)系統(tǒng)故障在運維人員得知根因的情況下，往往都能快速完成故障恢復(fù)，包括但不限于：雙活流量切換、故障節(jié)點隔離、故障節(jié)點重啟等等，但對于新手可能需要指導(dǎo)并不能獨立完成。如果系統(tǒng)規(guī)模較大，即使是經(jīng)驗豐富的運維人員要完成準確的故障修復(fù)也并不容易。成熟的運維組織應(yīng)該構(gòu)建穩(wěn)定可靠的自動化故障恢復(fù)能力。構(gòu)建基于IaC(InfrastructureasCode，基礎(chǔ)設(shè)施

即代碼)的自動化部署能力，可以通過IaC對現(xiàn)網(wǎng)資源和配置進行基線化管理，以便在任何需要的時候快速完成基線變更，這樣不僅能快速完成現(xiàn)網(wǎng)故障恢復(fù)的變更操作，也可以極大地降低頻繁變更引發(fā)的人因風險。故障根因修復(fù)手段是不斷迭代積累的過程，如果要能快速不斷完善針對應(yīng)用的自動化恢復(fù)手段，還是需要一套較靈活的流程編排和腳本作業(yè)工具。腳本作業(yè)可以通過shell或python快速構(gòu)建故障修復(fù)的原子能力，而流程編排可以調(diào)用這些原子能力，以及結(jié)合應(yīng)用的監(jiān)控、告警、診斷結(jié)果等數(shù)據(jù)，構(gòu)建起完整的故障恢復(fù)流程，當故障發(fā)生時使用這些編排好的流程，即使是新手也可以快速完成故障的修復(fù)。資源聲明配置聲明環(huán)境聲明資源聲明配置聲明環(huán)境聲明狀態(tài)聲明···laC執(zhí)行灰度控制灰度評估自動化部署灰度升級配置變更自動化部署灰度升級配置變更資源變更XaC聲明自動化執(zhí)行AIOps智能底座···流量預(yù)算算法健康評估算法可觀察性數(shù)據(jù)事件數(shù)據(jù)自動化結(jié)果評估服務(wù)狀態(tài)評估結(jié)果驗證自動化評審準入評審事件評估DryRun風險評審高危操作爆炸半徑開始開始completeandresult().result.Status!=0completecompleteandresult().result.Status!=0completecompletecompletecomplete結(jié)束回調(diào)器step18回調(diào)失敗step15執(zhí)行失敗發(fā)送消息step3開始自動修復(fù)告警回調(diào)器step16回調(diào)成功step17清除告警step11確認告警查看step查看ipstep14執(zhí)行成功圖2.34安全運維現(xiàn)代化隨著金融業(yè)務(wù)上云從一般業(yè)務(wù)擴展到核心業(yè)務(wù)，云平臺安全管控面臨的復(fù)雜情況增加。這些新的情況都讓金融云的安全面臨著前所未有的挑戰(zhàn)，例如：傳統(tǒng)的安全威脅主要來源于數(shù)據(jù)中心外部，在邊界作好防護就能解決大部分問題。而在金融云場景下，租戶間網(wǎng)絡(luò)邊界從物理邊界變?yōu)樘摂M網(wǎng)絡(luò)邊界，防護邊界變的模糊。此外，云平臺的安全邊界還會隨著云租戶數(shù)量和規(guī)模的擴展或調(diào)整而發(fā)生動態(tài)調(diào)整；安全攻擊不僅有可能來源于數(shù)據(jù)中心外部，還可能來源于內(nèi)部的社會工程、釣魚軟件、惡意植入、權(quán)限濫用、數(shù)據(jù)竊取等安全威脅；攻擊點的多樣性需要不同安全防護工具來應(yīng)對，因而，安全威脅會在不同安全防護工具上以不同的形式顯現(xiàn)出來，如果安全工具間不能很好協(xié)同，安全威脅防范的效率將無法保證；不僅云主機、容器、云內(nèi)數(shù)據(jù)需要安全防護，云原生應(yīng)用和API也需要進行安全防護。此外，在復(fù)雜性快速上升的云租戶安全防護場景下，僅僅被動響應(yīng)安全威脅已經(jīng)無法滿足安全運營的要求，主動安全勢在必行。面對這些新的挑戰(zhàn)，整體上應(yīng)從運維安全體系設(shè)計和云安全運營兩大層面進行面向現(xiàn)代化的能力構(gòu)建。云運維安全堤壩在云運維領(lǐng)域，由于運維安全設(shè)計不周或能力不足造成的事故不勝枚舉，如由于管理員和租戶權(quán)限設(shè)置不當造成誤刪除存儲或虛擬機，由于變更過程缺乏管控造成誤配或業(yè)務(wù)沖擊，由于高危操作缺乏管

控造成數(shù)據(jù)誤刪等等，這些事故往往會造成業(yè)務(wù)中斷，給企業(yè)造成重大損失。運維安全不僅需要從意識層面重視，更重要的是從管理到技術(shù)兩個層面制定保障機制，實現(xiàn)運維過程事前、事中、事后端到端的安全保障。事前布局在傳統(tǒng)IT網(wǎng)絡(luò)中，運維主管通常主要關(guān)注對管理員權(quán)限的統(tǒng)籌規(guī)劃與管理。在深度用云的時代，云服務(wù)越來越多，業(yè)務(wù)場景越來越多樣化，更多的場景要基于云服務(wù)、基于租戶操作進行授權(quán)，而不再是傳統(tǒng)的按照資源進行授權(quán)。因此，金融云場景不但對管理員權(quán)限規(guī)劃提出了更高的要求，也需要實現(xiàn)對租戶權(quán)限的統(tǒng)籌管理。具體來說，金融企業(yè)需要建立統(tǒng)一的權(quán)限管理制度和規(guī)范，建立運維權(quán)限分配指導(dǎo)和審核制度，無論運維管理員還是租戶，都應(yīng)該按照“權(quán)責匹配、最小授權(quán)”的原則進行權(quán)限規(guī)劃。同時，需要建立完整的賬戶權(quán)限分配、賬戶提權(quán)、權(quán)限回收、密碼策略與權(quán)限審查機制，保障權(quán)限管理的持續(xù)有效。權(quán)限管理除了在規(guī)范和制度上進行約束外，還應(yīng)當將權(quán)限管理落實到工具上。在工具上實現(xiàn)按云服務(wù)、資源、租戶、操作等多維度組合授權(quán)，也就是說，將云服務(wù)、資源池、租戶和具體操作權(quán)限分別當成一個獨立維度，賬號的實際權(quán)限為幾個維度權(quán)限的交集，這樣才能精確匹配賬號的職責，實現(xiàn)最小授權(quán)。事中管控除了對權(quán)限進行管控外，對運維操作過程也需要進行嚴格管控。重點需要關(guān)注的操作有如下幾方面：云管或堡壘機進行，避免任何不受控變更的發(fā)生；回收所有內(nèi)部特權(quán)賬號，并定期修改特權(quán)賬號口令；所有操作均需要通過審核并在變更窗口期內(nèi)對賬戶進行提權(quán)，窗口期過后權(quán)限會被回收；在配置變更過程中，管理員輸入的每個命令行和回顯都會被記錄歸檔，用于后期審計與回溯；云管和堡壘機均需實現(xiàn)對高危命令的攔截，避免誤操作帶來災(zāi)難性損失；變更審核時對黑屏操作進行管控，逐步減少黑屏操作的頻次，牽引變更操作通過自動化腳本完成，便于變更前驗證以及后續(xù)復(fù)用?？傊?，通過合理制定和落實事中管控的一系列手段，可以從技術(shù)上最大限度