本文基於王石先生2022 GdevOps全球敏捷運維峰會 - 廣州現場演講的內容是有組織的。
講師介紹
希望中山大學統計學碩士畢業後，就職於華為，現任網易遊戲技術中心智慧型監控AIOPS團隊負責人，致力於將AIOPS應用到遊戲運維場景中，幫助SRE有效發現、定位和解決故障。 在智慧型運維領域擁有豐富的實踐經驗，帶領團隊打造從0-1到0的智慧型運維服務平台。
分享劇情梗概
1、網易遊戲AIOPS落地路線圖。
2. 異常檢測
3.故障定位。
根據Gartner的最新解釋，智慧型運維（AIops）是指大資料與機器習學習能力的融合，通過鬆散耦合和可擴充套件性，在數量、品種、速度三個維度上增加IT資料，從而為IT運維管理產品提供支援。 AIOps圍繞質量保障、成本管理、效率提公升等基礎運維場景，逐步構建智慧型運維場景。 在質量保障方面，保障現網穩定執行細分為異常檢測、故障診斷、故障檢測、故障自癒等基本場景。 在成本管理方面，細分為資源優化、容量規劃、效能優化等基礎場景。 在效率上，分為智慧型變革、智慧型問答、智慧型決策等基礎場景。
1、網易遊戲AIOPS落地路線圖。
自2024年以來，網易遊戲不斷探索AIOPS之路，努力實現從人工運維到智慧型運維的轉變。 自2024年起成立智慧型監控團隊，打造智慧型運維平台，至今已實現異常檢測、一級關聯分析、下鑽分析、日誌分析、運維機械人、故障定位、故障預警等。 此外，還有很多其他功能，如火焰圖分析、硬體**、CDN檔案發布等，都取得了不錯的實際效果。
2. 異常檢測
異常檢測是研究AIOps的唯一途徑，後續很多場景函式都是基於異常檢測的，這是乙個必須解決的問題。 異常檢測是指利用AI演算法，從監控資料中自動、實時、準確地發現異常，為後續診斷和“自癒”提供依據。 相較於傳統閾值配置成本高、誤報多、場景覆蓋率低等優點，異常檢測具有配置簡單、準確率高、場景覆蓋範圍廣、自動更新等優點。
對於異常檢測，其實網上很多文件或者書籍都給出了一些演算法或者工具，但是在實際應用的過程中，你會發現效果往往不是很好，究其原因就是這些演算法只能有效適應一些特定的場景，需要做大量的優化來適應實際場景。 為了更好地在實際場景中實現演算法，我們對演算法進行了一些調整和優化，並根據業務需求對指標進行劃分，以達到更好的檢測效果。 我們根據指標型別將異常檢測分為三種場景---業務指標（如遊戲數量）、效能指標（如CPU使用率）、文字資料（如日誌）三種場景，並使用不同的檢測演算法。
1、經營指標
業務指標週期性強、曲線波動小、指數幅度小、準確率和召回率要求高等特點。 我們知道監督模型具有呼叫率高、擴充套件性高等優點，因此我們考慮使用監督模型對業務指標進行異常檢測。 然而，監督模型需要大量的標註資料，但很難收集到足夠的異常資料用於異常檢測專案。 那麼，兩者之間的關係應該如何化解和平衡呢？ 我們構建了從樣本構建到報警視覺化的一整套檢測框架。
1） 樣品構建
考慮到樣本採集的難度，我們的樣本主要來自歷史KPI資料集和線上使用者標註資料兩個方面。 首先，對部分KPI資料集進行抽樣，採用iforest檢測等簡單無監督檢測模型獲取異常評分，通過不等比例分層抽樣篩選出疑似異常樣本和正常樣本，進行人工標註，分為訓練集和測試集，以及使用者模型訓練和測試。 函式啟動後，收集使用者標註資料進行模型優化。 使用者標註的資料僅用於本專案，避免因不同使用者認知差異異常導致的誤報。 還應該注意的是，當歷史異常資料不足時，可以通過異常生成來生成樣本，例如新增雜訊和設計抖動模式。
2） 預處理
預處理模組由曲線分類、缺失歸一化處理和特徵計算三部分組成。 通過LSTM+CNN實現曲線分類，將待檢測的KPI分為穩定、不穩定、未檢測三類，分類準確率可達93%+。 缺失值通過線性和預值填充以及最大-最小歸一化進行處理。 特徵包括統計特徵、擬合特徵、分類特徵、過濾特徵、自定義特徵等，構建近500維特徵。 考慮到無效特徵的問題，有必要選擇特徵，然後對其進行建模。
3）演算法模型
該模型主要使用常用模型，如RF XGB GBDT等，然後使用LR進行積分和檢測。
4） 視覺化
視覺化部分包括告警、快速標註、異常檢視三個模組。 通過**告警形式，在告警訊息中新增快速標註鏈結，使用者收到告警後可以快速確認是否存在異常並進行標記。
通過監督模型，可以達到高病態的檢測效果，線上檢測效果可以達到90%+，可以滿足使用者的需求。
2. 績效指標
監督檢測模型可以很好地檢測業務指標，但不適用於效能指標場景。 如上所述，績效指標量級大、型別複雜、不確定。 如果還考慮使用監督模型，會花費大量的標註和訓練成本，這對業務的大規模部署並不友好。 因此，我們使用無監督模型來檢測效能型別指標。
我們將其分為毛刺、漂移、高頻、線性趨勢四種型別，通過不同的檢測模型進行檢測，使用者可以根據自己的需求選擇報警型別。
毛刺型別：毛刺異常是最常見的型別，可以使用差分和 SR 演算法進行檢測，這兩種演算法都有很好的結果。
漂移型別：對於漂移問題，首先需要分解STL週期，以分解週期、趨勢和殘差項。 然後，採用均值漂移和魯棒回歸演算法進行檢測;
高頻型：高頻是毛刺的一種變體，有時你並不關心時間抖動，但當它持續時，你需要注意它。 因此，所使用的檢測演算法也會有不同的型別，可以使用多步差分檢測。
線性趨勢型別：線性趨勢主要用於監控記憶體洩漏型別，可以先通過STL分解，然後進行LR回歸和MK檢測。
最後，有必要進行週期性抑制的步驟，以避免週期性誤報。
無監督檢測模型可以達到80%+的呼叫率，基本可以滿足使用者期望。 逐個報警，幫助使用者快速確認報警的正確性。
3. 文字資料
業務的快速發展對系統的穩定性提出了更高的要求，每個系統每天都會產生大量的日誌
系統存在潛在異常，但淹沒在海量日誌中，部分專案每天的告警量可達1w+，如何合併告警。
故障發生後，日誌告警量太大，無法定位。
當新版本啟動時，系統的行為發生了變化，但無法感知。
這些問題，歸根結底是由於日誌訊息太多，格式各異，無法很好地分類。 智慧型日誌分析基於大資料和AI演算法，提供實時智慧型日誌分類和日誌指標異常檢測。 該模型用於根據相似度對日誌文字進行分類，並自動提取相應的日誌模板。 如下圖所示，可以從兩個日誌中提取模板。
目前，業界對數分類的演算法比較成熟，很多演算法都能取得不錯的效果。 我們使用drain演算法進行初次分類，然後拼寫進行二次分類，以解決在不同模板中劃分不同長度的日誌進行初次分類的問題。
獲取日誌模板後，您可以根據日誌模板的數量進行異常檢測。 智慧型異常檢測，比對不同時間段的分類日誌數量，利用機器習模型自動識別與歷史趨勢不一致的突變或日誌型別，並發出告警訊息
該模型基於兩天內歷史日誌的分布進行訓練，以習學習正常的日誌波動週期。
分析日誌的整體分布，減少單型別日誌中小抖動導致的誤報。
自動選擇影響最大的 topn 日誌。
與指標異常檢測不同，日誌異常檢測可以檢測型別異常，這對程式故障排除有很大幫助。 此外，日誌分類對日誌治理也有很大幫助，在新專案服務啟動時，可以通過檢視日誌模板，根據需要整理和刪除無效日誌。
3.故障定位。
在標準故障處理過程中，故障定位一般可分為兩個階段：
失效前止損：可以快速獲取可用於止損決策的資訊，並據此進行止損操作以恢復服務。
失效止損後：進一步找到故障的深層次原因，確定故障的根本原因，將線上環境恢復到正常狀態。
在遊戲場景中，隨著遊戲和系統架構的日益複雜，運維人員接收到的告警資訊也變得多樣化
遊戲架構越來越複雜，故障發生後的排查過程比較長。
故障發生後，往往會觸發多個告警，但這些告警是分散的，沒有按照一定的規則進行分類和視覺化。 因此，在故障排除過程中需要手動整理和過濾告警。
目前，故障定位依靠人工經驗，難以復用。
1. 資源
在資源維度上，可以區分機器、網路渠道、SaaS進行分析和異常資訊。
1） 機器
對最近 20 分鐘內的所有指標執行異常檢測，並計算異常檢測分數。 然後，根據異常越早越可能是根本原因，指標異常越嚴重越可能是根本原因，機器故障越嚴重越可能是根本原因的標準，給出了最先的異常機器。
2）網路通道
利用Adtributor演算法，按區域、運算元等維度進行下鑽分析，給出TOPN異常維度。
3）saas
目前我們的SaaS已經有了比較完整的告警，可以直接獲取異常結果進行彙總。
*問題可以通過日誌分類和異常檢測直接發現，並給出topn異常模板。
3.手動操作
人為部分主要是變更事件，它與變更系統相關聯，與故障發生前的變更事件相關聯，並提醒異常情況。
4. 歷史失敗
除了分析機器、**等問題外，定位故障根源的更有效方法是關聯歷史故障。 如果該故障的異常效能與歷史故障的異常效能相似，那麼很可能是由同一原因引起的，因此歷史故障原因可以作為故障的根本原因。 計算當前斷層和歷史斷層的tanimoto係數，推薦最大tanimoto值和超過閾值的topn斷層及其根本原因。
整體故障定位過程，檢測故障的發生情況，基於拓撲資源、人為因素、歷史故障等角度，採用不同方法分析根源。 如果檢測到遊戲中的人數減少，則啟動故障定位過程，檢測到機器A的網路連線異常，告警網路問題，手動調查公網故障原因。