面向視頻云微服務系統的智能運維技術

徐代剛 姜磊 梅君君

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

關鍵詞：視頻云系統；數據挖掘；知識圖譜；圖神經網絡；智能運維

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大應用場景，尤其是相關的音視頻應用，得到了快速發展。此外，由于受到新冠肺炎疫情等不確定性因素的影響，企業或團體遠程辦公、遠程會議的場景和需求日益增多，相應的通信系統也變得日益復雜。以視頻會議為例，它需要支持雙流會議、多流會議，除了要具備編解碼、鏈路控制、會議控制等多種基本功能外，還要能夠管理用戶的安全接入、權限控制等。因此，一個良好的視頻系統，不僅要滿足用戶的業務需求，支撐音視頻編解碼、播放、合成、錄制、擴展現實（XR）以及會議等多種業務，還要支撐用戶的質量需求，從聽得清、看得清到聽得懂、看得懂，直至聽得真、看得真，以提升用戶體驗質量（QoE）。對于一個企業級視頻系統而言，為了提供優良的用戶感知，系統除了提供音視頻編解碼、XR渲染等技術外，還要能夠支持多租戶、高并發、大流量。整個系統應穩定可靠且具有高安全性，不僅能靈活控制終端的接入和退出，還可支持云邊協同，使系統部件可彈性伸縮。

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

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

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

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

1視頻云系統云邊部署架構

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

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

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

2視頻云系統智能運維架構

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

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

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

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

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

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

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

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

3視頻云系統故障自愈流程

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

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

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

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

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

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

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

4視頻云系統智能運維模型算法研究

4.1微服務系統故障分析

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

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

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

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

4.2 GNN

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

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

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

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

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

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

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

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

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

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

通過學習我們可以看出，由于受到相鄰和其他節點的影響（相鄰關系越近，影響越大），圖中的每個節點都在時刻改變著自己的狀態，直至平衡。這里，我們仍然以圖4的子圖為例，VAS和CSB就是同一類節點，因此系統可以通過它們來確定關聯關系和根因關系。

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

5 視頻云系統智能運維能力的提升效果

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

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

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

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

由表1可知，AIOps在分類方面的表現比完全根據策略定義的ITOps更好。

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

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

6 結束語

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

致謝

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

參考文獻

[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] 董德尊， 歐陽碩. 分布式深度學習系統網絡通信優化技術 [J]. 中興通訊技術， 2020， 26（5）： 2-7. DOI： 10.12142/ZTETJ.202005002

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

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

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

[6] 龔正， 吳治輝， 王偉， 等. Kubernetes權威指南：從Docker到Kubernetes實踐全接觸 [M]. 北京：電子工業出版社， 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] 李航. 統計學習方法 [M]. 北京： 清華大學出版社， 2012： 10-19

作者簡介

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

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

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