徐代剛 姜磊 梅君君

摘要：提出了一種基于人工智能（AI）的保障視頻云體驗質量（QoE）的系統(tǒng)架構。該系統(tǒng)針對多個維度創(chuàng)建運維知識圖譜，例如運行數(shù)據(jù)、運行環(huán)境、運維數(shù)據(jù)，以用于建模、感知、映射和分析。在對系統(tǒng)的微服務保障中，運用了圖神經(jīng)網(wǎng)絡（GNN）等方法進行分類和預測。通過知識圖譜和機器學習，該系統(tǒng)可實現(xiàn)實時監(jiān)控、自愈恢復、智能預測和主動運維，從而實現(xiàn)QoE的智能保障。

關鍵詞：視頻云系統(tǒng)；數(shù)據(jù)挖掘；知識圖譜；圖神經(jīng)網(wǎng)絡；智能運維

Abstract： Based on artificial intelligence （AI）， a system architecture that guarantees video cloud quality of experience （QoE） is proposed. According to multiple dimensions， the system creates an operation and maintainance knowledge map for modeling， sensing， mapping， and analyzing， such as operating data， operating environment， and operation and maintenance data. In the microservice system， methods such as graph neural network （GNN） are introduced for classification and prediction. Based on thetechnology of knowledge graph and machine learning， the system can perform realtime monitoring， self-healing， intelligent predicting and active operation and maintainance to implement intelligent guarantee of QoE.

Keywords： video cloud system； data mining； knowledge graph； graph neural network； AIOps

隨著5G時代的到來，增強型移動寬帶（eMBB）、海量機器類通信（mMTC）、超可靠低時延通信（URLLC）3大應用場景，尤其是相關的音視頻應用，得到了快速發(fā)展。此外，由于受到新冠肺炎疫情等不確定性因素的影響，企業(yè)或團體遠程辦公、遠程會議的場景和需求日益增多，相應的通信系統(tǒng)也變得日益復雜。以視頻會議為例，它需要支持雙流會議、多流會議，除了要具備編解碼、鏈路控制、會議控制等多種基本功能外，還要能夠管理用戶的安全接入、權限控制等。因此，一個良好的視頻系統(tǒng)，不僅要滿足用戶的業(yè)務需求，支撐音視頻編解碼、播放、合成、錄制、擴展現(xiàn)實（XR）以及會議等多種業(yè)務，還要支撐用戶的質量需求，從聽得清、看得清到聽得懂、看得懂，直至聽得真、看得真，以提升用戶體驗質量（QoE）。對于一個企業(yè)級視頻系統(tǒng)而言，為了提供優(yōu)良的用戶感知，系統(tǒng)除了提供音視頻編解碼、XR渲染等技術外，還要能夠支持多租戶、高并發(fā)、大流量。整個系統(tǒng)應穩(wěn)定可靠且具有高安全性，不僅能靈活控制終端的接入和退出，還可支持云邊協(xié)同，使系統(tǒng)部件可彈性伸縮。

視頻云系統(tǒng)是一個基于微服務架構的云化視頻業(yè)務系統(tǒng)。它擁有良好的軟件設計和硬件架構，支持多業(yè)務、多租戶、大流量，并支持靈活控制、云邊部署、協(xié)同協(xié)調(diào)，可以滿足平滑擴容彈縮，并有嚴格的安全策略設計，以保證終端用戶接入和系統(tǒng)管理的安全性。從視頻云系統(tǒng)的角度來看，QoE的保障不僅要求對具體業(yè)務指標，如丟包率、抖動和時延等，進行調(diào)參調(diào)模等，還要求服務端的軟件系統(tǒng)具有較好的穩(wěn)定性和連續(xù)性（如基于微服務的視頻云系統(tǒng)）[1]。因此，一旦微服務本身的運行狀況出現(xiàn)劣化，上層業(yè)務的QoE將會受到影響。基于經(jīng)驗來看，當前期系統(tǒng)調(diào)試運行穩(wěn)定后，中后期系統(tǒng)（如微服務模塊）運行狀況會出現(xiàn)瓶頸問題，從而導致QoE下降。在系統(tǒng)運行過程中，有兩種情況會導致QoE指標下降，且最終影響用戶感知：一種是軟件代碼質量問題，如代碼漏洞、場景考慮不周全和壓力不足等，或者是系統(tǒng)架構設計有問題，如無法應對數(shù)據(jù)風暴；另一種是系統(tǒng)本身策略性問題，如對網(wǎng)絡感知出現(xiàn)異常，在需要相應微服務模塊進行彈性伸縮時，策略執(zhí)行動作執(zhí)行得不夠迅速。

因此，我們有必要為視頻云系統(tǒng)建立一個智能運維系統(tǒng)。這是因為智能運維系統(tǒng)不僅能夠監(jiān)控具體業(yè)務性能指標劣化，還能監(jiān)控視頻業(yè)務運行的軟件系統(tǒng)劣化，并在此基礎上協(xié)助分析、定位異常和系統(tǒng)瓶頸，甚至能夠主動運維使系統(tǒng)自愈，以更好地提高用戶感知。

對于早期的系統(tǒng)運維，運維人員和軟件模塊開發(fā)人員根據(jù)巡檢和發(fā)生的告警，分析日志和代碼，來定位和解決問題，其中大多屬于事后分析和人肉運維。大量的人工參與，不僅耗時而且容易出現(xiàn)錯誤，因此，如何能減少人工操作并實現(xiàn)故障自愈走上運維的舞臺。隨著人力成本的不斷增高和業(yè)務場景的日益復雜，自動化運維應運而生。自動化運維不僅能夠端到端地解決重復、簡單而又經(jīng)驗化的低階運維工作，而且在提取相關經(jīng)驗形成知識庫后，還能根據(jù)策略定義實施故障自愈。策略閉環(huán)和專家經(jīng)驗知識庫是自動化運維的兩大基石。對于復雜的視頻云系統(tǒng)來說，故障自愈不僅是錦上添花，更是一個必備的保障功能，因為它把運維能力從低階提升到了中階。

但是，隨著5G時代來臨，由于業(yè)務、場景、數(shù)據(jù)急劇增加，系統(tǒng)架構變得更加復雜，自動化運維已經(jīng)無法有效滿足數(shù)據(jù)的海量性、流程的復雜性和應用的新穎性需求。因此，在算法、大數(shù)據(jù)和算力的支撐下，借助人工智能的運維逐漸成熟起來[2-3]。通過數(shù)據(jù)挖掘和概率統(tǒng)計來分析海量數(shù)據(jù)，包括業(yè)務專家和流程專家標簽異常數(shù)據(jù)，并通過機器學習（包括深度學習、強化學習）訓練學習異常來提煉規(guī)則并融入知識圖譜，使自動化運維進一步邁向高階的智能運維（AIOps）[4]。

1視頻云系統(tǒng)云邊部署架構

從業(yè)務角度來看，視頻云系統(tǒng)主要提供媒體應用、媒體控制、媒體處理等服務。其中，媒體應用包括會議電視、音視頻會議和直播等；媒體控制除了要對媒體應用的接入進行解析外，還需要進行業(yè)務調(diào)度和控制業(yè)務邏輯，如在視頻會議中對不同用戶的加入/退出、畫面以及靜音等的控制；媒體處理要進行音視頻編解碼、XR識別等操作。

為了更快速地提供音視頻服務，目前視頻云系統(tǒng)服務端一般采用云邊部署方式[5]，即媒體面靠近用戶邊緣部署，控制面在云端中心部署，如圖1所示。

中心云部署以業(yè)務控制和媒體控制為主，包括會議應用服務器、會議控制、資源控制、數(shù)據(jù)協(xié)作、消息群組、水印服務、實時錄制控制。邊緣云部署以媒體處理為主，其中媒體處理包括多流媒體處理、視頻轉碼合成、實時媒體推流、實時媒體錄制，可提供音視頻算法庫、轉碼和QoE通信引擎等?；贙ubernetes（也稱K8s）的視頻云系統(tǒng)支持微服務的彈性伸縮。

2視頻云系統(tǒng)智能運維架構

借助云邊部署和云邊協(xié)調(diào)，系統(tǒng)在中心管理控制并提供業(yè)務支持，同時計算下沉到邊緣側，能夠更快速地響應和反饋，減少骨干傳輸網(wǎng)以及上層核心網(wǎng)的資源占用，可以很好地保障用戶感知。然而，由于QoE的影響可能是來自邊緣側，也可能是來自中心云，甚至可能是兩者交互后的結果，因此運維監(jiān)管需要對云邊進行統(tǒng)一運維。

如圖2所示，左側是視頻云系統(tǒng)的中心云和邊緣云，右側是AIOps智能運維系統(tǒng)。中心云和邊緣云都嵌入智能代理，分別通過代理模塊將數(shù)據(jù)上報給運維系統(tǒng)，并先通過分析定位后再通過代理模塊分別給云邊下發(fā)指令進行修復自愈。整個系統(tǒng)實現(xiàn)云邊運維閉環(huán)自愈。

為了保障QoE，智能代理對邊緣云和中心云需要采集至少兩方面數(shù)據(jù)。一個方面是運維數(shù)據(jù)，它不僅包括告警數(shù)據(jù)、性能數(shù)據(jù)、日志數(shù)據(jù)和拓撲資源數(shù)據(jù)等，還包括微服務的運行數(shù)據(jù)，如微服務的中央處理器（CPU）和內(nèi)存等數(shù)據(jù)；另一個方面是業(yè)務數(shù)據(jù)，即那些會影響QoE的數(shù)據(jù)。運維數(shù)據(jù)和業(yè)務數(shù)據(jù)統(tǒng)稱為感知數(shù)據(jù)。其中業(yè)務數(shù)據(jù)具體又分為3類：（1）網(wǎng)絡數(shù)據(jù)，如收發(fā)端帶寬、丟包率、抖動、時延等；（2）音視頻參數(shù)，如幀率、分辨率等；（3）直接體驗QoE的終端數(shù)據(jù)，如手機型號、手機系統(tǒng)、會議室終端、機頂盒終端等。另外，由于視頻云系統(tǒng)本身非常復雜，一些模塊或者網(wǎng)絡在調(diào)參（甚至硬件調(diào)整）后，需要重新模擬驗證，因此一些視頻云系統(tǒng)利用數(shù)字孿生進行仿真驗證。智能代理模塊也可以配置探針，采集相關影響QoE的孿生數(shù)據(jù)并將其上傳到保障系統(tǒng)，以進行云邊統(tǒng)一沙箱驗證。

由圖2右側可以看出，運維保障系統(tǒng)大致包括3層：上層提供運維業(yè)務服務，中間框架層提供基本架構和運行支撐，底層是AI支撐。

上層不僅提供具體視頻云系統(tǒng)的QoE運維，還提供異常感知、故障診斷、故障預測和故障自愈。異常感知是對感知數(shù)據(jù)進行異常檢測，具體包括兩種檢測方法：一種是在數(shù)據(jù)直接異常時，有嚴重告警或者指標異常，例如抖動超過閾值、微服務CPU直接超限等，這種異常一般可以通過閾值定義直接檢測；另外一種是綜合判斷，比如對某個時段，雖然沒有指標超過閾值，但整體已經(jīng)劣化。此時，可先通過人工直接標注是否異常，然后通過機器學習來學習和推理。故障診斷可對故障進行定界定位，比如，通過關聯(lián)分析和根因分析，系統(tǒng)發(fā)現(xiàn)聲音激勵切換（VAS）模塊導致終端會議在視頻切換時出現(xiàn)卡頓等。同時，這些分析的結果將被直接注入知識圖譜以供后續(xù)推理使用。故障預測可通過對歷史數(shù)據(jù)進行機器學習來推斷實時的運行情況，具體包括兩種預測：一種是微觀預測，例如根據(jù)歷史數(shù)據(jù)學習來判斷某微服務是否會出現(xiàn)內(nèi)存異常；另一種是宏觀預測，例如當視網(wǎng)絡處理單元（NPU）內(nèi)存消耗較高時，機器學習認為終端會議可能不會出現(xiàn)問題，但XR可能會出現(xiàn)問題。因此，把當前終端類型和NPU內(nèi)存等維度輸入機器學習，可推理預測是否會出現(xiàn)劣化。故障自愈則是根據(jù)診斷定位故障原因，或者根據(jù)預測判斷QoE是否發(fā)生劣化，并根據(jù)知識圖譜學習的規(guī)則通過策略實施自愈措施，把恢復命令（如微服務彈縮或者微服務遷移指令）通過代理發(fā)送給相應系統(tǒng)。

中間的框架層包括感知系統(tǒng)、分析系統(tǒng)、策略中心和執(zhí)行引擎。感知系統(tǒng)接收代理上傳的數(shù)據(jù)（包括云和邊的感知數(shù)據(jù)），并對這些數(shù)據(jù)進行分類、清洗和歸一化。如果數(shù)據(jù)是非離散的，歸一化可以按照高斯分布或者伯努力分布對其進行處理，例如高斯分布可按照馬氏距離來處理。分析系統(tǒng)提供數(shù)據(jù)分析，如告警、性能以及日志等數(shù)據(jù)的關聯(lián)分析和根因分析。策略中心定義相關策略和動作。例如，當NPU內(nèi)存消耗達到80%且持續(xù)時間超過60 s時，系統(tǒng)就會執(zhí)行彈縮擴容。再例如，如果AI預測NPU的內(nèi)存會在視頻終端用戶數(shù)超過10個時就會沖高，那么制定策略會將其設定為當用戶數(shù)超過8個時就彈縮（百分比、時間和數(shù)量等數(shù)據(jù)是非標準數(shù)據(jù)，在此僅做舉例說明）。執(zhí)行引擎保障系統(tǒng)自動化閉環(huán)執(zhí)行，例如對數(shù)據(jù)清洗及歸一化、再挖掘分析、預測、執(zhí)行策略彈縮、發(fā)送指令、全程自動化。

底層AI支撐提供AI算法和訓練推理框架。AI算法包括數(shù)據(jù)挖掘和機器學習的算法，并提供知識圖譜框架。其中機器學習除了涉及常規(guī)分類算法外，如支持向量機（SVM）、邏輯回歸（LR）等，還用到了深度學習中的圖神經(jīng)網(wǎng)絡（GNN）。知識圖譜框架則提供知識圖譜的創(chuàng)建、融合和推理等。相對于傳統(tǒng)人工專家知識庫來說，知識圖譜具有更好的可視性、準確性和擴展性。

從異常感知、故障診斷到故障預測、故障自愈，是一個從被動運維到主動運維的過程。其中，雖然故障自愈的場景不多，但是對于復雜的視頻云系統(tǒng)來說，故障自愈是一個非常必要的功能。下面我們以故障自愈的流程來詳細說明系統(tǒng)的運作流程。

3視頻云系統(tǒng)故障自愈流程

一般來說，視頻云故障自愈有如下3種情況：（1）當系統(tǒng)發(fā)生故障時，如檢測到硬件溫度過高，則進行微服務遷移，把有問題的硬件上的微服務遷移到備份機上；（2）當微服務性能關鍵性能指標（KPI）異常時，相關的微服務可能會進行彈性擴容或者提高服務等級；（3）根據(jù)業(yè)務指標超常進行微服務彈縮[6]。

傳統(tǒng)自動化自愈等做法就是設計門限閾值或者相關事件，制定相應策略進行遷移、擴容或者熔斷等以保障自愈閉環(huán)。以微服務彈縮擴容來說，自動化運維最大的問題在于不確定性。這可能是因為指標（如CPU、內(nèi)存和帶寬）抖動沖高但時間沒有達標而不彈縮，也可能是無法一步彈縮到位，即會按照策略多次彈縮才能最終滿足要求。還有一種可能就是策略設置錯誤，比如在一個周期內(nèi)當最高值達到門限時就會彈縮。然而，由于內(nèi)存瞬間沖高可能會回落，誤彈縮的情況也會發(fā)生，一旦發(fā)生將浪費不必要的資源。

更高階的智能化運維能夠通過機器學習來尋找比較好的解決方案?；跈C器學習的智能自愈，可建立在對歷史數(shù)據(jù)進行機器學習、統(tǒng)計和分析診斷的基礎上，生成相關學習模型和知識規(guī)則，在異常發(fā)生時，能夠根據(jù)學習到的模型和規(guī)則，按照策略定義實施自愈手段，實現(xiàn)閉環(huán)自愈。此外，基于機器學習的智能運維，可以在預測服務或者系統(tǒng)必然劣化時，就提前采取措施實施主動運維，即把被動運維和主動運維相結合，以保障更好的用戶體驗效果。

下面我們對視頻云系統(tǒng)的故障自愈流程做一個總體描述。如圖3所示，自愈流程分為上下兩部分：上面是訓練側，下面是推理側。

在訓練側，歷史數(shù)據(jù)就是感知數(shù)據(jù)，包括QoE指標數(shù)據(jù)、運維數(shù)據(jù)和微服務運行數(shù)據(jù)。在采集數(shù)據(jù)后，系統(tǒng)會首先對數(shù)據(jù)進行清洗、歸一化和映射處理，把運維數(shù)據(jù)進行頻繁集挖掘并分析得到相關性，再通過機器學習對QoE進行分析，通過回歸或分類來判斷趨勢是否會惡化（也可以定位相關惡化指標的關聯(lián)根因）。接著，GNN學習微服務運行趨勢，得到邊和節(jié)點的關系，以及是否需要彈縮的回歸模型和分類模型，并進行驗證。在這一階段，如果效果不好就需要調(diào)參進行再次迭代。最終系統(tǒng)形成知識圖譜和機器學習模型。值得注意的是，在訓練側，需要人工干預，即不僅在數(shù)據(jù)挖掘和機器學習階段要標注，在驗證階段也要交互反饋。

在推理側，當獲得實時監(jiān)控數(shù)據(jù)后，如果數(shù)據(jù)映射感知到異常，系統(tǒng)將進行定位診斷，即根據(jù)知識圖譜得到問題根因模塊，并根據(jù)機器學習模型判斷是否可能會劣化、是否需要彈縮等。緊接著，系統(tǒng)將依據(jù)策略定義執(zhí)行微服務彈性伸縮或者遷移等具體動作，最終達到自愈。

可以看出，在分析階段進行數(shù)據(jù)挖掘后，系統(tǒng)采用傳統(tǒng)的機器學習方法進行QoE分析，如使用單類支持向量機（OCSVM）進行異常檢測，使用LR進行趨勢是否惡化的分類判斷等。由于數(shù)據(jù)挖掘技術已經(jīng)比較成熟，比如工業(yè)界大多采用的頻繁模式樹（FPGrowth）和最大頻繁項集（FPMAX）等算法，加之傳統(tǒng)機器學習和知識圖譜構建也比較成熟，本文不再贅述。下面我們將重點介紹用于微服務判斷和預測的圖神經(jīng)網(wǎng)絡算法。

4視頻云系統(tǒng)智能運維模型算法研究

4.1微服務系統(tǒng)故障分析

在討論GNN算法之前，我們首先介紹基于微服務架構的視頻云系統(tǒng)。在視頻云系統(tǒng)中，不同微服務組件既有一定的獨立性，又有一定的相關性和耦合性。它們的組織架構更像一張圖，具體如圖4所示。

視頻云系統(tǒng)表示一個視頻會議所需要的微服務局部子圖。其中，應用服務（AS）為業(yè)務邏輯提供服務。媒體控制可調(diào)用不同的媒體處理單元。網(wǎng)絡處理單元（NPU）負責收發(fā)和接收網(wǎng)絡媒體包，同時保障媒體QoS。內(nèi)容交換總線（CSB）提供媒體數(shù)據(jù)的分發(fā)。在視頻會議中，聲音激勵切換（VAS）可使發(fā)言者的畫面被展示出來。這些組件與終端會議AS、媒體播放應用服務（AS-VP）、音頻解碼單元（APU）、視頻解碼單元（VPU）均以微服務的形式部署。需要注意的是，圖4僅是示意圖，其中的APU和 VPU等都以各自不同的微服務形式部署。而在實際部署時，為了實現(xiàn)更快的模塊間交互，APU、NPU和CSB可能會被部署在同一個微服務中。這是因為如果視頻會議出現(xiàn)問題，就需要快速定位是哪個服務出現(xiàn)了問題。例如，在圖4（a）中，如果切換發(fā)言出現(xiàn)視頻卡頓，終端會議AS將會出現(xiàn)延遲（圖4中橘色模塊），同時VAS的日志將顯示調(diào)用緩慢（圖4中黃色模塊）。一般來說，造成這種現(xiàn)象的原因可能是VAS、VPU或NPU出現(xiàn)了問題，也可能是CSB出現(xiàn)了問題（圖4中紅色模塊）。此時，系統(tǒng)可借助模塊間的快速交互，實現(xiàn)問題的準確定位：CSB內(nèi)存超限影響VAS，導致切換激勵出現(xiàn)延遲，進而導致AS出現(xiàn)卡頓。

深度神經(jīng)網(wǎng)絡（DNN）、卷積神經(jīng)網(wǎng)絡（CNN）、LR、SVM+梯度直方圖（HOG）等，都是傳統(tǒng)的機器學習和深度學習方法。雖然它們在提取歐氏空間數(shù)據(jù)的特征方面取得巨大的成功，并在線性分類、圖像分類、聲音處理等相關應用上有著非常優(yōu)秀的表現(xiàn)，但是在處理非歐式空間數(shù)據(jù)時（如社交網(wǎng)絡、交通網(wǎng)絡和化學分子式），由于數(shù)據(jù)中每個節(jié)點的邊或者鄰域是不固定的，所以這些深度學習方法無法對此建立模型，即無法使用同樣尺寸的卷積核來表達或者泛化。而GNN，如圖卷積網(wǎng)絡（GCN），可同時結合圖和卷積的特點，能夠取得比較好的效果[7]。例如，在參考文獻[8]中，CHAI D.等利用GCN和多層全聯(lián)接神經(jīng)網(wǎng)絡（MLP）模型，預測了共享單車流量問題；在參考文獻[9]中，作者提出 R-GCN模型，并分別將其運用到聯(lián)系預測和實體分類兩項任務上，在關系圖的多個推理步驟中使用編碼器模型來積累信息，顯著改進了鏈路預測模型；在參考文獻[10]中，YING R.等把GCN運用在推薦系統(tǒng)中，拼趣公司（Pinterest）在此論文基礎上把GCN運用在商業(yè)系統(tǒng)中以推薦圖片給不同用戶。

如前所述，微服務方式部署實際上是一個典型的圖結構。圖4中的節(jié)點就是各個微服務，邊是各個服務之間的調(diào)用關系。例如，假如AS和VAS沒有直接的調(diào)用關系，那么它們兩個節(jié)點之間就沒有相對應的邊。因此，視頻云運維系統(tǒng)在對圖進行學習和預測時，不僅采用了傳統(tǒng)的機器學習算法（例如OCSVM和LR等），還結合了GCN等算法。需要注意的是，在真實視頻云系統(tǒng)中，微服務數(shù)量有上千個，不同服務之間的關聯(lián)更加復雜，微服務部署的復雜度遠遠超過圖4所示的結構。因此，簡單的圖搜索和圖嵌入都不能進行有效的推理和根因定位。

4.2 GNN

GNN是一個很寬泛的概念。一般來說，GNN就是圖+神經(jīng)網(wǎng)絡。目前，與GNN相關的模型算法有GCN、圖注意力網(wǎng)絡（GAT）等。本文中，我們以GCN為例來做具體討論。

一般來說，GNN可被用來處理3類任務：

節(jié)點層面任務。該任務主要包括對微服務節(jié)點進行分類和預測，例如判斷這個節(jié)點和其他節(jié)點是否屬于同一類，或者當該節(jié)點的業(yè)務數(shù)據(jù)有異常時，是否需要進行微服務彈縮或遷移等。

邊層面任務。該任務與微服務直接相關，比如微服務調(diào)用鏈、根因分析等。

圖層面的任務。該任務可對整個模塊或者子圖進行分類預測，例如預測整個視頻云是否正常。

我們提出的視頻云保障系統(tǒng)主要考慮節(jié)點層面任務和邊層面任務。我們需要首先對微服務的組成架構進行圖表示，然后再進行標注和訓練以獲得模型。

我們構建微服務圖，其中GCN把整個圖G、每個節(jié)點V、每條邊E轉化為稠密向量。當然，并不是每次都要把G、V、E進行向量化的，哪部分需要向量化取決于實際的應用場景。

以圖4中的微服務為例，我們搭建了一個GCN網(wǎng)絡，如圖5所示。其中，左邊為輸入層，右邊為輸出層，中間有2個或3個隱藏層，并且每個隱藏層的激活函數(shù)均為修正線性單元（ReLU）。

以圖4的子圖為例，圖6是鄰接矩陣和和度矩陣的實際數(shù)據(jù)。通過這些數(shù)據(jù)計算得到的拉普拉斯矩陣，隨后將進行公式（1）—（3）中的卷積運算。

整個學習過程為有監(jiān)督學習。系統(tǒng)先根據(jù)業(yè)務異常對節(jié)點進行標簽，然后把整個數(shù)據(jù)按7∶3的比例拆分成訓練數(shù)據(jù)和驗證數(shù)據(jù)。損失函數(shù)可以是比較通用的交叉熵損失函數(shù)。通過訓練學習，系統(tǒng)可以得到不同節(jié)點之間的分類、關聯(lián)程度和節(jié)點是否異常的模型。

通過學習我們可以看出，由于受到相鄰和其他節(jié)點的影響（相鄰關系越近，影響越大），圖中的每個節(jié)點都在時刻改變著自己的狀態(tài)，直至平衡。這里，我們?nèi)匀灰詧D4的子圖為例，VAS和CSB就是同一類節(jié)點，因此系統(tǒng)可以通過它們來確定關聯(lián)關系和根因關系。

此外，有3點需要注意：（1）前文所述的傳播表達方式是基于譜域方法而提出的。但是對整個網(wǎng)絡來說，由于節(jié)點和邊的關系非常復雜，除了內(nèi)存消耗巨大外，對D和A的求逆和行列式計算也將非常耗時，因此很多優(yōu)化方法目前被引入進來，比如基于空域的方法和節(jié)點采樣的方法等。（2）和DNN近似無限表達能力不一樣，GNN的表達能力是比較受限的[11]，當然，在云視頻微服務系統(tǒng)中，GNN的表達能力是完全能夠覆蓋遠不足萬計的微服務。（3）在一般的網(wǎng)絡搭建中，GCN后面會再設置一層MLP以協(xié)助業(yè)務判斷。由于這也是通用模型，不是本文討論的重點，故這里不再贅述。

5 視頻云系統(tǒng)智能運維能力的提升效果

視頻云微服務系統(tǒng)是基于K8s集群進行部署的，它主要通過配置運維策略、實時采集指標、可視化監(jiān)控、故障工單等，來實現(xiàn)信息技術運維（ITOps）。AIOps巧妙地將機器學習和知識圖譜相結合，取得了更好的運維效果。下面我們以微服務彈縮自愈場景來進行對比說明。一般來說，微服務指標包括CPU值、內(nèi)存、輸入輸出（IO）以及Java虛擬機（JVM）內(nèi)存等。傳統(tǒng)ITOps對CPU指標超限和一問題能夠處理得很好，但是對于內(nèi)存超限卻很難判斷，這是因為內(nèi)存會出現(xiàn)回收的情況。下面我們將對比測試這兩種情況。

視頻云的微服務藍圖主要包括：邏輯主機（Pod）數(shù)量共1個，CPU為2核，內(nèi)存為2 GB。傳統(tǒng)ITOps定義策略為：感知時間為1 min，當采集間隔時間為5 s，即1 min采樣12次，彈縮消耗時間為1 min。在感知時間內(nèi)，采樣中平均CPU消耗達85%時彈縮1個Pod，內(nèi)存消耗超過80%時彈縮1個Pod。測試時，我們按最終彈縮4個Pod為例，具體測試效果如圖7所示。

由圖7可知，傳統(tǒng)ITOps的彈縮是臺階式彈縮，即感知、彈縮、再感知、再彈縮，最終感知沒有異常時，則彈縮到位。在一次感知后，AIOps根據(jù)機器學習到的模型，直接進行一步到位的彈縮。圖7的測試是在假設感知時間是一致的條件下進行的。而實際上，AIOps的感知時間是按過去的時間窗口來預測的，它的感知時間會遠遠小于1 min。但即便是對于簡單的場景，AIOps的效果也會遠遠好于基于策略的ITOps。

從分類是否正確的角度來看，即是否應該彈縮和是否彈縮來看，ITOps根據(jù)策略定義來分類，AIOps根據(jù)機器學習來分類。這里，我們定義TP為應該彈縮，實際彈縮；FP為不應該彈縮，實際彈縮；FN為應該彈縮，實際未彈縮；TN為不應該探索，實際未彈縮。測試顯示，對于ITOps來說，TP=67，F(xiàn)P=7，F(xiàn)N=6，TN=20；對于AIOps來說，TP=65，F(xiàn)P=22，F(xiàn)N=8，TN=5。表1給出了在測試環(huán)境中100次彈縮是否準確的評價數(shù)據(jù)統(tǒng)計（統(tǒng)計公式見參考文獻[12]）。

由表1可知，AIOps在分類方面的表現(xiàn)比完全根據(jù)策略定義的ITOps更好。

除了微服務彈縮，在整個系統(tǒng)運維保障能力方面，AIOps比ITOps也有極大的提升，包括異常感知、故障診斷、故障自愈和故障預測等技術指標。以圖4的終端會議和媒體播放局部場景為例，該場景共有61類不同告警。故障平均修復時間（MTTR）包括故障感知、故障定位、故障診斷和故障恢復。由表2可知，與ITOps相比，AIOps至少提升了60%的故障修復效率。

除了在質量保障和效率方面的提升外，AIOps在成本優(yōu)化方面也有較大的提升。由于成本優(yōu)化是一個比較復雜的課題，而本文的闡述重點是質量保障和故障自愈，因此，本文中我們僅以視頻云微服務系統(tǒng)的K8s集群的成本，來做對比說明下。如表3所示，通過策略和人工經(jīng)驗的ITOps，僅在Pod資源優(yōu)化和非忙時間資源縮減方面有一定成效而AIOps在云存儲成本、GPU服務器和調(diào)整集群大小等方面表現(xiàn)更顯著。這是因為AIOps通過歷史數(shù)據(jù)的機器學習和數(shù)據(jù)挖掘，在成本優(yōu)化方面做得更科學、更深入，而不是簡單依靠人工經(jīng)驗等給出策略來控制成本。

6 結束語

在面向視頻云系統(tǒng)的云邊端復雜部署場景時，系統(tǒng)的運維保障變得極為復雜。AIOps技術能夠有效地提升視頻云的運維能力和QoE等級。與傳統(tǒng)ITOps相比，AIOps技術不僅能夠節(jié)約運維成本、提升運維效率，還能夠實現(xiàn)更加精準的運維服務、提升用戶體驗。

致謝

本研究得到中興通訊股份有限公司胡銳、付迎春、周祥生、弄慶鵬等的幫助，謹致謝意！

參考文獻

[1] ZHANG X， XIE L， GUO Z. Quality assessment and measurement for internet video streaming[J]. ZTE communications， 2019， 17（1）： 12-17. DOI： 10.12142/ZTECOM.201901003

[2] 董德尊， 歐陽碩. 分布式深度學習系統(tǒng)網(wǎng)絡通信優(yōu)化技術 [J]. 中興通訊技術， 2020， 26（5）： 2-7. DOI： 10.12142/ZTETJ.202005002

[3] 李建飛， 曹暢， 李奧， 等. 算力網(wǎng)絡中面向業(yè)務體驗的算力建模 [J]. 中興通訊技術， 2020， 26（5）： 34-38. DOI： 10.12142/ZTETJ.202005007

[4] AIOps標準工作組. 企業(yè)級AIOps實施建議白皮書 [R]. 2018

[5] 高志鵬， 堯聰聰， 肖楷樂. 移動邊緣計算：架構、應用和挑戰(zhàn) [J].中興通訊技術. 2019， 25（3）： 26-27. DOI： 10.12142/ZTETJ.201903004

[6] 龔正， 吳治輝， 王偉， 等. Kubernetes權威指南：從Docker到Kubernetes實踐全接觸 [M]. 北京：電子工業(yè)出版社， 2017： 93-171

[7] WU Z H， PAN S R， CHEN F W， et al. A comprehensive survey on graph neural networks[EB/OL]. [2020-11-10]. https：//arxiv.org/ abs/1901.00596

[8] CHAI D， WANG L Y， YANG Q. Bike flow prediction with multi-graph convolutional networks. [EB/OL]. [2020-11-10]. https：//arxiv. org/abs/1807.10934

[9] SCHLICHTKRULL M， KIPF T N， BLOEM P， et al. Modeling relational data with graph convolutional networks [C]//European Semantic Web Conference. Crete， Greece： Springer， 2018： 593-607

[10] YING R， HE R Y， CHEN K F， et al. Graph convolutional neural networks for web-scale recommender systems [EB/OL]. [2020-11-10]. https：//arxiv.org/abs/1806.01973v1

[11] RYOMA S. A survey on the expressive power of graph neural networks [EB/OL]. [2020-11-10]. https：//arxiv.org/abs/2003.04078

[12] 李航. 統(tǒng)計學習方法 [M]. 北京： 清華大學出版社， 2012： 10-19

作者簡介

徐代剛，中興通訊股份有限公司網(wǎng)絡智能平臺研發(fā)總工、OES運營技術專家委員會主任及首席架構師；研究方向為電信運營系統(tǒng)微服務架構和云化網(wǎng)絡智能技術。

姜磊，中興通訊股份有限公司網(wǎng)絡智能平臺高級架構師、OES運營技術專家委員會委員；研究方向為電信網(wǎng)絡智能運維、數(shù)據(jù)挖掘、機器學習和深度學習。

梅君君，中興通訊股份有限公司視頻云平臺研發(fā)總工、大視頻技術專家委員會委員；研究方向為視頻能力基礎設施云原生架構和低延時高性能實時音視頻通信技術。