一、智能運維現狀

大家對智能問答系統都很熟悉，目前許多APP都有智能問答系統——后臺是一個機器人，而不是真正的人回答問題。當前眾多研究者在對智能問答系統進行研究，提出了許多算法和技術，Google Scholar上關于智能問答系統的文章有30多萬不到35萬篇。但實際上，智能問答系統遠沒有達到真正的智能，回答的結果時常是答非所問，那么就會造成海量的算法和技術與差強人意的效果之間的偏差。

智能運維到現在大概有六七年的發展歷程，在此期間智能運維算法一直在快速地發展，包括對性能指標的時間序列的數據、對日志告警的數據以及近兩年對CMDB、調用鏈等圖的數據。算法的類型和效果也在不斷提升，包括指標異常檢測、容量預測、日志聚類、日志日常檢測、告警中的場景挖掘、根因定位等。接下來的內容主要涉及指標異常檢測、日志智能分析、告警數據分析三個類別。

?1、指標異常檢測

指標異常檢測是一個落地最多的智能運維場景，因為它數據容易準備，效果容易驗證，準確率、召回率的指標容易量化。目前許多公司對大規模指標進行異常檢測，比如1萬個指標、10萬個指標。

針對指標的異常檢測，研究者提出了大量的異常檢測算法，比如單指標、多指標檢測，基于統計、基于深度學習的模型，無監督、有監督的算法，以及近兩年許多公司和機構開源了異常檢測數據集和算法。但是，往往在落地的場景中應用的效果不盡如人意，主要問題如下：

1）誤報太多

• 設置閾值嚴，為了消除漏報，往往造成大量的誤報
• 異常數量多，運維人員難以處理，不得不忽略所有的指標異常告警

2）模型/參數難以設置

• 不同類型的指標，往往適合不同類型的模型和參數
• 無法單獨設置模型和參數，進行分類則效果不佳

3）缺乏有效的反饋和修正機制

• 缺乏問題發現能力，難以對指標異常進行類型、主機、時間段、業務等方面的展示和分析，難以對異常進行交互式探索，因此無法判斷異常是否應該報
• 缺乏基于反饋的模型調整能力，難以應對“這個不是我們認為的異常，后續檢測中不要再報了”的個性化需求

?2、日志智能分析

目前，大量企業上線了日志實時聚類和基于日志的異常檢測，主要解決了人工難以處理海量日志數據、基于規則的方法維護性差的問題。典型場景對海量日志做實時聚類，再做基于日志的異常檢測，比如變量取值異常、模板數量異常、語義異常等，但日志智能分析實踐同樣存在若干問題。

1）模板質量難以有效評估

• 日志聚類完之后，在將其聚到若干模板中時，模板質量難以有效評估，尤其是在實施過程或上線過程中，模板數量大，逐個人工判斷耗時太長，可能運維人員沒有充足的時間逐個人工判斷
• 不同的應用目標對模板的要求不同，可能做某類型的日志異常檢測時該模板不應該被泛化，但做另外一件事情可能就需要泛化，模板是否需要被泛化是一件非常主觀的事情

2）缺乏有效的反饋和修正機制

• 缺乏基于反饋的模板調整能力，難以應對“這種模板應該根據這個變量拆分”、“這個變量應該被泛化”之類的個性化需求
• 運維專家和算法人員的溝通難，運維專家與算法團隊之間隔著實施團隊，反饋鏈條長，且不是直接反饋

?3、告警數據分析

近年來告警相關項目快速增長，每天有成千上萬的告警，由于告警數量太多，運維人員難以有效處理和派單，因此通過算法進行告警壓縮、場景挖掘、根因定位越來越受重視。在告警智能處理中存在兩個典型問題：

1）告警模板提取效果不佳

• 告警數據更為靈活多變，不同運維人員的告警描述方式存在差異
• 包含大量中文，告警模板提取效果不盡如人意

2）根因定位效果欠佳

• CMDB質量有待提高，可能存在系統變更但CMDB沒有及時變更到最新場景的情況
• 可能真正的故障原因不存在于告警數據中，無法進行根因定位
• 標簽數據缺失，一方面故障數量少，另一方面企業由于涉及隱私等原因不愿意給予標簽

二、問題分析

我們在前面對于智能運維的現狀和具體的類別及相關問題進行了梳理，那么接下來是我個人的一些思考。我認為算法落地效果不盡如人意有兩個深層次原因：

?1、算法需要不斷迭代優化

我們時常認為智能運維的算法是開箱即用，但其實效果遠不是如此，算法需要不斷迭代優化。算法最開始的時候一般是一個通用算法，到具體在企業部署之后，它一定會成為一個定制化的算法。因為對于每一個具體的項目，算法需要和運維數據、業務特點、運維目標等深度融合，需要不斷進行打磨和適配。

1）算法本身：普遍缺乏反饋修正能力

對于“這個異常我不需要，后續檢測中不要再報了”、“這兩個模板應該合并掉，變量不能被泛化”之類的反饋，當前的模型尤其是深度學習模型很難有效吸收，其中主要是兩種能力的缺失：

• 發現問題的能力。比如說我們一天報2000個異常，能否有半小時或一小時的時間將這2000個異常過一遍，判斷其中哪些異常應該報，哪些不應該報，目前很少有人能夠在短時間內做到這點。

• 模型自動修正能力。比如給了很多“這個要報，那個不要報”之類的很多反饋，模型是否能夠很好地適應，因為這個適應其實是個百分百的適應，有的可能一個都不要報，有些是一定要報出來，這種對于模型也是比較難的。

2）實施過程：運維專家和算法人員的脫離

對于算法而言，最重要的是標簽數據和對算法結果的快速反饋，但是相關領域的專家可能熟悉機理卻不熟悉算法，由于溝通鏈條長、溝通成本高，運維專家和算法人員在一定程度上是脫離的。

?2、系統故障本身是超低頻事件

系統故障本身是一個超低頻的事件，嚴重的故障基本可能只出現一次，并且會被快速解決，不可能再出現。而算法需要基于歷史數據學規律進行優化提升，如果之前發現的故障后來很可能不再出現了，那么這其實是一個悖論。

我們前面也有提到完全依靠算法來實現自動化運維，至少在目前階段我覺得其實是不現實的，我們僅僅做異常檢測、日期類都沒有做得非常的好，那么我們相信現在算法能達到自動化運維嗎？我覺得更現實的目標是將算法作為一種讓運維更高效的輔助手段。

1）數據量太大，用算法來提高效率

• 對每天幾百TB的日志自動提取模板和變量
• 對上萬的指標自動進行異常檢測

2）在某些場景下，用算法來提高精度

因為在因果推斷里有些鏈條比較長，需要考慮的方面比較多，人的思考其實并沒有那么發達，所以算法在這些方面是可以幫助提高精度的。

3）作為一種定位故障過程的輔助手段，幫助運維人員靈活快速地查詢和探索數據

這是一種非常重要的能力，因為在很多項目里，算法結果的分析工作非常勞累辛苦。

4）算法作為一種積累知識的方式，構建知識圖譜

三、探索工作

?1、如何高效地支持反饋

如果只讓運維專家給10個異常/10個模板打標簽，應該怎么做？

1）快速發現問題的能力

首先可以通過異常置信度、日志模板置信度從2000個異常中選擇10個異常，然后通過異常立方體更加系統的能力對異常進行交互式探索，使異常可視化。

2）模型自動修正的能力

當我們希望將一個Excel或CSV的記錄人的電話、傳真信息的表格變成結構化數據進行處理時，我們可以通過算法進行自動轉化。通過我們給的少量樣本，算法能夠自動識別我們的目標，從而達成這個目標，這就是基于樣例的算法。基于樣例的算法在智能運維領域中同樣大有可為，另外還有一種方法是小樣本算法，通過給定少量標簽或案例快速達成目標是我們正在進行的嘗試。

?2、作為輔助手段的數據探索技術

1）基于自然語言的問答系統

人可以問類似以下自然語言的問題，能夠自動轉成SQL并出結果，具有高易用性，便于運維人員進行個性化數據探索。

• 在2019/11/28 11:25發生突增異常的指標有哪些？
• A應用發生異常次數最多的主機是哪臺？
• B應用告警次數最多的告警種類是什么？
• 最近一周內存使用率最高的十臺主機是哪些？
• 最近十天發生異常次數最多的應用是什么？
• 最近一周內失敗率最高的應用是哪個？

2）基于時間關聯的復雜查詢

用于事件關聯的快速發現,如下圖所示的HDFS日志，我們想查詢其中三個模板是否經常一起出現，PLQ查詢能夠更加簡潔高效，SQL查詢則會更加復雜。

3）基于拖拽式的分析流程實現

• 便于領域專家結合不同分析算法搭建分析流程
• 融合了異常檢測、聚類、場景挖掘等多種算法
• 支持不同語言開發的算法
• 支持輸入數據格式的智能學習

四、總結

智能運維中的算法正在發揮越來越大的作用，但同時算法落地仍有大量問題需要解決。算法不能一蹴而就，需要有持續優化的能力。不妨將算法作為一種運維的輔助手段，使運維人員也能靈活地分析數據，在運維過程中使其變得更高效。

作者：王鵬  復旦大學 教授/博導

復旦大學計算機科學技術學院，教授，博導。主要研究興趣包括：工業物聯網大數據、智能運維等。2012年獲得教育部自然科學二等獎（第三完成人）。主持或主要參與科技部重點研發計劃、國家青年973、自然科學重點 面上基金、上海市科委、上海市經信委的多個項目，以及華為、微軟、IBM等企業的資助項目。在數據庫領域頂級國際期刊和會議SIGMOD、VLDB、ICDE、TKDE等發表論文40多篇。擔任眾多國際學術會議的程序委員會委員，包括SIGKDD、ICDE、DASFAA、WAIM等。國際學術期刊VLDB Journal、TKDE、KIS等的審稿人。