與通常的介紹文章不同，本文結合作者從事智慧監控的實踐經驗，從聚合資料、明細資料兩種資料形態入手分析它們對模型效果上限的影響，並介紹了基於這兩種資料形態的智慧監控常用做法的本質。

一、業務背景

過去幾年中國移動網際網路發生了翻天覆地的變化，但凡是有流量入口的地方，各大公司都在不斷角逐，流量入口形式的不斷豐富，對應著背後業務形態的日趨複雜。從技術角度來看，過去平臺化的方式越來越難端到端的支撐快速發展的業務，進而演化出了中臺的概念，快速支撐業務的同時，也帶來了系統關係成網狀的複雜形態。業務形態、技術支援、運維規模等都在處於快速變化期。在這個業務快速增長期，一個不能穩定執行的系統意味著什麼？

通常穩定性都以一個百分比數字去描述，比如：全年系統執行穩定性為99.99%。我們又習慣叫99.99%為穩定性4個9。以4個9來算的話，一年365天大概有不到1個小時系統是不可用的，現今的大公司如BAT，每秒請求數量在幾萬是家常便飯。不到1小時的系統不可用對公司造成的影響是巨大的，輕則影響公司收益，重則失去使用者。

穩定性保障經歷了運維（Operation）、開發運維（DevOps）、質量（SRE）、智慧運維（AIOps）幾個階段（它們不完全互斥），最初Operation的階段往往是開發和運維各自為戰，在出現穩定問題時相互甩鍋，後來DevOps應運而生，通過開發運維一體化來保障穩定性，避免開發、運維隔離帶來的業務目標和運維目標的不一致問題，再往後DevOps進一步深化成質量保障體系，而不管是怎樣的形式，隨著複雜性的提升，單獨靠人工去保障穩定性已經不再可行，人們開始思考藉助人工智慧的“新動力”克服人工缺陷，打造一個7*24小時不停歇的智慧監控和定位的中臺。

智慧運維在工業界技術同行們不斷努力和嘗試下有一些落地的方案，在對常用做法進行歸納總結同時結合自己在工作中的使用經驗，對常見做法進行一些優缺點分析，希望對即將或正在從事智慧運維的同行們有一點啟發。

作為在工業界的人，我必須講究方法在實踐中的有效性，在做應用的這一波人裡，有一句流行話：“資料決定效果的上限，而演算法只是儘量逼近這個上限”，所以本文先從資料形態（聚合資料、明細資料，下文將詳細解釋）來分析方法的上限，然後再結合資料形態討論方法的優缺點。

由於我的知識有限，有錯誤遺漏之處請大家海涵。

二、從資料形態的角度看智慧監控與定位

智慧運維是人工智慧和運維結合的產物，而資料是人工智慧的“燃料”，特別是實踐機器學習的時候，往往用什麼樣的資料入模決定了應用是否成功的關鍵，它包括：資料型別（如：系統日誌、業務資料、函式呼叫堆疊、程式碼釋出、配置變更記錄、運維關鍵指標等）、資料形態（聚合資料、明細資料）。聚合資料是指通過聚合計算得到的彙總資料，比如運維關鍵指標。明細資料是指未通過聚合計算之前的資料。它們是兩種不同的資料形態，用它們做智慧運維的“燃料”有不同的優缺點。

2.1、聚合資料

聚合函式大家一定不陌生，sum、average等都是最常見聚合函式，當然你也可以自定義你的聚合函式，而聚合資料泛指通過聚合函式計算產出的資料。關鍵指標（KPI，Key Performance Index）是最常見的聚合資料，比如：在運維領域中技術KPI如CPU、記憶體使用率，業務KPI如支付成功率等。

上圖就是一個典型的KPI，橫軸是時間、縱軸是某項指標，運維同學往往關注KPI指標的異常變化趨勢，再通過人工分析去做問題排查。

聚合函式的設計往往按照運維人員可理解的方式設計，導致一旦報警準確，問題的語義資訊也同時明確，給定位排查帶來一些幫助，同時聚合後資料量驟減，避免秒級監控對儲存、計算的過分依賴，但聚合函式導致資料精度損失，並且會導致資料關聯的丟失，會導致監控報警只能依賴區域性資料，影響報警準確率的上限。

“聚合函式導致資料精度損失“這句話怎麼理解呢？舉例來說，99+1=100，但一旦做完加法，丟棄計算過程之後，再想要得到100=？+？在實踐中是不可能的，假設當加號右邊的1變成0，即99+0=99會出現系統故障時，在聚合計算之後，變化從100下降到99，1%的下降很可能導致故障的漏報，但如果計算過程未丟失，我們發現一個計算分支的指標從1下降到了0，100%的下降幾乎肯定能被檢測到。所以，聚合計算丟棄過程資料，而它蘊含了資訊，少了這部分資訊就像機器學習模型少了重要的特徵一樣，異動檢測效果上限必定受到影響。

“（聚合函式）會導致資料關聯的丟失”又怎麼理解呢？下圖是我司某業務的呼叫鏈路樹，每個樹節點是一個服務，和業界大部分設計良好的系統一樣，每次呼叫

都可以用一個全域性唯一的ID串聯，自然而然能得到資料之間的聯絡，當呼叫鏈路上某一個節點失敗時，有可能不足以斷定出現系統故障，但當許多關聯絡統出現問題時，出現問題的概率就大大上升了。而聚合計算導致全域性ID丟失，天然存在的資料關聯不復存在，只能假設在同一分鐘的聚合計算結果之間存在關係，但實際上由於系統呼叫也存在時間，導致僅靠時間無法完全還原資料關係。這就像做影象識別的時候，把一幅圖的空間聯絡打亂了一樣，大大增加了識別的難度，同樣影響異動檢測的效果。

2.2、明細資料

明細資料希望儘可能多的儲存系統狀態的上下文，比如：系統呼叫鏈路、每個節點的引數、CPU、網路等資料。其中能夠用全域性ID關聯的資料，儘量用它關聯。有了這部分資料，我們幾乎可以還原任何時候的系統狀態。但是，全量儲存的儲存代價是相當大的，在實踐中，往往會捨棄一些相對不太重要的資訊，以減少儲存和計算的開銷。

明細資料保留了資料聯絡、也不存在聚合函式的精度丟失問題，給機器學習模型提供了更多檢測特徵，合理利用通常能得到更好的異常檢測效果。通常，除了儲存、計算之外，要利用好明細資料還需要解決“明細粒度選擇”的問題：由於儲存問題導致在捨棄不重要資訊的時候，該丟哪些資訊？這個問題的產生是場景相關的，通常需要了解哪些資訊導致儲存爆炸，比如：double型資訊是否需要保留，如果需要必須分箱；列舉型別欄位，統計列舉值數量；list型資訊，是否需要排序等。同時，需要判斷這樣的操作是否是合理的，比如針對list型資訊，通常排序後去重可以降低對儲存的依賴，但是如果排序會導致明顯資料錯誤，那麼針對你的場景，需要設計其他“明細粒度選擇”的方法。

既然介紹了兩種資料形態以及它們對異常檢測效能上限的影響，下面再看看兩種資料形態檢測方法的通常做法和優缺點。

三、在實踐中基於兩種資料形態的異常檢測

3.1、基於KPI的異動檢測

傳統運維通常以KPI作為檢測物件，所以最早發展起來的方法是基於時間序列的預測KPI異動變化的一類。

基於時序預測KPI走勢的一類方法本質上是迴歸模型，只有1個KPI作為輸入預測其走勢的一類方法叫“單元時間序列預測”，傳統金融時序模型包括：Arima、滑動平均等、機器學習模型包括：LR、RNN、LSTM等，有多個KPI作為輸入預測1個或多個走勢的一類方法叫“多元時間序列預測”，傳統金融時序模型包括：向量自迴歸等、機器學習模型包括：Parallel LSTM等，有時還會有多條時序對齊的要求，通常用動態時間調整（DTW，Dynamic Time Warping）。下面是一些實際操作時的經驗，希望有一些幫助：

DTW是在恢復聚合資料丟失的資料關聯時比較有用的方法，但前提是要針對場景的問題做一些演算法微調，比如：系統呼叫時間通常在秒級，所以對齊的時候調整視窗不能太長，否則你會發現A系統呼叫量第1s的下跌，和B系統呼叫量第10s的下跌對齊了，而這是沒有意義的，畢竟演算法只是工具，有效是建模的同學要考慮的。

通常，在你沒有額外特徵可以引入之後，還可以利用時序特徵計算很多統計特徵，再利用機器學習模型去做學習，有時可以略微減少RSE。但實踐中不要花過多時間試圖去分析哪個統計特徵更有效果，我的實驗程式告訴我通常統計特徵的變化給我帶來的收效甚微，把經歷放在一些業務特徵引入上可能更好，而統計特徵的分析交給機器學習模型和研究者吧，我們要做的是多引入統計特徵即可。

在特徵數量較多的時候，儘量擬合能力較強的模型去做，比如LR用稍微高階一點，LSTM增加層數、每層的單元數、遍歷資料集的次數等。使用RSE做損失函式的時候，在波峰、波谷處通常預測曲線會更平滑，如果對於這部分的預測有強烈的擬合需求時，嘗試加入一些規則做後處理方法會得到意想不到的效果。

對於迴歸類模型，通常會有一些時間滯後，導致有一些誤報，如果報警準確率對你來說至關重要，那麼嘗試降低一點報警時效，在觀測到時間滯後現象後再嘗試報警。

3.2、基於系統呼叫引數的異動檢測

 假設我們已經解決了“明細資料粒度”選擇問題，得到了一段時間的系統呼叫引數，假設訓練集有N個例項，每個例項有M個特徵。

第一類方法是無監督異常檢測方法，比如：孤立森林、AutoEncoder等，可以從方法層面劃分為基於密度的、基於距離的等。但這些叫法都只不過是招式，不是核心，實戰中重點是我們需要清洗的理解損失函式的物理意義是否符合要檢測的異常定義，比如孤立森林，本質上他是在空間中用平行座標系的分割線不斷切割空間，更少的切割能夠分開的點，就更孤立。但這個假設在實踐中並不一定成立，因為少的不代表就是異常的。所以無監督異常檢測方法雖然層出不窮，花樣百出，讓大家覺得在方法層面很高大上，而在實踐中，真正找到適合場景的損失函式是一件困難的工作，往往需要不斷的實驗。但大家不要鑽牛角尖，認為方法就不重要了，它們在思路上給了我們很好的啟示。

第二類方法把無監督問題轉變為有監督問題，因為N個例項是帶有時間戳的，我們可以把它們按照時間戳排列起來，利用週期性出現的特徵給例項打標，讓模型去學習例項未來出現的概率，再利用預測例項出現概率與實際出現概率的偏差去做預警。這種方法將異常定義轉換成了學習系統狀態週期性，而系統呼叫有無週期性和是否出現異常理論上也不是一定有關係的，幸運的是，實際上系統呼叫符合一定週期性，例如：大家都是早上8~10點去上班，這段時間叫車協議支付、吃早飯線下掃碼等業務就是高峰。

三、總結

“資料決定效果的上限，而演算法只是儘量逼近這個上限”。所以，本文從異常檢測資料形態的角度出發，分析了它們對檢測模型效果的影響，同時給出了一些實踐中的經驗和理解，希望拋磚引玉，幫助到大家。

現階段的人工智慧善於解決問題定義良好、問題邊界清晰、且有大量標註資料的問題，比如：影象識別等。對於異常檢測，缺乏標註資料、問題定義模糊，在工業界、學術界都是一個挑戰，但是我相信在廣大行業同胞、學術界教授們的努力下，有一天無人值守的夢想可以實現。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562044/viewspace-2649248/，如需轉載，請註明出處，否則將追究法律責任。