在看不見的地方，AI正在7×24為你在線服務

編者按：當你使用在線系統來搜索網頁、編輯文檔、存儲圖片、聽音樂、看視頻、玩遊戲，並享受著行雲流水般的順暢服務時，正有幾十萬到上百萬台伺服器堅守在大後方，為你提供著7×24小時的可靠服務。超大的規模和超高的複雜度給服務的可靠性、可用性和性能都帶來了極大的挑戰。近年來，微軟亞洲研究院軟體分析組在與微軟在線服務部門合作，利用人工智慧前沿技術解決大規模在線系統服務的運維問題，成為微軟諸多產品如Office 365、Azure等的堅強後盾。本文中，軟體分析組的研究員將會展開介紹在線系統背後的相關研究工作和成果。

為了保證在線系統的服務質量和用戶體驗，公司運維部門需要實時監控系統運行狀況，以便對異常及時進行分析和處理。眾所周知，在運維發展的過程中，最早出現的是手工運維，但手工方式通常費事耗力，一直是運維人員的夢魘。後來，大量的自動化腳本實現了運維的自動化，大大提高了運維效率。不過隨著系統規模的日益增長，自動化的運維也變得差強人意。所幸，數據和AI時代的到來讓運維方式邁向智能化的歷史階段。運維智能化開始被越來越多的企業所重視，通過搭建集中監控平台，收集並記錄系統的各項運行狀態和執行邏輯信息，如網路流量，服務日誌等，實現對系統的全面感知。而隨著系統規模的增長，運維數據也在爆炸式增長，每天有上百億條日誌產生，給運維帶來了更大的挑戰。

我們長期深耕數據智能領域，利用大規模數據挖掘、機器學習和人工智慧技術對紛繁複雜的運維大數據進行實時分析，從而可以為系統維護提供有效的決策方案。如今，我們的研究成果已經應用到了微軟Skype、OneDrive、Office 365、Azure等諸多在線服務中。下面將主要從異常檢測、智能診斷、自動修復、和故障預測四個方面對我們的研究成果進行深入解析。

異常檢測

異常檢測指對不符合預期模式的事件或觀測值的識別。在線系統中的異常表現有響應延遲、性能減弱、甚至服務中斷等，用戶體驗會因此打了折扣。所以，異常檢測在保障穩定服務上尤為重要。

突發事件異常檢測

在線系統每天還會收到來自世界各地客戶報告的各種各樣的問題（Issue），每個問題可以用與之相關的屬性來描述，像用戶類型（TenantType）、產品功能（ProductFeature）、操作系統（ClientOS）等，這些屬性描述了問題發生的上下文，比如產品功能表明了用戶在使用產品的哪一項功能時出現了問題。

通常情況下，每天的問題報告數量相對穩定，但有時一個特定的屬性組合會導致報告數量的突發性增長，快速發現並解決這些問題對於保證用戶滿意度來說非常重要。下圖iDice左側展示了一個真實的突發事件，包含屬性組合Country=「India」，TenantType=「Edu」，Datacenter=「DC6」的問題報告的數量從每天70猛增到超過300，這個屬性組合能夠幫助運維工程師從紛繁複雜的原因中快速地定位到問題發生時的上下文。這個屬性組合被稱為有效組合（Effective Combination）。

但是在大規模在線系統中，數量龐大的屬性組合為檢測有效組合帶來了挑戰。為此，我們提出了iDice[1]來高效找到有效組合，降低系統的維護成本。圖iDice右側展示了iDice的整體架構。首先，我們會從問題報告中整理出所有可能的屬性組合，然後經過3次剪枝後再對剩下的屬性組合排序，最終找到造成問題突發增長的有效組合。其中，3次剪枝分別為基於影響力的剪枝（Impact based pruning ）、基於變化檢測的剪枝（Change detection based pruning）以及基於區分能力（Isolation Power）的剪枝，通過剪枝可以有效縮減有效組合的查找範圍。影響力（Impact）指對用戶的影響程度，對更多用戶造成影響的屬性組合被認為有更大的影響力，而有效組合理應是影響力大的屬性組合。此外，有效組合理應會造成報告數量的顯著增長。接著，我們基於信息熵原理定義了區分能力，用來快速確定有效組合。

為了提供更穩定的服務，除了KPI異常預測，我們還會對系統日誌進行異常事件識別，並支持對多維特徵時序數據的異常分析。對於系統日誌，通過日誌解析將非結構化的日誌信息轉換成結構化的日誌，再經過組合、不變因子挖掘，最終實現異常檢測，詳見文末參考文獻[2]。

智能診斷

如果把異常檢測比喻成一段高速公路上的堵車現象，那智能診斷的目標就是找到其背後的根本原因，是上下班高峰，還是交通事故，抑或是正在上演一場警匪角逐？

對異常的診斷基於對系統運行時產生的大量監測數據的深入分析。我們在實踐中遇到了如下挑戰：

1. 如何在海量指標數據中定位到異常原因？

2. 如何關聯時序型的異常數據和文本類型的記錄？

為了解決上述難題，我們先後提出了異構數據的關聯分析方法[3]，利用日誌數據進行問題定位的日誌診斷分析[4]，以及在海量指標數據下的異常識別（Anomaly Detection）和自動診斷（Auto Diagnosis）系統AD2。

一、異構數據關聯分析

時間序列（Time Series）數據和事件序列（Event Sequence）數據是兩類常見的系統數據，包含豐富的系統狀態信息。CPU使用率曲線就是一條典型的時間序列，而事件序列是用來記錄系統正發生的事情，比如當系統存儲不足時可能會記錄下一系列「Out of Memory」事件。下圖展示了CPU 使用率的時間序列和兩個系統任務（CPU密集型程序和磁碟密集型程序）之間的關係。

監控數據和系統狀態之間的相關性分析在異常診斷中發揮著重要的作用。為了定位異常原因，運維人員通常從在線服務的KPI指標（如宕機時間）和系統運行指標（如CPU使用率）的相關性切入。目前已經有很多工作研究時間序列數據和單一系統事件之間的相關性，但由於連續型的時間序列和時序型的事件序列是異構的，傳統的相關分析模型（如Pearson correlation和Spearman correlation）效果差強人意。而且在大規模系統中，一件事件的發生可能與一整段時間序列相關，而傳統的相關性分析只能處理點對點的相關性。

為此我們提出了創新性的方法來解決時間序列和事件序列的相關性問題[3]，我們將問題建模為雙樣本(two-sample)問題，再用基於最近鄰統計的方法來挖掘相關性。

二、日誌分析

打日誌是記錄系統運行相關信息的關鍵方法，日誌數據也成為問題診斷的重要資源[5]。一個微軟的服務系統每天會產生1PB的日誌數據，系統規模之大，複雜性之高的同時還帶來了海量日誌，一旦出現問題，手工檢查日誌需要耗費大量的時間。而且，與傳統軟體系統一勞永逸的漏洞修正方式不同，在大規模在線系統中，一個問題修正後還可能會反覆出現，因此在問題診斷時可能會做大量重複性勞動。日誌數據的類型也極具多樣性，但不是所有的日誌信息在問題診斷時都同等重要。

為了解決上述問題，我們提出了一種基於日誌聚類的問題診斷方法[4]。如下圖所示，日誌分析分為兩個階段，構造階段和產品階段。在構造階段，我們從測試環境（測試環境通常是一個小型的虛擬雲平台）中收集日誌數據，進行向量化（Log Vectorization）、分權重聚類後（Log Clustering），從每個集合中挑選一個代表性的日誌，構造日誌知識庫（Knowledge Base）。在產品階段，我們從大規模實際生產環境中收集日誌，進行同樣處理後與知識庫中的日誌進行核對。如果知識庫中存儲了這條日誌，代表該問題之前已經過，只需採用以往的經驗處理，如果沒出現過，再進行手工檢查。

三、AD2

AD2 的全稱是異常檢測和自動診斷（Anomaly Detection and Auto Diagnosis），AD2的自動診斷旨在解決海量指標數據下的異常診斷。

圖AD2 表明在一段時間內出現兩次服務異常，而在線系統從CPU、內存、網路、系統日誌、應用日誌、感測器等採集了上千種系統運行指標（Metric），而且這些指標之間存在複雜的關係，單獨研究問題和指標之間的相關性已經無法得出診斷結論，需要理解指標之間的相關性。

AD2基於這些指標數據構造出指標間的關係圖，再根據貝葉斯網路估算條件概率，從而診斷出引起問題的主要指標。

從2017年3月上線以來，AD2為Azure平台捕捉到數量可觀的異常情況，並提供了有效的診斷信息。

自動修復

平均修復時間（Mean Time to Restore, MTTR）是衡量在線系統可靠性以及保證用戶滿意度的重要指標。為了減少MTTR，通常的修復做法是在問題出現時人工確定一個合適的（糙快猛）的方式（比如重啟機器），等服務恢復正常後，再去挖掘並修復潛在的根本問題，因為「治本」比「治標」需要更多的時間。但是，人工確定修復方式一來耗時，大約佔用到90% MTTR，二來容易出錯，因為確定一個合適的修復方法需要很強的領域知識。由於大規模在線系統中的每台機器每天都會產生海量運行數據，人工修復的改革勢在必行。

為了解決人工修復的「事倍功半」問題，我們提出了自動產生修復建議的方法[6]，其主要思想是當一個新問題出現的時候，利用過去的診斷經驗來為新問題提供合適的解決方案。下圖展示了該策略的主要流程。首先，我們會根據問題（issue）的詳細日誌信息為其生成一個簽名（Signature），還建了一個問題庫記錄過去已經解決過的問題，其中每個問題都有一些基本信息，比如發生時間、地點（某集群，網路，或數據中心）、修復方案。其中，修復方案由一個三元組描述<verb, target, location>，verb是採取的動作如重啟，target是指組件或服務，如資料庫，location是指問題影響到的機器及機器位置。當一個新問題出現的時候，我們會去問題庫中尋找與其簽名相似的問題，如果找到就可以根據相似問題的修復方案來修復，否則就單獨人工處理。

在生成簽名的過程中，我們首先採用了形式概念方法（Formal Concept Analysis ）將高度相關的事件組合到一起，也就是一個Concept，並基於互信息衡量每個Concept與相應的日誌記錄之間的相關性，再根據相關數據生成問題籤名。

在實踐中，我們還遇到了其他挑戰並提出了相應的解決方法。自動修復技術已經應用到微軟的在線服務維護中，並有效地減少了MTTR，細節請參看文末論文[6].

Service Analysis Studio (SAS)

在系統實際運行中時而會發生某些系統故障，導致系統服務質量下降甚至服務中斷，通常稱為服務事故（Service Incident）。在過去的幾年中，很多大公司運作的在線系統都曾經出現過多次服務事故。這樣的服務事故往往會帶來巨大的經濟損失，並且嚴重損害公司的商業形象。因此，事故管理（Incident Management）對於保證在線服務系統的服務質量很重要。

一個典型的事故管理過程通常可以分為事故檢測接收和記錄、事故分類和升級分發、事故調查診斷、事故的解決和系統恢復等環節。事故管理的各個環節通常是通過分析從軟體系統收集到的大量監測數據來進行的，這些檢測數據包括系統運行過程中記錄的詳細日誌（log和trace），CPU及其他系統部件的計數器，機器、進程和服務程序產生的各種事件等不同來源的數據。這些監測數據往往包含大量能夠反映系統運行狀態和執行邏輯的信息，因此在絕大多數情況下能夠為事故的診斷、分析和解決提供足夠的支持。

在過去的幾年中，我們採用軟體解析的方法來解決在線系統中事故管理問題，開發了一個系統Service Analysis Studio（SAS）來幫助軟體維護人員和開發人員迅速處理、分析海量的系統監控數據，提高事故管理的效率和響應速度。具體來說，SAS包括如下分析方法（詳見文末論文[7]）：

1）可疑信息挖掘。從大量數據中自動找出可能與當前服務事故相關聯的信息，進而幫助定位事故發生的源頭和推測事故發生的機理；

2）缺陷組件定位。通過檢測野點的方法，定位到個別運行狀態「與眾不同」的組件。

3）診斷信息重用。SAS中為每個事故案例創建指紋(signature)，並且定義兩個案例間的相似度。當事故發生後，會查找是否存在相似的歷史案例，並在之前相似案例的解決方案的基礎上給當前事故提供參考解決方案。

4）分析結果綜合。為了使得SAS能夠非常容易地被用戶所理解和使用，我們將從不同分析演算法中得到的結果進行綜合,綜合的結果以一個報表的形式呈現出來以方便用戶使用。

SAS在2011年6月被微軟某在線產品部門所採用，並安裝在全球的數據中心，用於一個大規模在線服務產品的事故管理。我們從2012年開始收集SAS的用戶使用記錄。通過分析半年的使用記錄發現，工程師在處理大約86%的服務事故處理中使用了SAS，並且SAS能夠為解決其中的大約76%提供幫助。

故障預測

上文主要介紹了如何在故障出現之後進行高效的診斷和修復，更理想的情況是把問題扼殺在搖籃中。比如，如果可以提前預測出數據中心的節點（node）故障情況，就可以提前做數據遷移和資源分配，從而保障系統的高可靠性。

現有方法是把故障預測抽象為是與非的二分類問題，使用分類模型（如隨機森林、SVM）做預測，並取得了相當好的效果。但面對實際生產環境，這些「實驗室成果」則無能為力。首先，大規模複雜系統的故障原因多種多樣，可能是由硬體或軟體問題引起，分布在系統不同層級，也可能是多個組件共同作用產生的故障。數據特徵也十分多樣，包括數值型，類別型以及時間序列特徵，簡單模型已無法處理。其次，極度不平衡的正負樣本為在線預測帶來了極大的挑戰。健康節點（磁碟）被標記為負樣本，故障節點（磁碟）為正樣本，在磁碟故障預測中，每天Azure的故障磁碟與健康磁碟的比例大約3:100000，預測結果會傾向於把所有磁碟都預測為健康，帶來極低的召回率。而採樣方法對在線預測也不適用，因為採樣後的數據集無法代表真實情況，訓練出的模型也會存在偏差。

為此，我們和Azure的專家們密切合作，分析故障原因，挖掘系統日誌，提取重要特徵，並採用KANG演算法解決在線預測問題，得到預測樣本的故障概率，把最可能出現故障的樣本交給運維人員。

Reference

[1] Qingwei Lin, et al. iDice: Problem Identification for Emerging Issues. ICSE 2016

[2] Qiang Fu, et al. Contextual Analysis of Program Logs for Understanding System Behaviors. MSR 2013

[3] Chen Luo, et al. Correlatingevents with time series for Incident Diagnosis. KDD 2014

[4] Qingwei Lin, et al. Log Clustering based Problem Identification for Online Service Systems. ICSE 2016

[5] Qiang Fu et al. Where do developers log? An empiricalstudy on logging practices in industry. ICSE 2014

[6] Rui Ding et al. Mining Historical Issue Repositories to Heal Large-Scale Online Service Systems. DSN 2014

[7] Jian-Guang Lou, et al. Software Analytics for Incident Management of Online Services - An Experience Report. ASE 2013 Experience Track

推薦閱讀：