2024年主機(jī)上云運(yùn)維現(xiàn)代化核心能力白皮書-華為-46正式版

踐行深度用云主機(jī)上云運(yùn)維現(xiàn)代化核心能力編制委員會

PREPARATIONCOMMITTEE主編單位華為云計算技術(shù)有限公司編委顧問尚海峰胡玉海貢青劉征輝林麗鑫編審組成員支新輝王飛徐俊主編人員郭曉征耿麗麗馬曉明毛明強(qiáng)張志炯張毅王進(jìn)行馬韜石松參編人員黃征彬熊洪槐錢沛秦丹濤張瀚文聞濤張江王珂石沛李松李晉彭永紅胡堃程紫東姚博田應(yīng)軍席彬王樂曉劉杰張任遠(yuǎn)張凱關(guān)建峰趙靜敏責(zé)任編輯王瑞（排名不分先后）序言

尚海峰華為主機(jī)上云軍團(tuán)CEO、混合云總裁過去三四十年，金融核心系統(tǒng)主要采用集中式主機(jī)架構(gòu)進(jìn)行建設(shè)。隨著金融業(yè)務(wù)數(shù)字化轉(zhuǎn)型需求的不斷深化，云計算技術(shù)的持續(xù)演進(jìn)，金融機(jī)構(gòu)普遍采用了云原生相關(guān)技術(shù)進(jìn)行業(yè)務(wù)改造，更有不少頭部大行作為先行者，率先將主機(jī)承載的核心系統(tǒng)業(yè)務(wù)也遷移上云，加速了金融行業(yè)數(shù)智化、自主創(chuàng)新進(jìn)程。目前，大部分國有銀行和股份制銀行已經(jīng)完成了從一般類業(yè)務(wù)上云到核心類業(yè)務(wù)上云改造的試點工作，進(jìn)入到核心業(yè)務(wù)批量上云改造階段。柜面系統(tǒng)、網(wǎng)銀系統(tǒng)、信貸系統(tǒng)、投資理財系統(tǒng)、信用卡系統(tǒng)等核心交易系統(tǒng)陸續(xù)遷移到云上，使得金融云平臺承載的業(yè)務(wù)規(guī)模不斷擴(kuò)大，重要性不斷攀升。隨之而來的是，業(yè)務(wù)對持續(xù)高可用的要求更加苛刻，尤其是核心業(yè)務(wù)上云后，任何業(yè)務(wù)中斷都會引發(fā)重大的影響。金融對公眾開放的核心業(yè)務(wù)一旦中斷會造成嚴(yán)重的社會影響甚至引發(fā)信用危機(jī)。除業(yè)務(wù)中斷外，業(yè)務(wù)的劣化，如卡頓、報錯等，也會造成最終用戶的不滿和投訴。這就對承載核心業(yè)務(wù)的云平臺提出了更高的穩(wěn)定性、可靠性要求。除了穩(wěn)定的產(chǎn)品外，強(qiáng)大的運(yùn)維體系是保障云平臺穩(wěn)定性最直接、最有效的手段。在主機(jī)核心業(yè)務(wù)逐步上云后，如何加強(qiáng)運(yùn)維全鏈路監(jiān)控能力，快速定位、定界和解決問題，如何變被動運(yùn)維為主動故障預(yù)防從而大幅減少潛在故障與運(yùn)維投入，如何將應(yīng)用運(yùn)維與平臺運(yùn)維進(jìn)行有效協(xié)同從而保障系統(tǒng)性業(yè)務(wù)高可靠高可用，如何應(yīng)對平臺運(yùn)維安全與租戶安全帶來的雙重挑戰(zhàn)等問題，成為了擺在金融運(yùn)維人面前的關(guān)鍵挑戰(zhàn)。華為云基于自身云平臺運(yùn)維經(jīng)驗，以及服務(wù)上百家金融客戶數(shù)字化轉(zhuǎn)型的實踐，持續(xù)積累主機(jī)上云場景的運(yùn)維核心能力，并沉淀了一套全面構(gòu)建穩(wěn)定可靠的現(xiàn)代化運(yùn)維能力的路徑和方法，期望助力金融企業(yè)加快實現(xiàn)主機(jī)業(yè)務(wù)的全面云化。CONTENTS錄目05-08主機(jī)上云帶來的運(yùn)維新挑戰(zhàn)1.1挑戰(zhàn)1：如何基于應(yīng)用視角設(shè)計高可用上云方案與高可靠運(yùn)維保障方案1.2挑戰(zhàn)2：云平臺技術(shù)?？焖僭龊?，如何有效進(jìn)行全鏈路可視監(jiān)控1.3挑戰(zhàn)3：云網(wǎng)深度融合，如何快速發(fā)現(xiàn)、定位、恢復(fù)問題1.4挑戰(zhàn)4：如何應(yīng)對運(yùn)維安全與租戶安全的雙重挑戰(zhàn)09-43主機(jī)上云運(yùn)維現(xiàn)代化核心能力2.1平臺運(yùn)維現(xiàn)代化2.1.1全鏈路運(yùn)維監(jiān)控構(gòu)建從應(yīng)用到云平臺的全棧感知能力2.1.2基于故障模式庫和云網(wǎng)一體化運(yùn)維實現(xiàn)確定性故障恢復(fù)2.1.3基于一體化風(fēng)險庫和混沌工程進(jìn)行預(yù)見性風(fēng)險治理2.2應(yīng)用運(yùn)維現(xiàn)代化2.2.1運(yùn)維規(guī)劃前置到設(shè)計階段，業(yè)務(wù)可靠性來源于運(yùn)維與設(shè)計的融合2.2.2借助運(yùn)維數(shù)倉構(gòu)建應(yīng)用可用性監(jiān)控管理體系，實現(xiàn)業(yè)務(wù)故障實時感知定界2.2.3面向故障全生命周期，全方位提升故障感知、診斷、恢復(fù)智能化水平2.3安全運(yùn)維現(xiàn)代化2.3.1全視角運(yùn)維安全體系設(shè)計構(gòu)筑金融云運(yùn)維安全堤壩2.3.2體系化、智能化安全運(yùn)營為云上業(yè)務(wù)保駕護(hù)航44結(jié)語主機(jī)上云帶來的運(yùn)維新挑戰(zhàn)挑戰(zhàn)1：如何基于應(yīng)用視角設(shè)計高可用上云方案與高可靠運(yùn)維保障方案主機(jī)上云的最大挑戰(zhàn)就是核心應(yīng)用上云后的可用性管理。隨著原來運(yùn)行在大機(jī)上的應(yīng)用不斷遷移上云，云上的業(yè)務(wù)可用性等級要求被提升到了新的高度，傳統(tǒng)的運(yùn)維手段已經(jīng)無法滿足核心業(yè)務(wù)N個9的可用性目標(biāo)?？捎眯怨芾砬爸玫搅讼到y(tǒng)設(shè)計乃至應(yīng)用設(shè)計階段。即便如此，可用性管理依然面臨著成本、技術(shù)和管理的三重挑戰(zhàn)。首先，無論是備份、主備、多活還是業(yè)務(wù)單元化改造，所有的高可用的架構(gòu)設(shè)計都需要投入高昂的成本，高可用的效果和技術(shù)方案的投入成本成正相關(guān)關(guān)系。如何平衡高可用的投入與產(chǎn)出就成為IT管理者在高可用管理過程中的重要難題。其次，高可用設(shè)計是一系列技術(shù)方案的組合，從底層網(wǎng)絡(luò)設(shè)計、到云服務(wù)的有效運(yùn)用以及高可用技術(shù)工具的選型，從業(yè)務(wù)部署架構(gòu)的改造到上層業(yè)務(wù)的單元化改造，每個層次都涉及多種技術(shù)的使用與配合。如何讓現(xiàn)有的技術(shù)手段以及云服務(wù)發(fā)揮最大的效能，如何基于先進(jìn)的單元化設(shè)計理念達(dá)成核心應(yīng)用N個9的可靠性也是IT管理者面臨的難題。最后，服務(wù)SLA（ServiceLevelAgreement,服務(wù)水平協(xié)議）的達(dá)成還需要有相匹配的管理手段與工具，如故障模式庫、演練工具等資源作為支撐，不但要能有效跟蹤度量SLA的實際效果，還需要持續(xù)、主動發(fā)現(xiàn)可用性風(fēng)險的機(jī)制與工具，在可用性管理的過程中實現(xiàn)數(shù)據(jù)積累和能力演進(jìn)。挑戰(zhàn)2：云平臺技術(shù)?？焖僭龊?，如何有效進(jìn)行全鏈路可視監(jiān)控隨著主機(jī)上云和業(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ùn)維方式帶來巨大沖擊。例如，應(yīng)用的微服務(wù)化改造，帶來微服務(wù)數(shù)量的指數(shù)級增長，應(yīng)用的調(diào)用層次和調(diào)用關(guān)系變得冗長；分布式云原生的深度應(yīng)用，使得業(yè)務(wù)鏈路更加復(fù)雜。當(dāng)上層業(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實例>虛擬機(jī)>服務(wù)器>虛擬網(wǎng)絡(luò)>物理網(wǎng)絡(luò)。在針對這個路徑的運(yùn)維實際工作中，應(yīng)用、虛擬機(jī)軟件提供方、服務(wù)器和網(wǎng)絡(luò)設(shè)備提供方常常是各管一段，整個業(yè)務(wù)從上到下的全棧調(diào)用路徑往往是個黑盒，導(dǎo)致故障定位定界困難，或者恢復(fù)時長無法控制。面對IT系統(tǒng)復(fù)雜的技術(shù)棧及海量的運(yùn)維對象，做到軟硬件運(yùn)維對象的統(tǒng)一管理，指標(biāo)、告警、日志、調(diào)用鏈、拓?fù)涞冗\(yùn)維數(shù)據(jù)的統(tǒng)一匯聚和分析，構(gòu)建全鏈路故障感知、全棧故障可視的運(yùn)維體驗，對于金融主機(jī)上云過程中的運(yùn)維工作至關(guān)重要。挑戰(zhàn)3：云網(wǎng)深度融合，如何快速發(fā)現(xiàn)、定位、恢復(fù)問題過去一年，在互聯(lián)網(wǎng)領(lǐng)域發(fā)生過多起頗為嚴(yán)重的宕機(jī)事故：2023年3月，某互聯(lián)網(wǎng)服務(wù)商發(fā)生機(jī)房故障，多個互聯(lián)網(wǎng)核心應(yīng)用受到影響，事故持續(xù)7個小時，影響約十幾億用戶。2023年11月，某云服務(wù)商旗下多款應(yīng)用出現(xiàn)無法登錄故障，事故持續(xù)4個小時，這是該云服務(wù)商時06隔一年之后第二次出現(xiàn)嚴(yán)重故障。 如何解決云網(wǎng)絡(luò)問題在云網(wǎng)絡(luò)和物理網(wǎng)絡(luò)深度融合的場景下，應(yīng)用級的網(wǎng)2023年11月，某互聯(lián)網(wǎng)服務(wù)公司核心應(yīng)用業(yè)務(wù)癱 絡(luò)可視、云網(wǎng)絡(luò)端到端的故障探測是解決云網(wǎng)絡(luò)問題瘓接近12個小時，流失千萬訂單，直接損失上億 的關(guān)鍵所在。元，引發(fā)了廣泛的社會關(guān)注?？偨Y(jié)上述這些事故，它們都具備了如下幾個特點： 挑戰(zhàn)4：如何應(yīng)對運(yùn)維安全與租戶安全的雙重挑戰(zhàn)事故影響范圍巨大，社會反響強(qiáng)烈，更有甚者還會對社會的衣食住行產(chǎn)生嚴(yán)重影響。 主機(jī)上云的過程中，應(yīng)用與云平臺的運(yùn)維會同時受到運(yùn)維安全和租戶安全的雙重挑戰(zhàn)。事故影響時間較長，業(yè)務(wù)恢復(fù)周期以數(shù)小時計，嚴(yán)重者故障恢復(fù)時長達(dá)到了12小時。 在運(yùn)維安全方面常見的挑戰(zhàn)包括：造成巨額經(jīng)濟(jì)損失，負(fù)責(zé)人被處分、問責(zé)。 運(yùn)維安全意識不足運(yùn)維管理者缺乏對運(yùn)維安全的完整規(guī)劃，在制度、流隨著上云進(jìn)程的逐漸深入，金融企業(yè)開始將核心應(yīng)用 程和技術(shù)規(guī)范方面缺少對變更的嚴(yán)格管控。在缺乏對搬遷上云。核心應(yīng)用一般有著規(guī)模大、分布式、架構(gòu) 變更的嚴(yán)格審控機(jī)制的情況下，隨意的變更為引發(fā)后復(fù)雜等特點，這一點和互聯(lián)網(wǎng)業(yè)務(wù)非常相似，上述互 續(xù)事故埋下了隱患。聯(lián)網(wǎng)的故障也在時刻給金融核心應(yīng)用的運(yùn)維敲響警鐘。在此背景下，近年來金融領(lǐng)域客戶提出了核心業(yè) 運(yùn)維安全管控的技術(shù)手段不足務(wù)的“1-5-10”目標(biāo)，即：1分鐘發(fā)現(xiàn)故障、5分鐘 主要表現(xiàn)為，對運(yùn)維操作入口沒有進(jìn)行技術(shù)管控，缺定位、10分鐘恢復(fù)。要實現(xiàn)這個目標(biāo)必須要解決以 乏對運(yùn)維操作過程的有效監(jiān)管，缺乏對高危操作的攔下關(guān)鍵問題： 截，缺乏對運(yùn)維操作的記錄與審計，缺乏識別惡意操作的評估手段。如何盡可能地少出問題首先，需要有一個完善的運(yùn)維規(guī)范和流程來保障運(yùn)維 權(quán)責(zé)不匹配流程合規(guī)；其次，核心應(yīng)用需要全局的高可用設(shè)計， 運(yùn)維人員的權(quán)限過大或者超越自己的職責(zé)范圍，很容從架構(gòu)層面避免單點故障；最后，企業(yè)還應(yīng)具備完善 易引發(fā)超出職責(zé)范圍的誤操作，從而帶來不必要的運(yùn)的風(fēng)險管理體系，可以對識別到的風(fēng)險舉一反三快速 維風(fēng)險。閉環(huán)，持續(xù)提升核心應(yīng)用的韌性。在租戶安全方面的挑戰(zhàn)包括：如何快速恢復(fù)故障基于核心應(yīng)用黃金指標(biāo)的秒級故障感知是故障恢復(fù)的 安全攻擊無法避免前提；基于調(diào)用鏈分析、日志解析、云服務(wù)實例快速 希望一勞永逸地解決租戶安全問題是不切實際的。人診斷的分鐘級故障定位是故障恢復(fù)的基礎(chǔ)；基于應(yīng)急 類的操作永遠(yuǎn)無法做到完美，系統(tǒng)和技術(shù)總在不斷演處理預(yù)案的一鍵式故障恢復(fù)是行之有效的手段。 進(jìn)，新的漏洞會不斷出現(xiàn)，完全消除漏洞是不可能的。所以，0日攻擊、釣魚攻擊以及賬戶被破解都無法被避免。07租戶安全防護(hù)難以全局統(tǒng)籌現(xiàn)代企業(yè)和組織的網(wǎng)絡(luò)環(huán)境越發(fā)復(fù)雜，涉及眾多設(shè)備、應(yīng)用、數(shù)據(jù)類型。同時安全威脅也在不斷演變，

理解威脅的本質(zhì)，以制定有效的處置策略。有時候安全團(tuán)隊還會面臨技術(shù)上的限制，從而需要花費(fèi)更多時間來研究和實施解決方案。包括網(wǎng)絡(luò)攻擊、釣魚、木馬、病毒、社會工程學(xué)攻擊等多種形式。安全團(tuán)隊需要同時跟蹤多種威脅情報，及時調(diào)整安全策略和措施，以應(yīng)對各種各樣的威脅。安全威脅處置緩慢安全威脅普遍具有隱蔽性強(qiáng)的特點，不易被及時發(fā)現(xiàn)?，F(xiàn)代安全威脅越來越復(fù)雜和多樣化，攻擊手段和方式不斷演變，安全團(tuán)隊需要花費(fèi)更多時間來分析和

在實際業(yè)務(wù)場景中，由于安全管理不善造成重大事故和業(yè)務(wù)損失的案例并不鮮見，如誤刪數(shù)據(jù)庫賬戶造成結(jié)算業(yè)務(wù)失效，誤刪虛擬機(jī)造成業(yè)務(wù)中斷，租戶權(quán)限管理不當(dāng)誤刪OBS桶等等。云化、集中化雖然提升了業(yè)務(wù)的創(chuàng)新速度，也讓運(yùn)維安全的管控以及租戶安全的治理變得更加復(fù)雜，所以運(yùn)維安全是業(yè)務(wù)可靠性保障的基石，也是運(yùn)維現(xiàn)代化的基礎(chǔ)。主機(jī)上云運(yùn)維現(xiàn)代化核心能力主機(jī)上云運(yùn)維現(xiàn)代化旨在圍繞核心系統(tǒng)云平臺運(yùn)維、應(yīng)用運(yùn)維及安全運(yùn)維三大領(lǐng)域系統(tǒng)性構(gòu)建上云后的云運(yùn)維保障能力，全面支撐金融核心應(yīng)用通過平遷、改造或核心重構(gòu)三種方式遷移上云后的穩(wěn)定可靠運(yùn)行，助力金融機(jī)構(gòu)平滑穩(wěn)健地深化數(shù)智業(yè)務(wù)創(chuàng)新，構(gòu)筑面向自主創(chuàng)新的高質(zhì)量發(fā)展基座。存貸款支付結(jié)算現(xiàn)金管理理財管理資金交易中間業(yè)務(wù)消費(fèi)信貸主動預(yù)防運(yùn)行穩(wěn)定安全可靠1.平臺運(yùn)維現(xiàn)代化2.應(yīng)用運(yùn)維現(xiàn)代化3.安全運(yùn)維現(xiàn)代化全鏈路確定性預(yù)見性高可用智能化全視角體系化運(yùn)維監(jiān)控故障恢復(fù)風(fēng)險治理架構(gòu)設(shè)計應(yīng)用運(yùn)維運(yùn)維安全安全運(yùn)營全鏈路可觀測云網(wǎng)定位定界主動風(fēng)險預(yù)防面向應(yīng)用運(yùn)維故障精準(zhǔn)診斷變更風(fēng)控管控極簡信息匯聚一鍵故障恢復(fù)混沌工程演練

高可用SLA規(guī)劃運(yùn)維數(shù)據(jù)治理用戶授權(quán)可控制立體防御體系應(yīng)用高可用設(shè)計可用性指標(biāo)構(gòu)建作業(yè)過程可信賴主動智能安全持續(xù)高可用治理運(yùn)維故障分析潛在風(fēng)險可識別全面安全運(yùn)營主機(jī)上云新基座應(yīng)用平遷上云 應(yīng)用改造上云 核心重構(gòu)圖2.1運(yùn)維現(xiàn)代化三大核心能力平臺運(yùn)維現(xiàn)代化平臺運(yùn)維的現(xiàn)代化轉(zhuǎn)型重點要考慮如下三方面的能力 華為云給出了通過全鏈路檢測、故障模式庫和云網(wǎng)結(jié)建設(shè)： 合快速定界故障的思路，以此提升核心應(yīng)用上云后云平臺故障恢復(fù)的確定性。全鏈路運(yùn)維監(jiān)控核心業(yè)務(wù)上云的過程中，云與應(yīng)用的耦合度逐步提 預(yù)見性風(fēng)險治理高，應(yīng)用與云平臺的關(guān)系愈加復(fù)雜，因而云運(yùn)維必須 實現(xiàn)風(fēng)險的提前感知與預(yù)防始終是運(yùn)維管理者長期的實現(xiàn)應(yīng)用到云平臺乃至物理設(shè)備的全鏈路覆蓋。同時 期望，也是運(yùn)維人員一直面臨的難題。這個問題同樣需要梳理出應(yīng)用與云平臺間的依賴關(guān)系，當(dāng)應(yīng)用出現(xiàn) 擺在華為面前。在十多年運(yùn)維工作中，華為云通過大故障的時候能夠基于應(yīng)用的視角快速感知和診斷故 量項目實踐摸索出了一套預(yù)見性風(fēng)險治理的思路，不障。 但覆蓋了運(yùn)行時的風(fēng)險治理，也覆蓋了對變更的風(fēng)險治理方法，以及對未知風(fēng)險的識別與預(yù)防手段，本文確定性故障恢復(fù) 將詳細(xì)闡釋通過數(shù)字化到自動化的轉(zhuǎn)換實現(xiàn)云平臺風(fēng)快速創(chuàng)新的金融業(yè)務(wù)場景增加了云平臺技術(shù)棧復(fù)雜 險預(yù)見性治理的思考。度，也因此提升了故障定界、故障快速恢復(fù)的難度。10應(yīng)用運(yùn)維現(xiàn)代化當(dāng)前，越來越多金融云運(yùn)維管理者的關(guān)注點從以云與設(shè)備為核心的運(yùn)維轉(zhuǎn)向以應(yīng)用為核心的運(yùn)維，尤其是核心應(yīng)用的運(yùn)維受到格外的重視。在應(yīng)用運(yùn)維領(lǐng)域，存在多種多樣的工具與技術(shù)，然而工具之間數(shù)據(jù)割裂無法形成全局視野，因而會直接影響應(yīng)用運(yùn)維的效率與效果。只有打破各個工具間的數(shù)據(jù)孤島才能統(tǒng)籌洞察應(yīng)用的完整運(yùn)行態(tài)勢，對應(yīng)用進(jìn)行全方位的監(jiān)控與分析。在本文中，華為云提出要將應(yīng)用的可靠性保障前置到設(shè)計階段，通過高可用設(shè)計提升應(yīng)用的可靠性，同時也給出了應(yīng)用高可用設(shè)計的思路，幫助金融企業(yè)選擇合適的高可用方案平衡成本與效益的矛盾。安全運(yùn)維現(xiàn)代化運(yùn)維安全是保障業(yè)務(wù)可靠性的基石，也是運(yùn)維現(xiàn)代化的基礎(chǔ)。在運(yùn)維安全領(lǐng)域需要通過對運(yùn)維過程無死角的安全管控來保障運(yùn)維安全，具體來說，需要實現(xiàn)事前對權(quán)限的有效規(guī)劃和管理，事中對運(yùn)維操作的嚴(yán)格管控，以及事后對運(yùn)維操作的審計與分析，減少由于運(yùn)維誤操作給云業(yè)務(wù)帶來的風(fēng)險。除了云平臺本身的安全保障，在租戶安全維度，也應(yīng)構(gòu)建完整的安全防護(hù)體系，端到端保障云租戶的安全。2.1平臺運(yùn)維現(xiàn)代化核心能力2.1.1全鏈路監(jiān)控構(gòu)建從應(yīng)用到云平臺的全棧感知能力從應(yīng)用視角到平臺視角，構(gòu)建全面的指標(biāo)體系，快速感知故障核心應(yīng)用部署上云，從上到下可以分為四層，分別為終端層、應(yīng)用層、PaaS實例層和IaaS基礎(chǔ)設(shè)施層。如下圖：終端層嚴(yán)格意義上并不在云上部署，主要部署在端側(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è)備等。簡單應(yīng)用訪問流程示例 微服務(wù)架構(gòu)復(fù)雜應(yīng)用訪問流程示例訂單處理120ms102ms層user-mgrMySQL102ms用應(yīng)ELB102msapi-gwcache-mgrAPPAPPAPP200ms102ms102ms數(shù)據(jù)庫RabbitMQproduct-mgrRedispaas實例層laas層

緩存 容器節(jié)點 云硬盤 云主機(jī) 緩存數(shù)據(jù)云庫主機(jī) 云硬盤容器節(jié)點 數(shù)據(jù)庫宿主機(jī) 網(wǎng)元 存儲池 宿主機(jī) 宿主機(jī) 網(wǎng)元 存儲池 宿主機(jī) 物理主機(jī) 網(wǎng)元 存儲池云數(shù)據(jù)中心1 云數(shù)據(jù)中心2 傳統(tǒng)數(shù)據(jù)中心如上圖所示，針對簡單應(yīng)用（綠色線條），可以直接以應(yīng)用云上部署架構(gòu)來構(gòu)建全鏈路監(jiān)控；針對微服務(wù)架構(gòu)的復(fù)雜應(yīng)用（紅色線條），需要借助APM工具解析微服務(wù)間交互流程來構(gòu)建全鏈路監(jiān)控。圖2.2典型云上應(yīng)用部署模型12構(gòu)建核心應(yīng)用可觀測體系，需要根據(jù)應(yīng)用部署層級分別進(jìn)行設(shè)計：終端可觀測終端層需重點關(guān)注用戶的使用體驗，采集終端應(yīng)用運(yùn)行報告、訪問成功率、接口延時等體驗類指標(biāo)，通過終端內(nèi)置的軟件工具包(SDK)上報到應(yīng)用可觀測平臺。必要時需要部署一定數(shù)量的云撥測終App/ServerKit邊緣網(wǎng)絡(luò)AccountkitAudiokit…Internet/骨干網(wǎng)&CDNAPP體驗指標(biāo)API性能指標(biāo)邊緣網(wǎng)絡(luò)指標(biāo)下載成功率API時延帶寬安裝成功率調(diào)用量流量首頁打開耗時成功率速率首頁圖片耗時…CDN用戶搜索耗時…應(yīng)用詳情耗時用戶下載速率…圖2.3典型終端指標(biāo)設(shè)計流程

端，對應(yīng)用進(jìn)行周期性撥測，快速感知邊緣網(wǎng)絡(luò)故障。終端層常見指標(biāo)舉例：APP體驗指標(biāo)：如下載成功率、安裝成功率、用戶搜索耗時、用戶下載速率等表征最終用戶體驗的指標(biāo)API性能指標(biāo)：調(diào)用成功率、調(diào)用量、時延等邊緣網(wǎng)絡(luò)性能指標(biāo)：丟包率、延時、帶寬、流量消耗等應(yīng)用可觀測應(yīng)用層需要根據(jù)應(yīng)用的核心功能，構(gòu)建表征功能健康度的黃金指標(biāo)。不同應(yīng)用功能存在差異，梳理出的指標(biāo)不盡相同，指標(biāo)越能精細(xì)表征健康度，越能快速感知故障，反之亦然。以某互聯(lián)網(wǎng)視頻應(yīng)用為例，需要基于應(yīng)用接口日志定義接口請求量、接口成功率、接口時延、播放卡頓率等指標(biāo)，針對指標(biāo)數(shù)據(jù)進(jìn)行治理，最終呈現(xiàn)不同時間維度的視圖，同時支持針對流量的趨勢進(jìn)行動態(tài)閾值調(diào)整，準(zhǔn)確產(chǎn)生指標(biāo)告警。維度：APP版本、視頻分類視頻登錄請求成功次數(shù)/度量：請求結(jié)果標(biāo)識、時延視頻登錄請求次數(shù)視頻登錄請求成功次數(shù)視頻登錄請求次數(shù)視頻登錄請求成功率長視頻登錄請求成功率邏輯主體基礎(chǔ)指標(biāo)派生指標(biāo)指標(biāo)疊加公式組合指標(biāo)派生組合指標(biāo)APP...視頻請求...時延視頻登錄視頻登錄視頻登錄長視頻登錄版本分類結(jié)果1.0.1長視頻成功30請求次數(shù)請求成功次數(shù)請求成功率請求成功率1.0.2短視頻成功501.0.1短視頻成功35X（次）X（次）XX（%）XX（%）1.0.3長視頻失敗40圖2.4指標(biāo)設(shè)計流程示例13應(yīng)用指標(biāo)定義完成之后，還需要構(gòu)建應(yīng)用全鏈路拓?fù)湟晥D，發(fā)生故障時，能夠在拓?fù)湟晥D中直觀呈現(xiàn)，運(yùn)維人員可以從多個維度快速感知故障影響范圍，并對故障進(jìn)行簡單定界。全鏈路拓?fù)湟话憧梢苑殖蓱?yīng)用調(diào)用拓?fù)浜途W(wǎng)絡(luò)流量拓?fù)洌?應(yīng)用調(diào)用視圖：基于APM(applicationperformancemanagement，應(yīng)用性能管理)調(diào)用鏈能力，追蹤應(yīng)用進(jìn)程內(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)用視圖33calls|120msuser-31calls|102msmgrMySQL31calls|102ms31calls|102msapi-133calls|200mscache31calls|102msRabbitMQgw-mgr29calls|1014ms503calls|568msproduct31calls|102ms-mgrRedis0%/8us0%/10usapi-3%/20usGuestOSGuestOSRabbitMQgw網(wǎng)絡(luò)流量視圖subnetELB源端subnet目的端subnetVPC源端目的端0%/15us0%/8usvSwitchELB源端0%/15us0%/8us0%/8usvSwitch0%/15us0%/8us0%/8us0%/8us0%/15us目的端vSwitchvSwitch源端目的端圖2.5全鏈路應(yīng)用拓?fù)湟晥D14PaaS實例可觀測式數(shù)據(jù)庫的長事務(wù)、慢SQL執(zhí)行等指標(biāo)。云平臺通常能夠提供豐富的PaaS實例，如容器集群、消息隊列、數(shù)據(jù)庫、分布式緩存、分布式事-Error(錯誤率)：代表執(zhí)行某一業(yè)務(wù)的錯誤率是務(wù)等中間件，這一類PaaS實例由云平臺側(cè)提供開多少，如分布式緩存高危命令、大Key使用等指箱即用的SLI(servicelevelindicator,服務(wù)質(zhì)量標(biāo)。指標(biāo))，通過API或者監(jiān)控對接等方式接入到應(yīng)用運(yùn)維平臺。此類指標(biāo)以云平臺提供的客戶可感知-Ticket(工單)：代表某一功能是否需要人工介的服務(wù)實例為中心，直觀體現(xiàn)實例狀態(tài)的監(jiān)控指入，人工介入越多，可用性越差。標(biāo)，與實例類型強(qiáng)相關(guān)，通常以業(yè)務(wù)請求消息統(tǒng)計的形式獲取對應(yīng)指標(biāo)。PaaS實例SLI指標(biāo)體系建設(shè)遵照VALET原則構(gòu)建五個維度的指標(biāo)：容量-Volume(容量)：是指服務(wù)承諾的最大容量是多少，如數(shù)據(jù)庫連接數(shù)、容器集群可用節(jié)點數(shù)等。可用性工單實例SLI指標(biāo)-Availablity(可用性)：代表服務(wù)是否正常，如實例主備狀態(tài)、實例可用副本數(shù)量等。延時錯誤率-Latency(時延)：代表響應(yīng)是否足夠快，如分布圖2.6遵照VALET模型建設(shè)SLI指標(biāo)體系指標(biāo)指標(biāo)監(jiān)控閾值重復(fù)影響云服務(wù)功能功能VALET指標(biāo)（索引）點平面類別名稱單位周期方式規(guī)則次數(shù)說明連接使用率大于90%查詢上述指標(biāo)表征DCS實例連接使用率情況，超過DCS實例DCS實例服務(wù)過去1分鐘內(nèi)為一個統(tǒng)計周DCS數(shù)據(jù)面可用性%1分鐘3使用率可能導(dǎo)致實例新建連接失敗，可用性產(chǎn)可連接性連接使用率監(jiān)控期，至少3次檢測連接使生異常。用率達(dá)到95%。查詢過去1分鐘內(nèi)為一個統(tǒng)DCSDCS實例數(shù)據(jù)面延時DCS實例毫秒1分鐘服務(wù)計周期，每分鐘統(tǒng)計的最3實例命令時延過長，阻塞后續(xù)命令執(zhí)行，影響可連接性命令時延監(jiān)控大時延超過10ms，連續(xù)實例功能。三次上報告警。查詢過去1分鐘內(nèi)為一個統(tǒng)DCSDCS實例數(shù)據(jù)面錯誤率DCS實例布爾1分鐘告警計周期，存在高危命令、1高危命令、大Key使用可能影響實例可用性。可連接性使用規(guī)范性類型大Key使用的告警。需要考慮告警聚合策略。圖2.7可用性指標(biāo)設(shè)計舉例15基礎(chǔ)設(shè)施可觀測基礎(chǔ)設(shè)施指標(biāo)主要是指以公共的基礎(chǔ)設(shè)施類資源為中心，用于體現(xiàn)基礎(chǔ)資源當(dāng)前運(yùn)行狀態(tài)的指標(biāo)。此類指標(biāo)只有出現(xiàn)瓶頸時才可能會影響上層業(yè)務(wù)，但很難定義出與上層業(yè)務(wù)之間明確的必然性以及關(guān)聯(lián)度，如：CPU使用率、內(nèi)存使用率、IOPS、網(wǎng)卡發(fā)送速度等指標(biāo)。此類指標(biāo)無業(yè)務(wù)含義，重點體現(xiàn)的是基礎(chǔ)設(shè)施資源的運(yùn)行狀態(tài)，而指標(biāo)的異常也無法明確對上層業(yè)務(wù)的具體影響。由于比較通用，這類指標(biāo)可通過公共能力統(tǒng)一提供。角視用應(yīng)務(wù)用業(yè)應(yīng)端日志指標(biāo)事件終APP瀏覽器撥測運(yùn)營數(shù)據(jù)移動端JS錯誤云撥測異常分析用戶旅程用業(yè)務(wù)數(shù)據(jù)應(yīng)務(wù)日志指標(biāo)trace事件業(yè)全局拓?fù)滏溌纷粉櫞a級診斷例Profiling多語言接入實務(wù)服云實例可觀測日志指標(biāo)事件容器集群可觀測中間件可觀測集群監(jiān)控Pod監(jiān)控消息隊列RDS角節(jié)點監(jiān)控網(wǎng)絡(luò)監(jiān)控GaussDB緩存視源池資臺源基礎(chǔ)設(shè)施可觀測日志指標(biāo)事件平資管理虛擬機(jī)操作系統(tǒng)主機(jī)存儲網(wǎng)絡(luò)

綜上所述，構(gòu)建核心應(yīng)用的可觀測體系，應(yīng)該從業(yè)務(wù)應(yīng)用視角到云平臺資源視角進(jìn)行分層設(shè)計。應(yīng)用視角主要包含終端層和應(yīng)用層，基于應(yīng)用的核心功能，由業(yè)務(wù)開發(fā)人員、運(yùn)維人員、測試人員組成“鐵三角”共同設(shè)計。云平臺資源層主要包含PaaS層實例和IaaS層基礎(chǔ)設(shè)施，由云平臺提供開箱即用的標(biāo)準(zhǔn)SLI指標(biāo)，應(yīng)用指標(biāo)和資源指標(biāo)匯聚接入到應(yīng)用可觀測平臺中，由應(yīng)用可觀測平臺統(tǒng)一對外呈現(xiàn)。應(yīng)用可觀測平臺終端體驗類指標(biāo)端側(cè)數(shù)據(jù)采集端側(cè)體驗類撥測端側(cè)運(yùn)行監(jiān)控應(yīng)用黃金指標(biāo)應(yīng)用數(shù)據(jù)匯聚應(yīng)用請求成功率應(yīng)用功能響應(yīng)時延應(yīng)用請求吞吐量云實例可用性指標(biāo)云實例數(shù)據(jù)匯聚實例可連接性實例讀寫時延實例狀態(tài)基礎(chǔ)設(shè)施指標(biāo)資源池數(shù)據(jù)匯聚 CPU利用率內(nèi)存利用率網(wǎng)絡(luò)帶寬使用率存儲IO使用率圖2.8四層指標(biāo)體系16極簡信息匯聚，一站式觸達(dá)運(yùn)維態(tài)勢，提升運(yùn)維體驗監(jiān)控匯聚狀態(tài)可視：展現(xiàn)被管對象及內(nèi)部組件的和故障處理效率告警信息?；诟婢梢钥焖俑兄獙ο蟮漠惓钊缜八?，金融客戶在日常運(yùn)維信息的獲取上，存在態(tài)；此外，運(yùn)維平臺還應(yīng)支持查看被管對象及內(nèi)兩個關(guān)鍵痛點，一是運(yùn)維體驗圍繞功能展開，對運(yùn)維部組件的指標(biāo)信息。對象的操作需要在不同界面來回切換，體驗不暢；二是信息分散，比如描述狀態(tài)的告警指標(biāo)信息、用于定拓?fù)潢P(guān)聯(lián)故障定界：展現(xiàn)被管對象與內(nèi)部組件、位的日志和調(diào)用鏈信息、各類操作的狀態(tài)信息需要從底層部署依賴、周邊調(diào)用依賴等關(guān)系的拓?fù)鋱D，不同的運(yùn)維界面上獲取，導(dǎo)致故障處理效率低。因此并在拓?fù)鋱D中展示各個對象的告警狀態(tài)。創(chuàng)建的需要持續(xù)構(gòu)建極簡信息獲取的能力，使運(yùn)維人員可以拓?fù)鋺?yīng)包括應(yīng)用的物理拓?fù)洹⒃品?wù)物理拓?fù)?、快速獲取所需的運(yùn)維態(tài)勢信息，從而提升運(yùn)維體驗和云服務(wù)部署拓?fù)涞取Ｍㄟ^對關(guān)聯(lián)對象的異常狀態(tài)故障處理效率，進(jìn)而解決企業(yè)運(yùn)維要求高和運(yùn)維能力分析，可以支撐運(yùn)維人員進(jìn)行故障定界。不足的矛盾。組件分析逐層下鉆：故障定界定位猶如抽絲剝極簡信息獲取的設(shè)計理念繭，極簡運(yùn)維要支持從故障表現(xiàn)的點開始，對齊信息集約：面向運(yùn)維對象進(jìn)行運(yùn)維操作功能的體內(nèi)部組件和依賴資源，逐步、逐層進(jìn)行下鉆分驗設(shè)計，例如，在同一個操作界面上集成運(yùn)維對析，一步步接近問題根因。象的狀態(tài)信息、組件關(guān)聯(lián)、操作維護(hù)等信息。操作維護(hù)快速直達(dá)：集成被管對象的常見操作，對象關(guān)聯(lián)：圍繞同一個運(yùn)維對象，可向下關(guān)聯(lián)依如自動作業(yè)、節(jié)點診斷、撥測等，在日常運(yùn)維和賴的容器、物理設(shè)備等底層資源信息，向上關(guān)聯(lián)故障處理時，能夠快速完成操作。被依賴的應(yīng)用組件信息，從而快速獲取與該運(yùn)維對象相關(guān)聯(lián)的運(yùn)維信息。2.1.2基于故障模式庫和云網(wǎng)一體化運(yùn)維實現(xiàn)確定性故障恢復(fù)逐層下鉆：在呈現(xiàn)運(yùn)維狀態(tài)信息時，界面應(yīng)圍繞運(yùn)維對象關(guān)系，展示逐層下鉆的內(nèi)部組件和依賴確定性故障恢復(fù)需要從應(yīng)用系統(tǒng)視角和云平臺資源視資源相關(guān)的分析信息，以便逐步逼近問題根因。角分別定義。一致體驗：所有被管理對象都有一致的全景360視基于云服務(wù)故障模式基線庫，對云服務(wù)實例進(jìn)行全面圖體驗，從一個關(guān)聯(lián)對象可以一鍵跳轉(zhuǎn)至其全景診斷，以便精確定位、快速恢復(fù)故障360監(jiān)控信息界面。應(yīng)用可觀測平臺感知故障之后，通過指標(biāo)的匯聚和算法處理，可以對故障進(jìn)行初步的定界，輸出可能存在極簡信息獲取的目標(biāo)效果故障的資源實例，此時需要云平臺具備針對資源實例運(yùn)維信息展示要能夠圍繞運(yùn)維對象進(jìn)行匯聚，使運(yùn)維端到端的精確故障診斷和快速恢復(fù)能力。實現(xiàn)資源實人員可以方便且快速獲取需要的運(yùn)維信息。例的診斷，需要大量的運(yùn)維專家經(jīng)驗，從實例的資源、依賴、歷史故障模式等多個維度進(jìn)行分析，因?qū)ο鬆顟B(tài)一屏概覽：被管對象概覽界面，要能夠此，構(gòu)建云服務(wù)的故障模式庫至關(guān)重要。展示對象關(guān)鍵信息，包括基本信息、告警、關(guān)鍵指標(biāo)等內(nèi)容。故障模式庫生成機(jī)制故障模式庫是在產(chǎn)品設(shè)計階段，對構(gòu)成產(chǎn)品的組件進(jìn)17行逐一分析，找出潛在的失效模式，并分析其可能造成的影響，根據(jù)組件的薄弱環(huán)節(jié)，輸出的預(yù)防措施列表。構(gòu)建一個完善的故障模式庫需要至少包含如下三個方面：白盒化的故障模式分析：端到端梳理組件架構(gòu)，根據(jù)組件在架構(gòu)中的位置，分析可能的故障點。梳理云服務(wù)核心功能，并和組件架構(gòu)有機(jī)結(jié)合，以實現(xiàn)對某一核心功能對應(yīng)故障點的可視化呈現(xiàn)。此外，還應(yīng)規(guī)劃對應(yīng)故障點的自動化診斷、一鍵式恢復(fù)能力。黑盒化的功能性撥測：包括關(guān)鍵進(jìn)程和端口的探測、網(wǎng)絡(luò)組件交互性撥測、及AA集群流量負(fù)載均衡的診斷?，F(xiàn)網(wǎng)歷史故障補(bǔ)充：基于產(chǎn)品組件在現(xiàn)網(wǎng)中的歷史重大故障進(jìn)行逆向覆蓋，確保重大質(zhì)量問題全覆蓋，改進(jìn)措施對應(yīng)指標(biāo)可診斷?？墒褂孟到y(tǒng)級FMEA(failuremodeandeffectanalysis，失效模式及效應(yīng)分)故障模式分析流程持

確定分析對象 建立框圖描述系統(tǒng)功能 故障模式清單定義嚴(yán)酷等級 FMEA分析圖2.9系統(tǒng)級FMEA故障模式分析流程續(xù)積累故障模式庫。故障模式庫的推廣機(jī)制梳理故障模式庫只是故障處理的一種手段，讓站點能夠基于故障模式庫快速診斷、恢復(fù)故障才是最終目的。因此基于故障模式庫中定義的每一種故障模式都需要開發(fā)對應(yīng)的內(nèi)容包，內(nèi)容包中應(yīng)至少包含一套診斷腳本和一套恢復(fù)腳本。故障模式內(nèi)容包應(yīng)該與產(chǎn)品解耦，既可以集成到產(chǎn)品中支持新建站點的開箱即用，又可以單獨發(fā)布支撐存量站點的持續(xù)迭代更新。針對一類服務(wù)的某個核心功能的故障模式庫梳理產(chǎn)品對象故障模式描述云服務(wù)名稱核心功能點故障對象故障模式故障影響嚴(yán)酷等級觀測方式應(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)控實例活躍客戶端調(diào)整實例最大連接數(shù)連接數(shù)超規(guī)格故障模式適配包開發(fā)├─resource_{云服務(wù)索引}_{version}.zip #故障適配包│├─alarm #告警目錄││├─{云服務(wù)索引}_alarm.json #告警靜態(tài)信息│├─monitor #監(jiān)控目錄│├─script #非必選│││├─config.json #配置腳本范圍│││├─{script} #腳本邏輯│├─operations #運(yùn)維操作目錄│││├─actions.json #操作配置││├─i18n #國際化目錄│├─autoops #自動作業(yè)目錄││├─operations #操作目錄││├─flows #編排目錄││├─i18n #國際化目錄

包故障模式適配包推廣容內(nèi)式模開箱障十統(tǒng)一新建即用故適配包站點運(yùn)維持續(xù)存量治理包站點迭代圖2.10故障模式庫推廣機(jī)制故障模式庫運(yùn)行機(jī)制運(yùn)維人員在運(yùn)維平臺上針對故障進(jìn)行一鍵式診斷，對于診斷不通過項，進(jìn)行一鍵式故障恢復(fù)。這樣可以減少運(yùn)維人員對環(huán)境接入及運(yùn)維能力的依賴，使他們可以更加聚焦業(yè)務(wù)?？乜貥I(yè)分布式緩存服務(wù)關(guān)系數(shù)據(jù)庫服務(wù)XXX服務(wù)監(jiān)監(jiān)作警標(biāo)動告指自狀態(tài)診斷腳本狀態(tài)診斷腳本狀態(tài)診斷腳本信息收集腳本信息收集腳本信息收集腳本局點運(yùn)維人員快速恢復(fù)腳本快速恢復(fù)腳本快速恢復(fù)腳本圖2.11故障模式庫運(yùn)行機(jī)制19圖2.12一鍵式故障診斷恢復(fù)示例云網(wǎng)一體化運(yùn)維實現(xiàn)應(yīng)用、虛擬鏈路、物理路由的 用端點無損監(jiān)測和iFIT真實業(yè)務(wù)流鏈路監(jiān)測兩大核一致性監(jiān)控和運(yùn)維 心功能實現(xiàn)。云網(wǎng)一體化運(yùn)維是指將云計算與網(wǎng)絡(luò)技術(shù)相結(jié)合，對云計算環(huán)境中的網(wǎng)絡(luò)資源進(jìn)行統(tǒng)一管理和維護(hù)的 虛擬&物理網(wǎng)絡(luò)可視診斷定界：主要通過Cloud-一種模式。在這種模式下，網(wǎng)絡(luò)管理員可以通過云 NetDebug虛擬網(wǎng)絡(luò)撥測和FabricInsight物理計算平臺提供的工具和接口，對網(wǎng)絡(luò)資源進(jìn)行實時 網(wǎng)絡(luò)定界兩大核心功能實現(xiàn)。監(jiān)控、故障排查、性能優(yōu)化等操作。（一）應(yīng)用網(wǎng)絡(luò)真實業(yè)務(wù)流一屏監(jiān)控云網(wǎng)一體化運(yùn)維的實現(xiàn)依賴于云平臺和網(wǎng)絡(luò)設(shè)備的協(xié)同工作，云平臺需要提供相應(yīng)的API接口，以便管 1）eBPF應(yīng)用端點無損監(jiān)測理員可以訪問和操作網(wǎng)絡(luò)資源，同時網(wǎng)絡(luò)設(shè)備也需 eBPF是一種在Linux內(nèi)核中運(yùn)行的虛擬機(jī)，它允許要支持相應(yīng)的功能，如網(wǎng)絡(luò)監(jiān)控、故障診斷、流量 用戶在不修改內(nèi)核源代碼的情況下，動態(tài)地加載和分析等，以實現(xiàn)對網(wǎng)絡(luò)資源的有效管理，從而實現(xiàn) 執(zhí)行代碼。eBPF最初是為了網(wǎng)絡(luò)數(shù)據(jù)包過濾而設(shè)云上Overlay資源與Underlay網(wǎng)絡(luò)設(shè)備的統(tǒng)一運(yùn) 計，已擴(kuò)展到其他領(lǐng)域，如安全、跟蹤和性能分維。 析。云網(wǎng)一體化運(yùn)維通過如下兩個機(jī)制實現(xiàn)高效監(jiān)控與問題定位： eBPF的運(yùn)維涉及到許多方面，包括部署、監(jiān)控、調(diào)試和排查。具體的實現(xiàn)機(jī)制是：eBPF以字節(jié)碼形式應(yīng)用網(wǎng)絡(luò)真實業(yè)務(wù)流一屏監(jiān)控：主要通過eBPF應(yīng) 注入到應(yīng)用內(nèi)核中并掛載到特定鉤子(hook)掛載點20上。當(dāng)內(nèi)核或應(yīng)用程序執(zhí)行到某個掛載點時，產(chǎn)生特定事件并觸發(fā)程序運(yùn)行。eBPF技術(shù)的代碼無侵入、語言無關(guān)、高性能、強(qiáng)關(guān)聯(lián)、數(shù)據(jù)端到端覆蓋等特征，可滿足可觀測性標(biāo)準(zhǔn)和觀測數(shù)據(jù)采集的要求。BPFProgramReaderLLVM/ClangProg.bfpBytecodeUserspacebpfKernelbpfeBPFBPFMapsBPFBytecodeVerifier+JITKernelFunctionsNativeCode圖2.13eBPF掛載原理

基于eBPF內(nèi)核觀測技術(shù)生成的網(wǎng)絡(luò)級丟包、時延、吞吐量等方面指標(biāo)，可以實現(xiàn)流級的應(yīng)用路況可視化監(jiān)控能力。應(yīng)用訪問拓?fù)淇梢暎涸L問關(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ò)的智能運(yùn)維。iFIT主要基于在被檢測業(yè)務(wù)流報文中添加iFIT檢測頭，實現(xiàn)隨流的業(yè)務(wù)質(zhì)量檢測，反映業(yè)務(wù)流的真實業(yè)務(wù)質(zhì)量。R1(Source) 1588v2/G8275.1R2(Destination)Tx[i+1] Tx[i] Rx[i+1] Rx[i]000111110000010001110100001T:染色周期每周期統(tǒng)計點后移，屏蔽亂序干擾：T+6T/10，后移6T/10時點圖2.14iFIT監(jiān)測原理21借鑒IPFPM(FlowPerformanceMeasurement，部署，自動按需E2E/逐跳檢測流性能測量)染色機(jī)制，iFIT染色報文帶內(nèi)測量技術(shù)可以構(gòu)建流級的網(wǎng)絡(luò)路況追蹤和診斷能力，實現(xiàn)基丟包位置：基于每節(jié)點的報文計數(shù)，分析丟包點于包粒度的真實業(yè)務(wù)流全鏈路檢測。這項技術(shù)具有以下幾方面特點：逐跳時延/抖動：基于每節(jié)點的時戳記錄，分析鏈路/節(jié)點時延支持多種業(yè)務(wù)場景：L3VPN/EVPN/SRv6/SR-MPLS/MPLS路徑還原：基于每節(jié)點上報信息，呈現(xiàn)業(yè)務(wù)真實路徑易部署運(yùn)維：頭節(jié)點按需定制，中間/尾節(jié)點一次圖2.15iFIT業(yè)務(wù)流監(jiān)測實例如圖所示，實例中實現(xiàn)了網(wǎng)絡(luò)丟包、時延、抖動、帶寬等真實業(yè)務(wù)流路徑的可視監(jiān)控。（二）虛擬&物理網(wǎng)絡(luò)可視診斷定界1）CloudNetDebug虛擬網(wǎng)絡(luò)撥測CloudNetDebug是面向運(yùn)維人員的虛擬網(wǎng)絡(luò)診斷工具，幫助網(wǎng)絡(luò)管理員和開發(fā)人員快速診斷和解決云網(wǎng)絡(luò)中的問題。通過收集和分析云網(wǎng)絡(luò)中的數(shù)據(jù)包、流量和性能指標(biāo)等信息，提供全面的視圖，使用戶能夠快速定位和解決網(wǎng)絡(luò)問題，包括數(shù)據(jù)包捕獲、流量分析、集成撥測和抓包、性能監(jiān)測和故障排查等。通過客戶報文模擬撥測，應(yīng)用報文抓取等方式，實現(xiàn)可視化撥測快速診斷定界。22正常周期撥測---覆蓋所有鏈路CNA1①vRouter1BorderRouter1CNA2交換機(jī)1vRouter2交換機(jī)3BorderRouter2···············BMSGW1交換機(jī)2ENAT1交換機(jī)4BorderRouter15BMSGW2預(yù)置探針ENAT2BorderRouter16出現(xiàn)故障場景---自動匯聚告警CNA1vRouter1BorderRouter1②CNA2交換機(jī)1vRouter2交換機(jī)3BorderRouter2···············ENAT1交換機(jī)4BorderRouter15BMSGW1交換機(jī)2BMSGW2預(yù)置探針ENAT2BorderRouter16圖2.16CloudNetDebug撥測原理軟件撥測定位是利用染色標(biāo)記技術(shù)主動撥測抓包，通過跟蹤染色報文經(jīng)過的路徑，覆蓋資源(IP)>虛擬交換網(wǎng)絡(luò)>物理交換網(wǎng)絡(luò)進(jìn)行全景網(wǎng)絡(luò)拓?fù)涞目梢暬瘬軠y診斷。實際應(yīng)用中，有如下兩種監(jiān)控診斷模式：LinkMonitor主動鏈路監(jiān)控：通過在計算節(jié)點創(chuàng)建探針，創(chuàng)建出VPCL2、VPCL3、VPC-Peering、EIP和DC流量的撥測任務(wù)，自動周期性探測虛擬網(wǎng)元的轉(zhuǎn)發(fā)質(zhì)量，以及網(wǎng)絡(luò)服務(wù)的鏈路質(zhì)量，從被動問題處理轉(zhuǎn)變?yōu)橹鲃影l(fā)現(xiàn)鏈路質(zhì)量問題，進(jìn)而提前發(fā)現(xiàn)問題風(fēng)險點。FullLink全鏈路診斷：進(jìn)行全鏈路復(fù)雜流量疊加場景的網(wǎng)絡(luò)問題定位。通過控制面診斷租戶的云服務(wù)配置、路由表、安全組和網(wǎng)絡(luò)ACL等配置，檢測每個網(wǎng)元的時延和丟包率實現(xiàn)虛擬網(wǎng)絡(luò)診斷。

物理網(wǎng)絡(luò)診斷通過調(diào)用FabricInsight的接口獲取業(yè)務(wù)流路徑指標(biāo)，包括流狀態(tài)以及交換機(jī)異常信息等，實現(xiàn)從控制面>虛擬網(wǎng)絡(luò)>物理網(wǎng)絡(luò)的三層穿透故障診斷。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)化機(jī)會。此外，F(xiàn)abricInsight工具還支持多種物理設(shè)備組網(wǎng)的管理、控制和分析，支持網(wǎng)絡(luò)仿真校驗及虛擬感知，支持NetConf，OpenFlow，OVSDB，SNMP等協(xié)議，從而實現(xiàn)物理和虛擬網(wǎng)絡(luò)設(shè)備的可視化管理。23網(wǎng)絡(luò)路徑設(shè)備KPI故障風(fēng)險TCPSYN/FIN/RST報文采集丟包/時延變更檢測逐跳真實路徑還原網(wǎng)絡(luò)路況分析TCP連通性分析關(guān)聯(lián)逐跳故障分析關(guān)聯(lián)逐跳網(wǎng)絡(luò)質(zhì)量分析VM逐跳配置變更檢測VMVMVMVMVMVMVMVM自動輸出故障定位結(jié)論VMVMVMVM圖2.17FabricInsight物理網(wǎng)絡(luò)故障定界硬件診斷定位是通過業(yè)務(wù)物理路徑指標(biāo)，包括流狀分析指標(biāo)、日志、告警、配置、容量等運(yùn)維數(shù)態(tài)以及交換機(jī)設(shè)備故障、鏈路故障、轉(zhuǎn)發(fā)過載等，據(jù)，從風(fēng)險隱患、性能規(guī)格、系統(tǒng)容量、系統(tǒng)可靠實現(xiàn)業(yè)務(wù)流路徑物理網(wǎng)絡(luò)端到端路徑的可視及異常性、最佳實踐、版本生命周期、安全漏洞等多個定位。維度對系統(tǒng)進(jìn)行全面的評估。Fabric內(nèi)業(yè)務(wù)流路徑可視：通過關(guān)聯(lián)分析逐跳設(shè)變更風(fēng)險控制：通過建立變更前的風(fēng)險識別和評備信息感知故障斷點，故障一鍵式診斷，定位網(wǎng)審機(jī)制，提前識別變更的潛在風(fēng)險；通過自動化絡(luò)路由、策略類故障根因。及漸進(jìn)式的變更過程，確保變更不引入風(fēng)險。質(zhì)差主動發(fā)現(xiàn)：基于網(wǎng)絡(luò)路況開放，實現(xiàn)應(yīng)用網(wǎng)未知風(fēng)險挖掘：通過混沌工程識別系統(tǒng)的薄弱環(huán)絡(luò)協(xié)同，通過技術(shù)分析微突發(fā)、丟包、光模塊異節(jié)并改進(jìn)，持續(xù)提升系統(tǒng)韌性。常等現(xiàn)象快速定界定位問題。變“被動救火”為主動預(yù)防，構(gòu)建運(yùn)行態(tài)風(fēng)險主動2.1.3基于一體化風(fēng)險庫和混沌工程進(jìn)行預(yù)防體系預(yù)見性風(fēng)險治理面向未來，“被動救火”式運(yùn)維將成為過去式，主預(yù)見性風(fēng)險治理是一種前瞻性的風(fēng)險管理方法，旨動運(yùn)維將成為保障系統(tǒng)高可用的重要手段在通過事前的預(yù)測和診斷識別潛在風(fēng)險，提前制定《史記》曾載，魏文侯問扁鵲“你們?nèi)值苷l的醫(yī)風(fēng)險消減措施，保障系統(tǒng)的穩(wěn)定運(yùn)行。根據(jù)風(fēng)險場術(shù)最為高明？”扁鵲言“長兄最善，中兄次之，扁景，預(yù)見性風(fēng)險治理主要分為運(yùn)行態(tài)風(fēng)險預(yù)防，變鵲為下。”文侯好奇道“何出此言？”扁鵲答“大更風(fēng)險控制和未知風(fēng)險挖掘三部分內(nèi)容。哥治病，常以望聞問切，診斷隱患，在病害形成之前就能鏟除病因，因此一般人不知道大哥的厲害，運(yùn)行態(tài)風(fēng)險預(yù)防：建立完善的運(yùn)行態(tài)風(fēng)險主動預(yù)是以聲名不顯。二哥治病于初起之時，大家以為他防體系，定期進(jìn)行風(fēng)險評估和監(jiān)測。通過收集和只能看看小病，所以他只聞名于鄉(xiāng)里。而我治病于24嚴(yán)重之時，用針刺猛藥，救人于危機(jī)之時，所以大家都以為我醫(yī)術(shù)最高明，因此名傳天下。上工治未病，扁鵲長兄治病于未發(fā)，是為事前；中兄治病于漸發(fā)，是為事中；扁鵲治病于嚴(yán)重，是為事后。治病如此，運(yùn)維亦是如此。運(yùn)維的核心目標(biāo)是保障業(yè)務(wù)可用，減少和避免故障發(fā)生。傳統(tǒng)的救火式運(yùn)維，運(yùn)維人員的工作內(nèi)容和工作重心往往聚焦在事件和故障處理，偏向事后，這種運(yùn)維方式無異于減少和避免故障，無法滿足現(xiàn)代化云運(yùn)維的要求。從故障事前、事中和事后的角度看，事后恢復(fù)不如事中控制，事中控制不如事前預(yù)防。因此，必須摒棄傳統(tǒng)的救火式運(yùn)維，變被動為主動，預(yù)防和減少故障發(fā)生，防患于未然。建設(shè)金融云風(fēng)險主動預(yù)防體系，實現(xiàn)站點故障早發(fā)現(xiàn)主動運(yùn)維并不是一個新鮮的概念，但在大部分的企業(yè)中，主動運(yùn)維仍是一句口號，對于一個云平臺，如何能讓主動運(yùn)維真正落地并產(chǎn)生效果？本質(zhì)上來講，主動運(yùn)維的目的在于事前預(yù)防，治病于未發(fā)是關(guān)鍵，因此需要重點構(gòu)建事前的風(fēng)險識別和預(yù)防能力。1986年，美國挑戰(zhàn)者號航天飛機(jī)發(fā)射后發(fā)生爆炸，事故造成7名宇航員喪生，發(fā)射活動以失敗告終。為了實現(xiàn)故障先預(yù)警，隱患早發(fā)現(xiàn)，NASA建立了航天器故障預(yù)防診斷平臺，旨在提前通過診斷檢查發(fā)現(xiàn)異常事件，保障航天器可靠運(yùn)行，避免事故發(fā)生。對于云平臺這種大型的分布式軟件系統(tǒng)來說，建立風(fēng)險檢測預(yù)防機(jī)制同樣是重中之重。傳統(tǒng)IT系統(tǒng)的風(fēng)險主動預(yù)防通常會以產(chǎn)品化的方式發(fā)布巡檢工具，通過在現(xiàn)網(wǎng)部署巡檢工具進(jìn)行巡檢來識別風(fēng)險，這種方式受限于工具的發(fā)布節(jié)奏，風(fēng)險無法實時更新，無法保證現(xiàn)網(wǎng)時刻都可以應(yīng)用到最新的風(fēng)險庫。

金融云風(fēng)險主動預(yù)防機(jī)制的核心思想是通過構(gòu)筑中心化的風(fēng)險庫，從風(fēng)險規(guī)則的生成、風(fēng)險診斷到風(fēng)險的預(yù)警推送，構(gòu)筑服務(wù)化的風(fēng)險主動預(yù)防能力。實施層面可按如下思路展開建設(shè)：構(gòu)建中心化風(fēng)險庫構(gòu)建中心化風(fēng)險庫的目的在于將風(fēng)險集中管理，防止風(fēng)險管理的無序和散亂。風(fēng)險庫的建設(shè)需遵循全面性、實時性和持續(xù)性原則。全面性：風(fēng)險庫需要涵蓋明確的風(fēng)險類型和范圍，如產(chǎn)品缺陷、性能過載、組網(wǎng)非標(biāo)、配置隱患、版本配套、硬件適配、安全漏洞等，確保風(fēng)險范圍覆蓋全面，防止遺漏。實時性：風(fēng)險動態(tài)實時更新，即風(fēng)險從發(fā)現(xiàn)到入庫的時效性需要得到保證，確保現(xiàn)網(wǎng)應(yīng)用的風(fēng)險庫時刻保持最新。持續(xù)性：制定明確的風(fēng)險庫管理制度，包括風(fēng)險庫的更新和維護(hù)機(jī)制，確保風(fēng)險庫的有效運(yùn)行和持續(xù)更新。建立風(fēng)險評估機(jī)制風(fēng)險評估機(jī)制是通過收集和分析信息數(shù)據(jù)，結(jié)合風(fēng)險庫規(guī)則來識別風(fēng)險隱患的過程，其目的是為了有效地識別系統(tǒng)風(fēng)險。風(fēng)險評估機(jī)制的主要步驟包括：信息收集：收集生產(chǎn)環(huán)境的指標(biāo)、日志、告警、配置、資源、容量等運(yùn)維數(shù)據(jù)，作為風(fēng)險診斷分析的數(shù)據(jù)輸入。診斷分析：對收集的運(yùn)維數(shù)據(jù)進(jìn)行分析診斷，識別系統(tǒng)劣化指標(biāo)，匹配風(fēng)險庫規(guī)則進(jìn)行風(fēng)險冒泡，評估風(fēng)險等級及影響，輸出健康度評估報告。253.建立風(fēng)險預(yù)警流程變更前建立完善的風(fēng)險預(yù)警機(jī)制，通過定期的風(fēng)險評估報告 -變更準(zhǔn)入：建立變更準(zhǔn)入機(jī)制，在變更申請階段方式將風(fēng)險預(yù)警推送到現(xiàn)網(wǎng)，確保風(fēng)險信息可以及時 對變更的準(zhǔn)入條件進(jìn)行控制，包括變更必要性評準(zhǔn)確地傳遞給相關(guān)組織。同時，提供相應(yīng)的風(fēng)險規(guī)避 估，標(biāo)準(zhǔn)化變更方案制定，變更影響分析，回退措施，持續(xù)跟蹤風(fēng)險在現(xiàn)網(wǎng)的閉環(huán)情況。 方案、變更授權(quán)等；基于變更模型提前攔截變更態(tài)風(fēng)險，通過全流程自 -風(fēng)險識別：變更前對變更風(fēng)險進(jìn)行識別，包括變動化實現(xiàn)變更態(tài)風(fēng)險有效控制 更歷史問題風(fēng)險、變更方案風(fēng)險、業(yè)務(wù)影響風(fēng)變更風(fēng)險控制是系統(tǒng)變更過程中至關(guān)重要的一環(huán)， 險、高危操作風(fēng)險等；旨在減少因系統(tǒng)變更而帶來的不利影響，提高變更的成功率。隨著業(yè)務(wù)數(shù)量和業(yè)務(wù)規(guī)模的持續(xù)擴(kuò)大， -變更評審：變更評審階段，由評審人對變更方案現(xiàn)網(wǎng)的變更數(shù)量和變更頻次不斷增長，而頻繁的變 和變更風(fēng)險進(jìn)行評審，確保變更實施方案正確，更常常會給運(yùn)維帶來不可預(yù)知的風(fēng)險。據(jù)數(shù)據(jù)統(tǒng) 變更影響和變更風(fēng)險評估準(zhǔn)確。計，70%的線上故障都是由變更引起，變更可能引起功能失效、性能下降、數(shù)據(jù)丟失甚至系統(tǒng)崩潰。 變更中如何有效管控變更風(fēng)險，是運(yùn)維工作面臨的巨大挑 -灰度變更：構(gòu)筑變更實施階段的灰度變更能力，戰(zhàn)。面向現(xiàn)代化的變更風(fēng)險控制能力構(gòu)建可按下面 按需控制變更范圍，可以盡早發(fā)現(xiàn)并解決變更問思路進(jìn)行考量： 題，有效降低變更帶來的風(fēng)險；1.變更風(fēng)險控制需要在變更的不同階段構(gòu)筑不同的 -風(fēng)險控制：在變更實施過程中控制變更操作的風(fēng)控制能力 險。對于高危操作、未授權(quán)操作實施攔截，對于變更過程中的異常和非預(yù)期結(jié)果，應(yīng)實施變更自動終止操作。26-變更監(jiān)控：對變更過程實施監(jiān)控，通過狀態(tài)、指 流程，使得變更在各個階段都能得到有效的跟蹤和控標(biāo)和告警，快速發(fā)現(xiàn)變更帶來的非預(yù)期影響。 制。變更后變更申請階段，基于變更模型創(chuàng)建變更申請單，-安全回退：構(gòu)筑變更回退能力，包括變更全量回 變更申請單自動獲取變更模型關(guān)聯(lián)的風(fēng)險規(guī)則，退以及按階段、按工步的局部回退，支持靈活的 同時根據(jù)風(fēng)險規(guī)則識別變更風(fēng)險。風(fēng)險規(guī)則可以回退策略制定； 是特定的匹配規(guī)則或腳本，通過自動化流程運(yùn)行風(fēng)險規(guī)則或腳本，給出本變更所識別出的風(fēng)險集-撥測驗證：建立變更后的業(yè)務(wù)撥測能力，在變更 合。后通過業(yè)務(wù)撥測驗證變更業(yè)務(wù)是否可用，及時發(fā)現(xiàn)問題。 變更評審階段，對于變更單所識別變更風(fēng)險的閉環(huán)情況進(jìn)行審核，確保變更風(fēng)險全部閉環(huán)，變更2.建立變更模型+風(fēng)險規(guī)則的風(fēng)險識別機(jī)制，確保變 流程才能進(jìn)入變更實施階段。在變更申請和變更更風(fēng)險提前識別 評審階段，重點構(gòu)筑變更風(fēng)險的識別和攔截能首先，對不同類型的變更建立不同的變更模型，并對 力。變更模型設(shè)定相應(yīng)的風(fēng)險規(guī)則，風(fēng)險規(guī)則可來源于此類型變更的歷史問題和專家經(jīng)驗，或與此類變更相關(guān) 變更實施階段，基于工具構(gòu)筑自動化變更及控制的狀態(tài)、指標(biāo)和配置等。 能力。工具應(yīng)具備作業(yè)編排、灰度分批、高危攔截、熔斷回退等核心功能。灰度分批變更典型的此外，應(yīng)建立變更模型和風(fēng)險規(guī)則的關(guān)聯(lián)機(jī)制，持續(xù) 應(yīng)用形式通常如下：積累風(fēng)險規(guī)則，通過工具能力自動識別風(fēng)險，使得風(fēng)險識別不依賴人，基于變更模型建立標(biāo)準(zhǔn)化的風(fēng)險識 -灰度測試環(huán)境：提供獨立的灰度壞境。變更在生別流程和能力，確保變更前風(fēng)險有效識別。 產(chǎn)環(huán)境實施前，在灰度環(huán)境上提前實施變更，進(jìn)行業(yè)務(wù)驗證；3.基于流程和工具構(gòu)筑變更風(fēng)險控制能力，確保風(fēng)險控制有效落地 -生產(chǎn)環(huán)境分批實施：在生產(chǎn)環(huán)境中分批實施變具體來說，應(yīng)建立數(shù)字化的變更流程系統(tǒng)，從變更申 更，優(yōu)先選擇小范圍、重要性較低或影響可控對請、變更評審、變更實施到變更驗證建立完善的變更 象實施變更，根據(jù)變更結(jié)果逐步放開批次。程推送、閉環(huán)執(zhí)行腳本/規(guī)則流變更實施風(fēng)險評審識別風(fēng)險創(chuàng)建變更單拉取風(fēng)險信息導(dǎo)入型模變更模型風(fēng)險腳本/規(guī)則圖2.18變更申請、評審流程27變更作業(yè)流水線變更作業(yè)子流程N(yùn)變更作業(yè)子流程N(yùn)+1生產(chǎn)批安全回滾灰度批批次2準(zhǔn)入條件批次1生產(chǎn)批預(yù)檢查灰度批批次2安全回滾準(zhǔn)入條件批次1預(yù)檢查安全回滾工具能力模板編排 灰度分批 高危攔截熔斷機(jī)制 安全回滾 生產(chǎn)驗證圖2.19典型灰度分批變更應(yīng)用形式變更驗證階段，通過功能驗證、業(yè)務(wù)撥測等驗證從系統(tǒng)架構(gòu)層面，混沌工程可以驗證系統(tǒng)的容錯能手段，對變更后的業(yè)務(wù)進(jìn)行可用性驗證，及時發(fā)力，推動提升系統(tǒng)的架構(gòu)可用性；測試層面，混沌現(xiàn)可能的風(fēng)險。工程可以提前暴露線上問題，防止帶病上線；運(yùn)維層面，混沌工程可以讓我們更好地理解和掌握系統(tǒng)基于混沌工程挖掘未知風(fēng)險，識別系統(tǒng)薄弱環(huán)節(jié)，的運(yùn)行邏輯和規(guī)律，提升應(yīng)急恢復(fù)效率，降低故障持續(xù)提升系統(tǒng)韌性影響和損失，增強(qiáng)團(tuán)隊?wèi)?yīng)急能力，建立系統(tǒng)抵御未知風(fēng)險的信心。混沌工程核心思想：識別系統(tǒng)隱患，減少故障影響，提升系統(tǒng)韌性混沌工程的實施實踐混沌工程實踐可以按照如下步驟開展：混沌工程是一種實驗性的可靠性工程提升方法，是通過主動模擬故障場景來驗證系統(tǒng)在各種異常場景下的制定試驗?zāi)繕?biāo)行為，通過比較假設(shè)行為和實際行為，發(fā)現(xiàn)系統(tǒng)存在開展混沌演練之前，首先需要明確試驗?zāi)繕?biāo)及假的薄弱環(huán)節(jié)。在復(fù)雜的分布式系統(tǒng)中，交互關(guān)系和服設(shè)，確保實驗的有效性及針對性。例如，驗證某務(wù)依賴錯綜復(fù)雜，難免會出現(xiàn)各種不可預(yù)料的突發(fā)事應(yīng)用系統(tǒng)在過載場景下的保護(hù)機(jī)制，假設(shè)當(dāng)流量件，系統(tǒng)越復(fù)雜，越容易出現(xiàn)無法預(yù)知的故障?；煦邕^載時，系統(tǒng)的哪些指標(biāo)會發(fā)生什么變化，預(yù)期工程旨在提前識別系統(tǒng)的未知風(fēng)險，針對性地進(jìn)行防會有什么保護(hù)措施會觸發(fā)等。范加強(qiáng)，讓系統(tǒng)在每一次故障中獲益，不斷優(yōu)化，持續(xù)提升系統(tǒng)的韌性，保障業(yè)務(wù)的連續(xù)可用。28故障模式分析故障模式分析是混沌工程實踐的關(guān)鍵環(huán)節(jié)，通過6維故障分析法，從冗余、容災(zāi)、備份、過載、依賴和安全維度，剖析系統(tǒng)的部署架構(gòu)，邏輯架構(gòu)和內(nèi)外部的依賴關(guān)系，分析風(fēng)險場景，選定故障模式，作為混沌演練的場景輸入。云平臺故障場景識別xx會議系統(tǒng)故障場景識別lvs析冗余析視頻網(wǎng)關(guān)APIG分分nginx場場障障故故容災(zāi)安全前端負(fù)載均衡consoleframe6維故障故障點故障點視頻前端web01視頻前端web02分析法haproxyhaproxy依賴備份apicomimsimsvpc視頻后端service視頻后端service故障點故障點pub-dbpub-db過載視頻數(shù)據(jù)庫DB圖2.206維故障場景分析法如圖所示，6維故障分析法對于云平臺和業(yè)務(wù)應(yīng)用演練復(fù)盤場景的故障模式分析均適用。例如，對于應(yīng)用系 進(jìn)行演練復(fù)盤總結(jié)，從產(chǎn)品質(zhì)量、預(yù)案質(zhì)量和運(yùn)統(tǒng)中的關(guān)鍵模塊，如web前端，在業(yè)務(wù)過載場景 作流程等方面識別改進(jìn)點并優(yōu)化。下，分析系統(tǒng)是否具備限流、降級或彈性擴(kuò)容能力；對于數(shù)據(jù)庫，在業(yè)務(wù)過載場景下，分析系統(tǒng) 混沌工程平臺構(gòu)建是否具備自我保護(hù)能力等條件。 混沌工程平是進(jìn)行混沌演練的基礎(chǔ)，完整的混沌工程平臺需要具備故障模式管理、故障場景編排、故制定應(yīng)急預(yù)案 障注入、演練指揮、演練復(fù)盤等能力：根據(jù)故障場景，分析故障發(fā)生后的系統(tǒng)行為及影響，制定對應(yīng)的應(yīng)急預(yù)案。應(yīng)急預(yù)案應(yīng)包括故障 故障模式管理的識別、影響范圍確認(rèn)、故障隔離、恢復(fù)驗證等 提供豐富的故障模式庫，如過載類故障、網(wǎng)絡(luò)類方面。 故障、狀態(tài)變化類故障等，基于故障模式可以構(gòu)造業(yè)務(wù)故障場景。過載類故障包括磁盤IO高，故障演練 CPU負(fù)載高，內(nèi)存利用率高，網(wǎng)卡流量高等。網(wǎng)根據(jù)故障場景實施故障注入，觀察系統(tǒng)的行為是 絡(luò)類故障典型如網(wǎng)絡(luò)丟包、網(wǎng)絡(luò)時延、網(wǎng)絡(luò)中否符合預(yù)期，例如穩(wěn)態(tài)指標(biāo)觀察，容錯行為驗證 斷、網(wǎng)絡(luò)錯報、亂序、重復(fù)包等。狀態(tài)變化類故等，同時驗證處置策略，恢復(fù)手段是否有效。 障有kill進(jìn)程、關(guān)機(jī)、重啟、磁盤只讀、停止服務(wù)等。29故障場景編排2.2應(yīng)用運(yùn)維現(xiàn)代化基于故障模式和資源對象，進(jìn)行故障場景的靈活編排。2.2.1運(yùn)維規(guī)劃前置到設(shè)計階段，業(yè)務(wù)可靠性來源于運(yùn)維與設(shè)計的融合故障注入基于故障模式或故障場景，對資源對象進(jìn)行故障注隨著核心業(yè)務(wù)持續(xù)上云，金融企業(yè)對應(yīng)用高可用要入，為系統(tǒng)引入錯誤行為。由于云上資源的多樣求達(dá)到了5個9。業(yè)務(wù)一旦出現(xiàn)故障不但會影響經(jīng)濟(jì)性，故障注入需要支持各種類型的資源，包括主效益，甚至?xí)绊懙絿嬅裆匀绾慰s小應(yīng)用機(jī)、虛機(jī)、容器、數(shù)據(jù)庫、中間件、進(jìn)程等。故障的影響范圍，保障核心業(yè)務(wù)數(shù)據(jù)不丟失就成了企業(yè)面臨的頭等問題。因此，應(yīng)用高可用設(shè)計成為演練指揮應(yīng)用與基礎(chǔ)設(shè)施現(xiàn)代化轉(zhuǎn)型的關(guān)鍵。設(shè)置演練指揮中心，制定演練計劃，演練排班和應(yīng)急預(yù)案，演練過程全程監(jiān)控。然而，單純依靠傳統(tǒng)的運(yùn)維方式已經(jīng)難以保障業(yè)務(wù)的高可靠要求，運(yùn)維需要前置到設(shè)計階段，業(yè)務(wù)可演練復(fù)盤靠性來源于運(yùn)維與設(shè)計的融合。分析演練數(shù)據(jù)，對演練過程進(jìn)行復(fù)盤總結(jié)，輸出演練報告，發(fā)掘改進(jìn)環(huán)節(jié)并持續(xù)跟蹤。1.業(yè)務(wù)容災(zāi)等級評估高可用設(shè)計并非單純的技術(shù)問題，成本也是影響演練文化鍵。由于高可用設(shè)計需要大量的費(fèi)用投入，而其產(chǎn)混沌工程要在企業(yè)內(nèi)部有效落地，首先需要認(rèn)可其出并不能立竿見影地被直接感知到，所以對于高可所帶來的價值，從組織、流程、文化建設(shè)方面引用設(shè)計往往需要先解決“高可用設(shè)計成本與業(yè)務(wù)預(yù)導(dǎo)，從上到下建立混沌演練文化。只有持續(xù)例行地期的沖突”問題。開展演練工作，才能持續(xù)提升系統(tǒng)的容錯性和可恢復(fù)性，系統(tǒng)的韌性才能得到不斷提升。在投入成本方面，應(yīng)用可用性要求越高，對應(yīng)技術(shù)方案需要投入的成本也會越高。成本數(shù)據(jù)丟失數(shù)據(jù)可靠應(yīng)用可靠應(yīng)用宕機(jī)損失成本性成本性成本損失成本業(yè)務(wù)側(cè)期望 業(yè)務(wù)側(cè)期望當(dāng)前現(xiàn)狀平衡點當(dāng)前現(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ù)期沖突分析30如圖所示：當(dāng)RPO和RTO都為0時，對應(yīng)的高可用設(shè)計成本達(dá)到峰值；相反RPO和RTO時間比較高時，對應(yīng)的高可用成本也會相應(yīng)降低。如果所有業(yè)務(wù)都按照最高的高可用目標(biāo)建設(shè)，金融企業(yè)將面臨巨大的高可用投入成本，所以在技術(shù)設(shè)計前，首先要對業(yè)務(wù)災(zāi)備等級進(jìn)行評估分類?；趹?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)，并縮小故障爆炸半徑；

端邊縱向可觀測體系設(shè)計端側(cè)監(jiān)控 傳輸指標(biāo) 三方服務(wù)業(yè)務(wù)指標(biāo)體系搭建請求量 時延 吞吐運(yùn)維數(shù)倉匯聚運(yùn)維數(shù)據(jù)日志 配置 告警圖2.22典型運(yùn)維數(shù)據(jù)治理流程重要業(yè)務(wù)則需通過調(diào)整應(yīng)用的部署架構(gòu)（無需調(diào)整應(yīng)用架構(gòu)），實現(xiàn)數(shù)據(jù)丟失趨于0，同城主備，進(jìn)于一體的開箱即用的可觀測性平臺至關(guān)重要。異地容災(zāi)；構(gòu)建這樣一個應(yīng)用可用性觀測體系首先需要具備一個統(tǒng)普通業(yè)務(wù)無需對應(yīng)用和部署架構(gòu)作任何調(diào)整，僅一的運(yùn)維數(shù)據(jù)倉庫，以及完善的業(yè)務(wù)可觀測指標(biāo)設(shè)計。需進(jìn)行關(guān)鍵數(shù)據(jù)的定時備份即可。典型的運(yùn)維數(shù)據(jù)治理流程主要包括運(yùn)維數(shù)倉匯聚運(yùn)維數(shù)據(jù)、業(yè)務(wù)指標(biāo)體系搭建、端邊縱向可觀測體系設(shè)計三個3.高可用的持續(xù)治理步驟。運(yùn)維數(shù)倉匯聚運(yùn)維數(shù)據(jù)是基礎(chǔ)，業(yè)務(wù)指標(biāo)體系搭應(yīng)用高可用的保障過程是一個持續(xù)的治理過程。在建是核心，端邊縱向可觀測體系設(shè)計是補(bǔ)充。經(jīng)歷了前期的技術(shù)選型、方案設(shè)計、方案實施和方案驗證后，還需建立完善的容災(zāi)管理制度，并通過運(yùn)維數(shù)倉匯聚運(yùn)維數(shù)據(jù)專業(yè)的高可用技術(shù)團(tuán)隊持續(xù)跟蹤和優(yōu)化業(yè)務(wù)高可用應(yīng)用運(yùn)行過程中會產(chǎn)生大量的運(yùn)維數(shù)據(jù)，包括端側(cè)的達(dá)成情況。所以應(yīng)用高可用治理還涉及容災(zāi)團(tuán)隊數(shù)據(jù)、撥測網(wǎng)絡(luò)數(shù)據(jù)、實例指標(biāo)數(shù)據(jù)(Metrics)、日建設(shè)、容災(zāi)狀態(tài)監(jiān)控、容災(zāi)演練以及知識管理等一志數(shù)據(jù)(Logs)、調(diào)用鏈數(shù)據(jù)(Traces)等。這些運(yùn)維系列工作，才能真正保障應(yīng)用高可用目標(biāo)的達(dá)成。數(shù)據(jù)需要一個統(tǒng)一的運(yùn)維數(shù)據(jù)倉庫進(jìn)行承載。運(yùn)維數(shù)倉主要由數(shù)據(jù)集成、ETL、數(shù)據(jù)湖、MPPDB、2.2.2借助運(yùn)維數(shù)倉構(gòu)建應(yīng)用可用性監(jiān)控數(shù)據(jù)應(yīng)用等功能組件構(gòu)成，典型數(shù)據(jù)處理流程如管理體系，實現(xiàn)業(yè)務(wù)故障實時感知定界下：應(yīng)用可用性監(jiān)控管理是面向應(yīng)用運(yùn)維的一個重要方面。數(shù)據(jù)集成：這些數(shù)據(jù)并非全部是結(jié)構(gòu)化的數(shù)據(jù)，因著眼于持續(xù)現(xiàn)代化演進(jìn)的應(yīng)用可用性監(jiān)控，建設(shè)一個圍此需要有完備的數(shù)據(jù)集成平臺，支持多種運(yùn)維數(shù)據(jù)繞故障生命周期集預(yù)防、檢測、診斷、恢復(fù)、通報和改接入，如消息隊列、API集成、SFTP集成等。31數(shù)據(jù)抽?。簲?shù)據(jù)接入之后由ETL對單條數(shù)據(jù)進(jìn)行過濾、切分、擴(kuò)展、格式化等操作，統(tǒng)一放到消息隊列中。數(shù)據(jù)湖處理：不同的數(shù)據(jù)主體消費(fèi)消息隊列中的數(shù)據(jù)，完成不同的數(shù)據(jù)存儲，如原始日志或者指標(biāo)存放到OBS中、單條粒度數(shù)據(jù)直接入庫或者通過格式定義存放到ClickHouse中、時序多維度量數(shù)據(jù)需要依據(jù)一定的數(shù)據(jù)治理規(guī)則分多個表保存在MPPDB中。數(shù)據(jù)應(yīng)用：所有運(yùn)維數(shù)據(jù)治理完成之后，由數(shù)據(jù)應(yīng)用對數(shù)據(jù)進(jìn)行API封裝，提供對外統(tǒng)一查詢接口。運(yùn)維數(shù)倉UniQueryServer數(shù)據(jù)應(yīng)用單條粒度運(yùn)維數(shù)據(jù)時序多維度量數(shù)據(jù)離線數(shù)據(jù)分析數(shù)據(jù)倉庫[ClickHouse]數(shù)據(jù)湖后端數(shù)據(jù)訂閱分發(fā)[Kafka]日志原始文件單條粒度運(yùn)維數(shù)據(jù)[HDFS/OBS]ETL單條數(shù)據(jù)過濾、切分、擴(kuò)展、格式化[SparkStreaming/Flink]數(shù)據(jù)集成數(shù)據(jù)集成接入[Kafka/SFTP/HTTPS]端側(cè)數(shù)據(jù)采集撥測服務(wù)指標(biāo)監(jiān)控系統(tǒng)日志服務(wù)調(diào)用鏈服務(wù)自定義數(shù)據(jù)APMSEchoTestPrometheusLogServiceNuwaTrace圖2.23應(yīng)用運(yùn)維數(shù)倉典型架構(gòu)業(yè)務(wù)指標(biāo)體系搭建例，針對這些測試用例梳理黑盒化指標(biāo)，如撥測業(yè)務(wù)可觀測性指標(biāo)是指在企業(yè)的業(yè)務(wù)層面上，通過類指標(biāo)、規(guī)格類指標(biāo)等；運(yùn)維人員則根據(jù)運(yùn)維過監(jiān)測、分析和理解數(shù)據(jù)，設(shè)計出來的用以表征業(yè)務(wù)程中的問題持續(xù)對指標(biāo)進(jìn)行優(yōu)化，三者相互配運(yùn)行情況、用戶體驗的業(yè)務(wù)指標(biāo)。業(yè)務(wù)可觀測性更合，構(gòu)建完備的業(yè)務(wù)可觀測指標(biāo)。加關(guān)注運(yùn)行過程、用戶旅程和客戶交互等方面的可視化，從而幫助企業(yè)更好地理解業(yè)務(wù)的健康狀況，業(yè)務(wù)可觀測性指標(biāo)設(shè)計步驟給最終用戶提供更好的用戶體驗。通常情況下，業(yè)務(wù)可觀測指標(biāo)體系搭建主要分成如下四個步驟：業(yè)務(wù)可觀測性指標(biāo)梳理參與角色設(shè)計可觀測性指標(biāo)的前提是對業(yè)務(wù)系統(tǒng)功能有非a.數(shù)據(jù)調(diào)研，分解業(yè)務(wù)要素常深入的理解，因此應(yīng)用開發(fā)人員、測試人員、指標(biāo)設(shè)計人員將業(yè)務(wù)系統(tǒng)的功能進(jìn)行拆解，梳理運(yùn)維人員組成的“鐵三角”缺一不可。開發(fā)人員出業(yè)務(wù)核心功能點，每個功能點會產(chǎn)生的數(shù)據(jù)類可以對系統(tǒng)功能的實現(xiàn)邏輯進(jìn)行白盒化剖析，通型（結(jié)構(gòu)化數(shù)據(jù)、日志、指標(biāo)等），以及明確這過監(jiān)控和日志手段在開發(fā)階段預(yù)埋相應(yīng)的指標(biāo)；些數(shù)據(jù)的作用。測試人員更多從用戶體驗視角設(shè)計相應(yīng)的測試用32梳理概念模型，構(gòu)建總線矩陣每個核心功能點識別之后，就需要開發(fā)人員對每個核心功能點的業(yè)務(wù)過程進(jìn)行白盒化梳理，包括每個業(yè)務(wù)過程需要關(guān)注的數(shù)據(jù)維度，以及每個維度對應(yīng)的字段。以互聯(lián)網(wǎng)應(yīng)用“設(shè)備登錄”業(yè)務(wù)過程為例，應(yīng)用需要獲取設(shè)備類型、設(shè)備品牌、登錄地域、登錄運(yùn)營商、HTTP響應(yīng)狀態(tài)碼、業(yè)務(wù)響應(yīng)狀態(tài)碼等維度的數(shù)據(jù)。業(yè)務(wù)過程業(yè)務(wù)過程一致性維度一級二級請求來源設(shè)備類型品類地理運(yùn)營商http業(yè)務(wù)AppleDevtypeProductID區(qū)域響應(yīng)碼響應(yīng)碼北向設(shè)備注冊南向直連設(shè)備注冊設(shè)備注冊南向下掛設(shè)備注冊南向批量下掛注冊設(shè)備登陸南向設(shè)備登陸北向藍(lán)牙設(shè)備數(shù)據(jù)上報設(shè)備數(shù)據(jù)上報 北向三方設(shè)備數(shù)據(jù)上報南向設(shè)備數(shù)據(jù)上報設(shè)備查詢設(shè)備控制設(shè)備認(rèn)證北向設(shè)備注銷設(shè)備注銷 南向設(shè)備注銷南向鴻蒙設(shè)備重置圖2.24設(shè)備登錄業(yè)務(wù)過程總線矩陣舉例邏輯模型設(shè)計根據(jù)總線矩陣，進(jìn)行數(shù)據(jù)倉庫邏輯模型設(shè)計，在維度建模中，有以下一些關(guān)鍵概念和組件：事實表(FactTable)：事實表是數(shù)據(jù)倉庫中的核心表，包含了與業(yè)務(wù)過程相關(guān)的數(shù)值型度量或指標(biāo)。事實表中的每一行通常表示一個業(yè)務(wù)事件或交易，并與一個或多個維度表相關(guān)聯(lián)。在實際應(yīng)用時，應(yīng)該盡量將來源于同一個業(yè)務(wù)過程的底層度量結(jié)果存儲于一個維度模型中。

維度(Dimension)：維度是描述業(yè)務(wù)過程的屬性或特征，用于對事實進(jìn)行分類和分組。維度表(DimensionTable)：維度表包含了描述事實表中度量的上下文信息，它們用于描述與“who、what、where、when、how、why”有關(guān)的事件，用于對事實進(jìn)行分組和篩選的屬性。33層次結(jié)構(gòu)(Hierarchy)：維度可以具有層次結(jié)構(gòu)，即組織成多個級別的數(shù)據(jù)。例如，時間維度可以包含年、季度、月等層次。度量/原子指標(biāo)(Measure)：原子指標(biāo)和度量含義相同，是事實表中的數(shù)值型數(shù)據(jù)，表示業(yè)務(wù)過程的性能或結(jié)果，是用戶在數(shù)據(jù)倉庫中分析的關(guān)鍵指標(biāo)。

維維度度表表維維度度表表 維維度度表表 事實表 維維度度表表 維維度度表表圖2.25數(shù)據(jù)倉庫維度模型——星形維度模型設(shè)備維度表歌曲播放事務(wù)事實表日期維度表設(shè)備編號DID維度設(shè)備內(nèi)部型號日期[FK]設(shè)備產(chǎn)品傳播名設(shè)備編號DID[FK]設(shè)備品牌設(shè)備產(chǎn)品傳播名設(shè)備品類時間[FK]時間維度表設(shè)備價格范圍華為賬號編號UP_ID[FK]設(shè)備上市日期歌曲代理IO[FK]…歌曲名稱歌曲專輯代理ID[FK]賬號維度表藝術(shù)家[FK]藝術(shù)家維度表度量播放時長歌曲維度表有效播放時長播放次數(shù)...歌曲專輯維度表…圖2.26星形維度模型實踐舉例34d.物理模型開發(fā)與上線 應(yīng)用完整的全鏈路監(jiān)控是非常有價值的工作：物理模型開發(fā)就是在邏輯模型中填充數(shù)據(jù)的過程，填充的數(shù)據(jù)就是在總線矩陣中定義的數(shù)據(jù)，這些數(shù) 可以提升故障主動發(fā)現(xiàn)率，減少故障對業(yè)務(wù)的影據(jù)的來源主要是業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫、日志、調(diào)用鏈 響，提高系統(tǒng)的穩(wěn)定性和可靠性。(本質(zhì)上也是日志)、指標(biāo)數(shù)據(jù)等。而這些數(shù)據(jù)并非結(jié)構(gòu)化數(shù)據(jù)，需要經(jīng)過清洗，匯聚到數(shù)據(jù)倉庫的物理 通過逐層下鉆的數(shù)據(jù)分析能力，幫助快速定位和表中，才能夠讓指標(biāo)設(shè)計人員對指標(biāo)進(jìn)行進(jìn)一步處 解決問題。理(如打標(biāo)簽或者派生指標(biāo)設(shè)計)，最終完成業(yè)務(wù)可觀測性指標(biāo)上線。 通過對系統(tǒng)的實時監(jiān)測和數(shù)據(jù)分析，提供決策支持，優(yōu)化系統(tǒng)性能和資源利用率。端邊縱向可觀測體系設(shè)計應(yīng)用運(yùn)維的運(yùn)維對象是應(yīng)用，即是將“應(yīng)用”作為 上一章節(jié)主要闡釋了指標(biāo)體系如何構(gòu)建，下面介紹一個獨立的邏輯實體。所有該應(yīng)用所使用的資源， 如何根據(jù)這些能力構(gòu)建一個典型應(yīng)用的全鏈路監(jiān)控如VM、Docker、中間件、數(shù)據(jù)庫等，都是該“應(yīng) 模型。用”的組成部分。所以對于應(yīng)用運(yùn)維來說，構(gòu)建該App/ServerKit邊緣網(wǎng)絡(luò)服務(wù)&微服務(wù)二方/三方AccountkitELBWeb數(shù)據(jù)庫三方服務(wù)服務(wù)器AudioKit…SLB應(yīng)用NoSQL二方服務(wù)Internet/骨干網(wǎng)&CDN服務(wù)器APP體驗指標(biāo)API性能指標(biāo)邊緣網(wǎng)指標(biāo)服務(wù)&微服務(wù)性能依賴方性能下載成功率API時延帶寬API時延API時延安裝成功率調(diào)用量流量主機(jī)性能調(diào)用量首頁打開耗時成功率速率中間件成功率首頁圖片耗時…CDN數(shù)據(jù)庫…用戶搜索耗時…基礎(chǔ)設(shè)施應(yīng)用詳情耗時…用戶下載速率…圖2.28典型應(yīng)用全鏈路監(jiān)控模型：端邊云縱向可觀測體系35根據(jù)上圖我們可以看出，一個應(yīng)用要對最終用戶產(chǎn)處理，掌握傳輸過程的數(shù)據(jù)有利于在協(xié)同處理中生價值，整個數(shù)據(jù)流是從端側(cè)發(fā)起，經(jīng)過接入側(cè)、更高效地完成故障修復(fù)。由于無法在傳輸節(jié)點上廣域網(wǎng)、數(shù)據(jù)中心傳輸后，最終到達(dá)云上的服務(wù)端采集數(shù)據(jù)，這部分的時延數(shù)據(jù)一般可通過云側(cè)與完成邏輯處理，再返回到端側(cè)，完成一次完整的數(shù)端側(cè)的指標(biāo)通過復(fù)合計算得到。而邊緣加速網(wǎng)絡(luò)據(jù)交互。其中在云上服務(wù)端處理的過程中，還存在的數(shù)據(jù)可以通過供應(yīng)商的標(biāo)準(zhǔn)監(jiān)控能力獲取。與第三方外部服務(wù)調(diào)用的場景。在這個交互過程中，任何一個環(huán)節(jié)都可能影響到最終用戶的使用和云側(cè)監(jiān)控體驗。所以對于應(yīng)用的全鏈路監(jiān)控來說，每個環(huán)節(jié)應(yīng)用的云側(cè)監(jiān)控除了應(yīng)用黃金指標(biāo)外，還應(yīng)包括都應(yīng)該盡可能地做好監(jiān)控。構(gòu)建該應(yīng)用的資源監(jiān)控。這部分的監(jiān)控數(shù)據(jù)來源于云基礎(chǔ)設(shè)施監(jiān)控能力，但要按應(yīng)用緯度進(jìn)行切端側(cè)監(jiān)控割、匯聚，即應(yīng)用看到的數(shù)據(jù)應(yīng)該是以本應(yīng)用為通常采用埋點方式完成對端側(cè)數(shù)據(jù)的采集。端側(cè)顆粒度的整體數(shù)據(jù)。的指標(biāo)是應(yīng)用監(jiān)控指標(biāo)中最能直接反應(yīng)最終用戶體驗的數(shù)據(jù)，比如打開應(yīng)用的時延、訪問成功率三方服務(wù)等。如果傳輸質(zhì)量降低，云側(cè)成功率指標(biāo)可能沒指本應(yīng)用之外的調(diào)用或交互。這部分?jǐn)?shù)據(jù)的獲取有明顯波動，而通過端側(cè)指標(biāo)則可迅速感知。不能依賴對端服務(wù)，而應(yīng)該從自己應(yīng)用的調(diào)用過程中采集，例如可以通過對調(diào)用對端接口的日志傳輸網(wǎng)絡(luò)進(jìn)行分析的方式獲取。應(yīng)用運(yùn)維需要感知本應(yīng)用在傳輸過程中的質(zhì)量數(shù)據(jù)，比如涉及地域、線路、邊緣網(wǎng)絡(luò)加速等數(shù)經(jīng)過多輪的業(yè)務(wù)可觀測指標(biāo)設(shè)計之后，就可以將據(jù)，但不必過度關(guān)注底層傳輸指標(biāo)。網(wǎng)絡(luò)傳輸過指標(biāo)根據(jù)業(yè)務(wù)核心功能在監(jiān)控大屏中進(jìn)一步呈程中的質(zhì)量問題往往需要與運(yùn)營商或供應(yīng)商協(xié)同現(xiàn)。圖2.29業(yè)務(wù)可觀測大屏展示362.2.3面向故障全生命周期，全方位提升故障感知、診斷、恢復(fù)智能化水平圍繞故障生命周期，構(gòu)建開箱即用的一體化可觀測性平臺，有助于提升典型故障的故障定界、分析診斷和恢復(fù)理管障故化能智故障預(yù)防斷斷斷斷故障診斷斷斷斷斷故障診斷故障恢復(fù)故障改進(jìn)診診診診診診診診路絡(luò)路絡(luò)通報自恢復(fù)鏈D性網(wǎng)…鏈D性網(wǎng)…自動巡檢……WarRoom事后分析應(yīng)急預(yù)案工單管理故障生命周期管理故障處理策略管理故障模式庫(VM故障/容器故障/網(wǎng)絡(luò)故障/中間件故障/DB故障/微服務(wù)故障/…)智能運(yùn)維RPA(roboticprocessautomation)圖2.30應(yīng)用智能化故障管理流程基于監(jiān)控指標(biāo)的智能化故障呈現(xiàn) 得閾值配置過于保守而產(chǎn)生大量的無效告警。為解在構(gòu)建全鏈路監(jiān)控后，應(yīng)用運(yùn)維就具備了精細(xì)化的 決上述問題，可通過業(yè)務(wù)特征的曲線歷史形態(tài)(周期業(yè)務(wù)指標(biāo)監(jiān)控能力，下一步就是要能及時感知故 性、徒增突降、趨勢性)進(jìn)行建模，從而通過動態(tài)擬障。傳統(tǒng)的異常檢測基于閾值開關(guān)，這樣常常會使 合的閾值精準(zhǔn)識別異常，1分鐘發(fā)現(xiàn)業(yè)務(wù)故障。訓(xùn)練1、加載歷史數(shù)2、數(shù)據(jù)預(yù)處理3、識別數(shù)據(jù)特征4、選擇模型5、訓(xùn)練閾值6、構(gòu)建補(bǔ)充特征據(jù)和模型超參xx天的歷史數(shù)據(jù)1、歷史異常數(shù)據(jù)剔除1、周期性識別1、boxplot2、DSPOT1、異常度（毛刺點）（天周分鐘）3、SVM4、小樣本算法2、按檢測粒度重采樣2、突變2、波動性識別5、MAD…3、數(shù)據(jù)平滑&插值3、長時間掉零…3、平穩(wěn)性識別8、存入模型7、補(bǔ)充特征模型訓(xùn)練推理1、讀取實時數(shù)據(jù)2、數(shù)據(jù)預(yù)處理3、加載模型閾值4、異常標(biāo)記5、窗口異常標(biāo)記最近xx個點的實時數(shù)據(jù)1、按檢測粒度重采樣1、原始數(shù)據(jù)的閾值線2、數(shù)據(jù)平滑&插值2、補(bǔ)充特征的閾值線6、異常度閾值判斷11、返回推理結(jié)果10、推理后處理9、最終告警標(biāo)記位7、持續(xù)掉零告警返回實時數(shù)據(jù)推理結(jié)果1、請求量保護(hù)機(jī)制告警進(jìn)入標(biāo)記位、告警2、斷點保護(hù)機(jī)制8、環(huán)比突變告警（包含測量值、閾值）退出標(biāo)記位3、持續(xù)告警機(jī)制圖2.31智能化感知故障建模37智能化感知故障建模主要分為訓(xùn)練和推理兩個階段：訓(xùn)練：通過加載一定時期的歷史數(shù)據(jù)(如一個月的歷史數(shù)據(jù))，進(jìn)行異常數(shù)據(jù)剔除、數(shù)據(jù)插值、數(shù)據(jù)重采等數(shù)據(jù)預(yù)處理，識別出數(shù)據(jù)特征，基于一定的模型算法，輸出訓(xùn)練的閾值，形成業(yè)務(wù)運(yùn)行的典型模型。推理：業(yè)務(wù)在運(yùn)行過程中，實時采集運(yùn)行數(shù)據(jù)，生成運(yùn)行指標(biāo)，通過和已經(jīng)訓(xùn)練出的典型模型的指標(biāo)閾值對比，對存在異常的指標(biāo)進(jìn)行標(biāo)記(包含窗口異常標(biāo)記、異常度閾值判斷、持續(xù)掉零告警、環(huán)比突變告警等異常標(biāo)記)，確定最終告警標(biāo)記位，進(jìn)而生成最能呈現(xiàn)指標(biāo)變化的推理結(jié)果?；诒O(jiān)控指標(biāo)的智能化根因診斷當(dāng)應(yīng)用運(yùn)維監(jiān)控指標(biāo)構(gòu)建的足夠完善，就可以通過智能化分析進(jìn)行故障根因診斷。故障根因診斷通常有以下幾個步驟：

告警聚合成事件，以最新告警和歷史事件作為告警聚合的輸入；事件通過智能決策引擎進(jìn)行診斷決策，例如，觸發(fā)哪種診斷，觸發(fā)多少次診斷，診斷的先后順序等，并將診斷算法產(chǎn)生的根因記錄到事件中；事件中診斷的根因結(jié)果會被用來進(jìn)行新告警的聚合；智能決策引擎進(jìn)行事件的總結(jié)，包括事件描述的總結(jié)、事件