AIOps運(yùn)維大腦建設(shè)實(shí)踐

1、 AIOps運(yùn)維大腦建設(shè)實(shí)踐我們生活在一個(gè)數(shù)字化的社會中，而運(yùn)維則是這個(gè)數(shù)字社會的一個(gè)基礎(chǔ)設(shè)施級別的技術(shù)。運(yùn)維做得不好，各行各業(yè)，無論是金融、電信、能源、工業(yè)制造、互聯(lián)網(wǎng)、物聯(lián)網(wǎng)，都不能高效、穩(wěn)定、可靠地運(yùn)轉(zhuǎn)。既然運(yùn)維這么重要，為什么還常出現(xiàn)各種各樣的、甚至影響非常大的故障呢？本質(zhì)原因是我們現(xiàn)在遇到了一個(gè)非常大的矛盾。這個(gè)矛盾就是當(dāng)前運(yùn)維所大量依賴的人力決策已經(jīng)無法應(yīng)對當(dāng)前運(yùn)維所面臨的挑戰(zhàn)。隨著互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)迅猛發(fā)展，用戶越來越挑剔、對應(yīng)用軟件的用戶體驗(yàn)要求越來越高。而我們知道，應(yīng)用軟件都是建立在一個(gè)龐大、復(fù)雜、跨協(xié)議層的大型分布式系統(tǒng)之上的。這個(gè)分布式系統(tǒng)的技術(shù)、軟件、配置通常會不斷快速

2、地演變；其軟硬件難以避免會發(fā)生故障、Bug、變更；用戶流量會發(fā)生不可預(yù)知的變化，甚至?xí)l(fā)生安全攻擊事件，而上述趨勢有愈演愈烈之勢。盡管各類運(yùn)維監(jiān)控工具使系統(tǒng)運(yùn)行狀態(tài)的可見度有較大提升，但是當(dāng)遇到運(yùn)維故障時(shí)，面對海量監(jiān)控?cái)?shù)據(jù)和龐大負(fù)責(zé)分布式系統(tǒng)，仍依賴運(yùn)維人員在高壓下人力做出迅速、準(zhǔn)確的運(yùn)維決策，這顯然是不現(xiàn)實(shí)的。也即是說人力運(yùn)維決策已經(jīng)無法應(yīng)對當(dāng)前的運(yùn)維挑戰(zhàn)。這導(dǎo)致運(yùn)維人員的工作生活可以說是處于水深火熱之中，“人少、事多，救火、背鍋”，7*24小時(shí)時(shí)刻準(zhǔn)備救火。有運(yùn)維人員自己做的打油詩為證：我們解決上述核心矛盾的思路，就是逐漸減少人力在運(yùn)維決策中所占的比例，逐漸增加人工智能在運(yùn)維決策中的比例，

3、最終實(shí)現(xiàn)無人運(yùn)維：這就像交通工具所經(jīng)歷的變革一樣：起初交通工具要靠人力驅(qū)動(dòng)，之后能夠做到自動(dòng)驅(qū)動(dòng)，但還需要大量的人力決策（每公里駕駛需要人力決策100次以上），最終我們希望能夠做到無人駕駛你坐在車上面，車自動(dòng)帶你去目的地。運(yùn)維已經(jīng)從最早的人力運(yùn)維發(fā)展到了一定程度上的自動(dòng)化運(yùn)維（但還是需要大量人力盯屏決策），最終我們希望基于人工智能的運(yùn)維工具能夠更多自主決策，只需很少人力、甚至不再需要人力參與決策。這就是我們運(yùn)維行業(yè)的長遠(yuǎn)目標(biāo)：基于AIOps的無人運(yùn)維。無人運(yùn)維是目標(biāo)，AIOps（AI for IT Operations）是工具、是手段。目標(biāo)不可能一蹴而就，需要我們一步步腳踏實(shí)地、不斷探索去實(shí)現(xiàn)

4、。因此我們必須有一種客觀的、量化的手段能夠?qū)o人運(yùn)維（或智能運(yùn)維）水平進(jìn)行度量。下面提出的無人運(yùn)維量化評級方法，不包含主觀因素、不需要人主觀打分。按照這種方法，每個(gè)單位都可以與其它單位及自己以往進(jìn)行客觀地比較，有效衡量本單位無人運(yùn)維（或智能運(yùn)維）在行業(yè)內(nèi)的相對水平及自身進(jìn)展。一、 無人運(yùn)維評級如前所述，我們希望能夠量化、綜合評估運(yùn)維的生產(chǎn)力。因此，在設(shè)計(jì)具體指標(biāo)的時(shí)候，我們考慮了如下因素：直觀來講，為了達(dá)到同等的穩(wěn)定性、可靠性SLA，依賴人力決策越多，其無人運(yùn)維評級水平就相對低一些。希望這個(gè)評估指標(biāo)能夠與以下因素脫鉤：行業(yè)、業(yè)務(wù)類型、業(yè)務(wù)規(guī)模、架構(gòu)、技術(shù)、加班程度、外包情況等。運(yùn)維人力應(yīng)計(jì)入負(fù)

5、責(zé)運(yùn)維服務(wù)器、存儲、網(wǎng)絡(luò)、中間件、數(shù)據(jù)庫、應(yīng)用的所有人力。運(yùn)維人力計(jì)入人力查看監(jiān)控?cái)?shù)據(jù)、排除故障、運(yùn)維規(guī)劃，盯屏幕、值班閑置的事件，但是不計(jì)入運(yùn)維人員用于開發(fā)運(yùn)維工具的時(shí)間?；谏鲜隹紤]，我們提出的指標(biāo)是Cores per Op (CPO)，即每個(gè)運(yùn)維人員OP（每周平均工作40小時(shí)）平均管理的X86 CPU核數(shù)，而評級可以對照下表直接換算。在我之前訪談的若干家機(jī)構(gòu)中，傳統(tǒng)行業(yè)的CPO大致在幾百（對應(yīng)Level 0），基于公有云中小型互聯(lián)網(wǎng)公司的CPO大致幾千（對應(yīng)Level 1），大型互聯(lián)網(wǎng)公司CPO在幾萬（對應(yīng)Level 2）。下面我們通過舉幾個(gè)虛構(gòu)的例子來進(jìn)一步說明如何通過CPO和無人運(yùn)維

6、評級進(jìn)行橫向和縱向的比較：例1某互聯(lián)網(wǎng)公司A有X86架構(gòu)的服務(wù)器100萬臺，其中12核的50萬臺、24核的50萬臺；人力共有400人、每人每周工作60小時(shí)，其中200人50%的時(shí)間用在人力運(yùn)維，另200人80%的時(shí)間用在人力運(yùn)維。按照上述方法核算下來是390 Op，再用總核數(shù)（1300萬）除以390OP，是3.3萬核每OP，對應(yīng)Level 2。例2互聯(lián)網(wǎng)公司B運(yùn)維水準(zhǔn)要比A高一些：總核數(shù)同樣是1300萬，但是總?cè)肆怂阆聛碇挥?30 Op，用相同方法計(jì)算下來是Level 3，比A高一級，表示其智能化程度更高。從前兩個(gè)例子里可以看出，同一類型的不同公司之間可以通過CPO和無人運(yùn)維評級進(jìn)行量化的橫

7、向比較。例3再舉一個(gè)傳統(tǒng)行業(yè)的例子：某大型銀行C的CPU核數(shù)核算下來有18萬核，各種運(yùn)維人力（其中包括外包運(yùn)維人力200人）核算下來有495 Op。CPO為363，相當(dāng)于Level 0。水平遠(yuǎn)低于互聯(lián)網(wǎng)公司A、B。這里面有行業(yè)原因因?yàn)殂y行對穩(wěn)定性、可靠性的優(yōu)先級更高，所以為保證穩(wěn)定性和可靠性，銀行C只好依賴大量的人力來補(bǔ)足運(yùn)維工具的不足。這里是不同行業(yè)的機(jī)構(gòu)之間的橫向比較。由于銀行C基于互聯(lián)網(wǎng)的業(yè)務(wù)增長迅猛，計(jì)劃3年內(nèi)把X86的服務(wù)器從1萬臺增長到10萬臺，因此總核數(shù)預(yù)計(jì)增長為126萬核。如果保持運(yùn)維水準(zhǔn)不變（即每個(gè)運(yùn)維人力管理363個(gè)核），則需要人力增加10倍，達(dá)到3000多人；但如果人力只

8、能保持300多，這就必須提升自動(dòng)化運(yùn)維的水平，無人運(yùn)維評級相應(yīng)需要從0級升為1級。這是同一個(gè)機(jī)構(gòu)通過CPO和無人運(yùn)維評級進(jìn)行自我縱向比較和規(guī)劃的例子。小結(jié)以上幾個(gè)例子可以給大家一個(gè)比較直觀的感受：我們可以利用這種評級方法對同一行業(yè)的不同機(jī)構(gòu)、不同行業(yè)的機(jī)構(gòu)之間進(jìn)行橫向的量化比較，也可以對同一家機(jī)構(gòu)不同時(shí)期進(jìn)行縱向的量化比較。CPO和無人運(yùn)維評級可以給大家提供一個(gè)量化的依據(jù)，大家可以看到自己處于什么水準(zhǔn)、同行處于什么水準(zhǔn)，促進(jìn)大家更好地朝著最終無人運(yùn)維的目標(biāo)前進(jìn)。我們相信上述CPO和無人運(yùn)維評級在“基于AIOps的無人運(yùn)維”發(fā)展中將起到重要的促進(jìn)作用。二、通過AIOps實(shí)現(xiàn)無人運(yùn)維無人運(yùn)維是我們

9、的終極目標(biāo)，AIOps是我們通往這個(gè)目標(biāo)的手段。AIOps有兩個(gè)相關(guān)部分：左側(cè)是監(jiān)控系統(tǒng)，相當(dāng)于“眼睛”，采集各類運(yùn)維監(jiān)控?cái)?shù)據(jù)（抓包、埋點(diǎn)、撥測、日志、流程等），全面感知系統(tǒng)狀態(tài)；右邊是基于確定邏輯的自動(dòng)化工具，相當(dāng)于“手”，負(fù)責(zé)一些比如重啟、回滾、流量調(diào)度、擴(kuò)縮容、跨機(jī)房遷移等操作；中間部分是“大腦”，就是AIOps，它以眼睛感知到的數(shù)據(jù)作為輸入，做出實(shí)時(shí)的運(yùn)維決策，從而驅(qū)動(dòng)“手”執(zhí)行一些自動(dòng)化的操作。此外，大腦還負(fù)責(zé)把監(jiān)測的歷史數(shù)據(jù)梳理成高水平的知識（即運(yùn)維知識圖譜），從而可以被算法模塊調(diào)用、同時(shí)也可以供人查詢。AIOps運(yùn)維大腦主要包含兩大部分：“運(yùn)維知識圖譜”和“動(dòng)態(tài)決策”。運(yùn)維知識圖

10、譜就是線下挖掘運(yùn)維歷史數(shù)據(jù)、建立各種畫像，梳理出各類高水平的知識。這些知識有兩類基本用途：可以通過查詢工具（比如人機(jī)對話機(jī)器人）被運(yùn)維人員消費(fèi)；動(dòng)態(tài)決策利用實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)和已經(jīng)挖掘好的運(yùn)維知識圖譜進(jìn)行實(shí)時(shí)決策?！皠?dòng)態(tài)決策” 包括故障發(fā)現(xiàn)、故障定位、故障處置、故障規(guī)避等大場景。每一個(gè)大場景還包含若干個(gè)小場景，比如故障發(fā)現(xiàn)包含單指標(biāo)異常檢測、多指標(biāo)異常檢測、文本日志異常檢測、交易鏈條日常檢測等等。每一個(gè)場景都是運(yùn)維行業(yè)幾十年發(fā)展積累下來的難題，都需要投入大量AIOps算法人力和精力去攻克。比如我在清華的實(shí)驗(yàn)室，去年投入了10個(gè)博士生分工合作研究單指標(biāo)異常檢測，才把這個(gè)難題攻克了。此外， AIOps要

11、解決的是“系統(tǒng)+算法”問題，而不是簡單的算法問題。這是因?yàn)槲覀兊倪\(yùn)維對象是個(gè)龐大、復(fù)雜、跨協(xié)議層的系統(tǒng)，它里面的大量邏輯是程序員寫的代碼和各種網(wǎng)絡(luò)協(xié)議和應(yīng)用協(xié)議。因此，AIOps運(yùn)維大腦中的每一個(gè)模塊都相當(dāng)復(fù)雜，所以我們不要期望把運(yùn)維數(shù)據(jù)灌進(jìn)一個(gè)通用AI算法就能完成該模塊的功能。解決任何一個(gè)AIOps中的模塊或場景，都需要有“AIOps架構(gòu)師”把復(fù)雜的場景和需求拆解成具體的功能模塊： “眼”、“手”、“腦”?！把邸苯鉀Q那些通過采集數(shù)據(jù)全面感知系統(tǒng)運(yùn)行狀態(tài)就能解決的問題；“手”解決那些基于固定邏輯就能解決的問題；“腦”又細(xì)分為兩類模塊：1）通過挖掘歷史數(shù)據(jù)總結(jié)出來各種畫像和知識；2）通過動(dòng)態(tài)決策

12、算法來處理各種具體運(yùn)維場景。“腦”里面的兩個(gè)模塊必須能被當(dāng)前AI技術(shù)所解決（要求數(shù)據(jù)豐富、信息完整、清楚定義、單領(lǐng)域）。運(yùn)維領(lǐng)域有很多問題當(dāng)前AI技術(shù)沒有辦法直接整體解決，在這種情況下我們就繼續(xù)把該問題拆解成更細(xì)的模塊，以期能夠被當(dāng)前AI技術(shù)解決。為了更好地支持上述觀點(diǎn)，下圖展示了我在清華的實(shí)驗(yàn)室中在AIOps運(yùn)維大腦的各個(gè)模塊中使用過的并行之有效的通用AI算法?？梢钥吹讲煌哪K采用的通用AI算法差異非常大，有些模塊還需要若干通用AI算法的組合才能良好解決。這張圖充分說明了AIOps的架構(gòu)挑戰(zhàn)。三、智能故障發(fā)現(xiàn)接下來會介紹一下我們實(shí)驗(yàn)室在“智能故障發(fā)現(xiàn)”方向的進(jìn)展。智能故障發(fā)現(xiàn)包括故障發(fā)現(xiàn)和

13、故障定位。首先介紹我們在單指標(biāo)異常檢測的最新進(jìn)展。我們實(shí)驗(yàn)室在這一領(lǐng)域的科研成果在世界范圍內(nèi)處于領(lǐng)先的地位：我們IMC2015工作是有監(jiān)督的異常檢測，解決了之前樸素異常檢測算法無法普適的問題；我們在推廣這個(gè)技術(shù)的過程中，發(fā)現(xiàn)有監(jiān)督異常檢測算法的應(yīng)用場景是有限的，所以后來我們在WWW2018發(fā)明了一種無監(jiān)督的異常檢測算法；隨著在實(shí)踐中對該WWW2018算法的使用，發(fā)現(xiàn)它也存在一些不足。比如，當(dāng)存在違反周期性的異常時(shí)，使用該算法效果不好，因此我們加入了時(shí)間信息解決了這個(gè)問題；WWW2018算法在處理非高斯噪聲的指標(biāo)時(shí)也存在不足，我們就實(shí)現(xiàn)了一個(gè)基于對抗生成網(wǎng)絡(luò)的算法解決了這個(gè)問題；此外，我們通過聚

14、類算法和遷移學(xué)習(xí)，實(shí)現(xiàn)了對于百萬級指標(biāo)進(jìn)行異常檢測；對于游戲等生命周期很短的應(yīng)用通過半監(jiān)督學(xué)習(xí)快速進(jìn)行異常檢測；通過參數(shù)自動(dòng)遷移，在指標(biāo)模式漂移后自動(dòng)適配異常檢測算法。最后這些算法整合成了我們非常智能的單指標(biāo)異常檢測算法。這個(gè)單指標(biāo)異常檢測的例子很好地說明了我們實(shí)驗(yàn)室的研究思路：“從實(shí)踐中來” （從實(shí)踐中總結(jié)提煉出科研問題，從根兒上解決問題，而不是通過簡單工程方法治標(biāo)不治本）、“到實(shí)踐中去”（不斷實(shí)踐、不斷迭代認(rèn)知、不斷完善，而不是發(fā)表一篇論文就做別的去了）。在單指標(biāo)異常檢測的基礎(chǔ)上，我們還實(shí)現(xiàn)了多指標(biāo)異常檢測、面向文本日志的異常檢測、對交易鏈條的異常檢測、異常機(jī)器定位、異常多維定位、變更故障

15、定位、交易鏈條定位等：這些AIOps最終被整合在一起，形成我們的“智能故障發(fā)現(xiàn)”系統(tǒng)。一線運(yùn)維人員無需關(guān)注背后的種種算法：當(dāng)有故障發(fā)生時(shí)，系統(tǒng)直接告訴運(yùn)維人員哪里出了什么樣的故障，以及該故障的原因是什么。系統(tǒng)不是將海量的監(jiān)控都推給運(yùn)維人員讓他自己搞清楚問題是什么，而是已經(jīng)匯總好，直接給出問題所在。例如，下圖中5臺機(jī)器4項(xiàng)指標(biāo)出了問題：采用人力排查的話需要看上萬臺機(jī)器、每臺各100多個(gè)指標(biāo)，而我們的系統(tǒng)則可以把這個(gè)結(jié)果快速呈現(xiàn)出來：某一個(gè)具體日志時(shí)間，發(fā)生故障時(shí)第三個(gè)參數(shù)取值的分布在故障之前和故障之后有顯著變化，這樣就給運(yùn)維人員提供了非常清晰的提示和參考，指導(dǎo)人員下一步該怎么做。同時(shí)系統(tǒng)還會提示

16、本次故障和歷史上某次故障癥狀上非常相似或有某種關(guān)系，進(jìn)而建議運(yùn)維人員現(xiàn)在可采取什么樣的處置方案應(yīng)對當(dāng)前故障。以上“智能故障發(fā)現(xiàn)”AIOps算法朝著無人運(yùn)維的終極目標(biāo)邁進(jìn)了一大步。四、運(yùn)維知識圖譜這部分將會簡要介紹運(yùn)維知識圖譜的構(gòu)建和使用。構(gòu)建運(yùn)維知識圖譜是指從運(yùn)維數(shù)據(jù)中自動(dòng)挖掘：各類運(yùn)維主體；運(yùn)維主體的各類特性畫像和規(guī)律；運(yùn)維主體之間的關(guān)系。運(yùn)維主體包括系統(tǒng)軟、硬件及其運(yùn)行狀態(tài)：軟件是指服務(wù)、微服務(wù)、中間件、存儲服務(wù)、數(shù)據(jù)庫等等；硬件是指機(jī)房、機(jī)群、機(jī)架、服務(wù)器、虛擬機(jī)、容器、硬盤、路由器、交換機(jī)等等；各類監(jiān)控?cái)?shù)據(jù)，包括指標(biāo)、日志事件、Trace、變更、流程等等。那么運(yùn)維知識圖譜與CMDB的區(qū)

17、別是什么呢？運(yùn)維知識圖譜包含基于人工智能的、模糊的、自動(dòng)化挖掘的知識，而CMDB是確定的、手工配置的知識或基于確定邏輯自動(dòng)配置的知識：運(yùn)維知識圖譜與傳統(tǒng)的運(yùn)維專家知識又有什么區(qū)別呢？知識圖譜是中心化的，而傳統(tǒng)專家的知識是分布在運(yùn)維專家頭腦中的，是去中心化的。知識圖譜是連在一起的“一幅大圖”；而專家知識是割裂的，所以，想要實(shí)時(shí)地把分布在專家頭腦中的知識以及靜態(tài)CMDB數(shù)據(jù)關(guān)聯(lián)在一起，解決實(shí)時(shí)問題顯然是不可行的。知識圖譜可被快速查詢，專家知識需要人力關(guān)聯(lián)，所以緩慢易錯(cuò)。知識圖譜可自動(dòng)更新，而專家知識需要手動(dòng)更新?？梢宰詣?dòng)生成知識圖譜的變化報(bào)表，而利用專家知識要靠手動(dòng)撰寫報(bào)告。因此，建立運(yùn)維知識圖譜

18、的優(yōu)勢是非常明顯的。下面我們通過兩個(gè)例子來詳細(xì)說明一下：首先給出了各類硬件主體之間的關(guān)系：容器1屬于容器類型1， 而容器類型1的配置細(xì)節(jié)（CPU、內(nèi)存、存儲類型、存儲空間）都是能夠由配置信息基于固定邏輯自動(dòng)構(gòu)建出來的，屬于靜態(tài)屬性。同時(shí)，通過挖掘?qū)W習(xí)出一些動(dòng)態(tài)屬性（白底紅字），比如容器類型1的資源使用限制（內(nèi)存使用率最多能到多少），這些信息很難靠人力準(zhǔn)確總結(jié)或推測，得靠挖掘歷史數(shù)據(jù)獲得。我們再看軟件主體和硬件主體之間關(guān)系，以及軟件主體之間的關(guān)系：服務(wù)1調(diào)用微服務(wù)1、微服務(wù)1部署在容器1上面。這樣，軟硬件主體在圖中就通過邊連接起來了。這種關(guān)系也是通過確定邏輯基于配置信息自動(dòng)構(gòu)建的（橙色的邊屬性）

19、。那么，容器類型1可以支持微服務(wù)1每秒鐘多少次的交易呢（容器類型1與微服務(wù)1之間的邊的紅色屬性）？這個(gè)屬性需要通過歷史數(shù)據(jù)、壓測數(shù)據(jù)構(gòu)建動(dòng)態(tài)的畫像。我們再看一下軟件主體與監(jiān)控指標(biāo)主體之間的關(guān)系，以及監(jiān)控指標(biāo)之間的關(guān)系：服務(wù)1的一個(gè)監(jiān)控指標(biāo)是總流量，而這個(gè)總流量又可以按照省份屬性細(xì)分，監(jiān)控指標(biāo)“服務(wù)1.流量”與監(jiān)控指標(biāo)“服務(wù)1.流量.北京市”是包含的關(guān)系，而“服務(wù)1.流量.北京市”與“服務(wù)1.流量.北京市.聯(lián)通”又是包含關(guān)系。當(dāng)今的監(jiān)控?cái)?shù)據(jù)中雖然可能有幾百萬監(jiān)控指標(biāo)，但是它們之間往往有類似上述“包含”關(guān)系的某種關(guān)系。而此類關(guān)系遵循固定邏輯，是可以通過配置信息自動(dòng)構(gòu)建出來的，最終可以作為邊添加在這

20、幅圖譜中。因此我們可以想象，這個(gè)圖譜就形成了一個(gè)無所不包的大型數(shù)據(jù)結(jié)構(gòu)，供我們在其上為各類運(yùn)維場景開發(fā)動(dòng)態(tài)決策算法。上圖中還展示了“服務(wù)1.流量”的動(dòng)態(tài)畫像（白底紅字）：增長趨勢、季節(jié)性、高峰時(shí)段、特殊日、最佳的變更時(shí)段等等。這些信息在運(yùn)維人員腦子里面或多或少有一些，但是并不能被隨時(shí)隨地準(zhǔn)確快速地查詢。我們的方法是，在專家的指導(dǎo)下，通過機(jī)器學(xué)習(xí)方法自動(dòng)把這些知識挖掘出來，可以被自動(dòng)更新和隨時(shí)查詢。“微服務(wù)1.響應(yīng)時(shí)間” 的影響因素有n個(gè), 而它們之間的關(guān)系是通過一個(gè)函數(shù)f(x1,x2,xn)來刻畫的，而這個(gè)函數(shù)可能是通過一個(gè)神經(jīng)網(wǎng)絡(luò)來擬合的。這個(gè)例子清晰的說明運(yùn)維知識圖譜與傳統(tǒng)基于確定邏輯的C

21、MDB的區(qū)別：在這個(gè)例子里，我們用有限的一頁P(yáng)PT，展示了一個(gè)很大的知識圖譜中很小的一個(gè)切面?？梢韵胂笊先f臺機(jī)器，上百萬指標(biāo)，全都串在一起會形成如何的一幅大圖！幸運(yùn)的是，現(xiàn)在有不少相對成熟的圖計(jì)算系統(tǒng)和算法可以處理如此規(guī)模的圖。上述例子的一個(gè)應(yīng)用場景是：以往為了應(yīng)對每個(gè)月的大促，需要拍腦袋人工預(yù)測所需計(jì)算資源；有了運(yùn)維知識圖譜，通過查詢圖譜以及算法計(jì)算就可以給出準(zhǔn)確的預(yù)測結(jié)果。下面介紹最后一個(gè)例子，運(yùn)維知識圖譜的另一個(gè)切面故障傳播圖。有了這個(gè)故障傳播圖，就可以快速回答如下問題：當(dāng)前服務(wù)故障的根因是什么？對當(dāng)前故障有何處置建議？當(dāng)前底層的故障對上層服務(wù)有何具體影響？故障傳播圖可以長成什么樣子，又是如何構(gòu)建的呢？我們通過舉例來說明：服務(wù)1調(diào)用了微服務(wù)1.1和微服務(wù)1.2，而微服務(wù)1.2部署在容器1.2.1上。它們有共同的KPI A。因此，KPI A報(bào)警在這三個(gè)主體之前就自然形成了故障傳播關(guān)系，而這種故障傳播關(guān)系是可以通過配置信息通過固定邏輯自動(dòng)生成的（見上圖中藍(lán)色的邊屬性）。有些故障傳播關(guān)