複雜異常檢測如何快速落地？看看百度怎麼做

作者簡介:周偉    百度雲高階研發工程師

負責百度雲智慧運維（Noah）告警通告系統的設計和研發，在大規模分散式系統、運維監控、精準報警等方面具有廣泛的實踐經驗。

本文提到的異常檢測（Anomaly Detection）特指在運維領域中對時序資料的異常檢測，目的是為了發現時序資料中狀態的變化。

在我們看來，異常檢測一般可分為兩類：簡單異常檢測和複雜異常檢測

• 簡單異常檢測：一般指恆定閾值檢測，比如判斷可用性指標是否小於99.99%，如果小於則檢測結果為異常，否則檢測結果為正常。簡單恆定閾值檢測一般適用於可用性、資源利用率等監控指標。

• 複雜異常檢測：對於收入、錯誤率、流量等業務監控指標，需要檢測天/周/月/年等環比變化或者突增突降等狀態變化，這類業務監控指標的維度特徵較多（比如地域、運營商等），特徵變化也比較快（例如電商定期搞活動，流量瞬間漲起來，干擾正常的異常檢測）。恆定閾值檢測往往無法檢測到這類業務監控指標的狀態變更，所以還需要複雜異常檢測演算法來檢測業務監控指標的異常。為了發現監控指標的狀態變化，複雜異常檢測往往會採用機器學習、深度學習等比較複雜的技術。

和簡單異常檢測相比，複雜異常檢測對落地流程和異常檢測的執行平臺提出了更高的要求。

為了支援簡單異常檢測，異常檢測的執行平臺只需要能夠支援使用者新增自定義報警判斷規則即可。比如，對於上面提到的可用性指標，使用者可以在系統中將報警判斷規則配置為表示式“SLI < 99.99％”，然後等著接收報警就可以了。

然而對高階異常檢測演算法，演算法從研發到上線，一般需要包括以下三步：

1. 線下編寫演算法指令碼（一般是Matlab或Python指令碼），並根據歷史資料，離線訓練演算法所依賴的引數，透過用歷史Case進行回溯驗證效果。在這個過程中，演算法工程師需要反覆調整演算法引數，直到準確率和召回率都達到目標為止。

2. 將演算法指令碼改寫成線上程式碼（一般是C++、JAVA語言等編譯型語言）。這是因為線下編寫的演算法程式碼一般和線上執行程式碼使用不同語言開發，線下實驗演算法程式碼更側重研發效率，需要快速迭代和測試，而線上執行程式碼更側重執行效率，高效穩定執行。

3. 最後將改寫後的演算法程式碼生效到線上，並觀察其執行穩定性和資源消耗情況，及時調整線上資源分配情況。

以上流程在實踐的過程中存在若干阻塞點，導致複雜演算法落地時間長，演算法迭代效率低：

1. 線下實驗的過程中，歷史資料、歷史Case、不同實驗所使用的演算法、引數和效果全靠人工管理，常常出現指標資料不全，歷史Case不全，實驗過程兜圈子的情況。

2. 線下程式碼和線上程式碼開發語言不一樣，程式碼移植需要消耗比較多的時間，常常不能保證線上程式碼和線下程式碼的效果完全一致。

3. 一些複雜演算法對資源的消耗很大，貿然上線會影響監控系統部分或整體的穩定性。

上述阻塞點很容易導致演算法迭代速度跟不上指標變化速度的情況，最終限制了檢測效果的提升。所以，為了保證演算法的順利落地，我們需要提供一個新的異常檢測支援方案，滿足以下的需求：

1. 需要一個方便演算法快速迭代和演算法驗證的環境，用於線上下除錯演算法指令碼，並對歷史Case回溯，保證演算法的普適性。

2. 需要能彌合線下指令碼和線上程式碼鴻溝的機制，儘快將演算法生效到線上，能快速驗證演算法程式碼的真實效果，否則線下實驗指令碼和線上生效程式碼遷移成本太高，費事費力費程式設計師。

3. 需要評估線上程式碼的資源消耗和穩定性情況。因為複雜異常判斷演算法，其資源需求差異性特別大，比如有的會採用深度學習等非常耗CPU/GPU的演算法，而有的僅僅是簡單公式計算。另外，這類演算法開發迭代特別快，演算法程式碼很容易引入Bug，所以需要在不影響其他線上演算法執行的同時，採用線上真實流量驗證演算法穩定性。

4. 需要分離演算法程式碼和演算法引數，並支援演算法引數的獨立更新。因為演算法經過快速迭代後，會逐漸穩定下來，但是演算法的引數是對歷史資料的特徵表達，所以演算法所依賴的引數需要週期性更新，保障演算法達到最優效果。

為了解決上述問題和需求，我們推出了異常檢測執行平臺。基於執行平臺，演算法工程師可以用指令碼語言（當前支援Python指令碼語言）線下編寫異常檢測演算法，並線上下回溯歷史Case，當策略除錯完畢後，可以直接將Python演算法指令碼生效到到線上。同時，還支援演算法引數的獨立更新，大大加快演算法的生效速度。

異常檢測執行平臺包括三個環境：離線環境、線上環境、近線環境，下面詳細介紹。

離線環境會提供如圖1所示的策略開發框架，異常開發框架提供了Python執行環境和常用的Python庫，基於開發框架，演算法工程師採用一致的抽象介面編寫演算法程式碼，這樣可以保證線上下開發的演算法程式碼可以直接放到線上環境執行，從而彌合線下指令碼和線上程式碼鴻溝。為了回溯Case，開發框架還提供了歷史時序資料元件、異常判斷評價元件（支援準確率、召回率、F1 Score等評價指標）。由於複雜異常檢測演算法不像恆定閾值演算法可以根據資料直觀看出判斷結果，複雜異常檢測演算法往往需要執行並輸出異常判斷結果（能圖形化展示更好），才能評估演算法效果，所以開發框架提供了圖形元件，可以圖形化展示異常檢測結果。

圖1  策略開發框架

圖2展示了演算法開發介面，其中包括四個標準介面：

• load_model函式負責載入演算法引數；

• get_data函式負責載入指定時間段的歷史時序資料；

• initialize函式負責在演算法正式執行前進行初始化，比如載入演算法引數、申請記憶體等等；

• detect函式負責對時序資料點進行異常檢測，並返回異常檢測結果（正常或異常）。

圖2  用於高階異常檢測的抽象介面

演算法工程師線上下環境基於開發框架開發完策略演算法後，可以將演算法釋出到線上環境。線上環境提供了跟策略開發框架一致介面的策略執行時環境。策略執行時環境會接收上游傳送的時序資料，並驅動Python演算法指令碼週期性執行，同時將產生的異常判斷結果傳送到下游，用於報警通告。

圖3  線上環境架構

線上環境的架構圖如圖3所示，線上環境主要包括以下三個模組：

• 任務分發模組：負責管理運維人員提交的高階異常檢測演算法配置，並將每個演算法配置組裝成任務，分配給任務執行模組。

• 資料排程模組：資料排程模組週期性從任務管理模組同步任務的分配資訊，根據任務分配資訊，將每個任務所需的資料排程給相應的任務執行模組，同時將資料也Copy一份，寫入到時序資料快取中。

• 任務執行模組：任務執行模組週期性從任務分發模組拉取分配到的任務，併為每個任務啟動一個策略執行時環境。策略執行時環境支援跟開發框架相同的介面，所以可以直接驅動基於開發框架開發的演算法程式碼的執行。策略執行環境剛啟動的時候，會呼叫intialize函式，進行初始化操作，然後策略執行環境不斷接收資料排程模組排程過來的資料，並驅動呼叫detect函式，detect函式會對接收到的資料進行判斷，並返回判斷結果（正常或異常），執行時環境收到判斷結果後，將其傳送到下游，用於報警傳送。有時演算法在剛啟動或執行的時候，需要拉取近期的時序資料，這時透過get_data函式從時序資料快取中獲取即可。另外，任務執行時環境還會週期性檢測演算法依賴的引數是否有變更，如果演算法引數被更新了，則會呼叫load_model函式重新載入配置。

線上下環境編寫演算法程式碼，如果直接貿然上線到線上環境，往往會存在很多問題，所以策略演算法在離線環境驗證可用後，首先會放到近線環境執行起來，近線環境和線上環境的架構和功能其實沒有本質差別，只是用途不同而已。近線環境的目的，一方面是為了用線上真實流量資料來驗證演算法的資源消耗，以發現演算法執行的真實資源需求，只是不真正傳送告警而已；另一方面，是為了驗證演算法的穩定性，比如是否有記憶體洩漏、是否有崩掉、是否有錯誤日誌等等。如果發現有問題，演算法工程師可以快速調整並重新部署到近線環境進行驗證。

本文主要介紹了異常檢測的相關背景、應用場景和需求分析，然後我們給出了百度雲的高階異常檢測演算法快速落地方案——異常檢測執行平臺。目前執行在這套異常檢測執行平臺上的高階演算法超過20個，每天處理近千萬監控指標的異常判斷。演算法的線上迭代週期從周級別減少到天或小時級別，很好地支撐了業務方對不同高階異常檢測的需求。另外，我們還將平臺開放給業務運維人員使用，由業務運維人員研發的異常檢測演算法可以有效引入業務線人員的專家經驗。

關於高階異常檢測演算法的落地，有任何想法和疑問，歡迎留言一起交流。