在看不見的地方，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

但是在大規模線上系統中，數量龐大的屬性組合為檢測有效組合帶來了挑戰。為此，我們提出了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

 

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

你也許還想看：

● AI賦能版Excel： 龐大資料，一鍵分析

● 微軟Power BI：幫使用者發現資料洞察

● 成為資料專家，你只差一個Quick Insights的距離

感謝你關注“微軟研究院AI頭條”，我們期待你的留言和投稿，共建交流平臺。來稿請寄：msraai@microsoft.com。