站長資訊網中國應用性能管理行業盛宴——2016中國應用性能管理大會(簡稱APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召開。APMCon由聽云、極客邦和InfoQ聯合主辦的作為國內APM領域最具影響力的技術大會，首次舉辦的APMCon以“驅動應用架構優化與創新”為主題，致力于推動APM在國內的成長與發展。
清華大學計算機系副教授 裴丹于運維自動化專場發表了題為《基于機器學習的智能運維》的演講，現場分享了基于機器學習的智能運維目前面臨的挑戰和解決思路。
以下為演講實錄：
我今天分享的題目是《基于機器學習的智能運維》，下面是今天這個報告的大概內容：
首先會做一個背景的介紹;為什么清華大學的老師做的科研跟運維有那么多關系?智能運維現在已經有一個很清晰的趨勢，從基于規則的智能運維自動化逐漸轉為基于機器學習了;再介紹幾個跟百度的運維部門、搜索部門進行合作的案例;最后，還要講一下挑戰與思路。
一、背景介紹
談一下參加這次大會的感受，昨天各位講師們的報告，特別是今天早上幾位講師的報告特別精彩，講到了在生產一線過程中遇到的各種挑戰以及大家的實踐和經驗，我們又加了運維的群，對于像我這樣在科研領域做運維相關科研的工作者來說，感覺找到了組織。介紹一下我的經驗，特別是跟海峰老師開場的時候，講的一個概念是相關的。海峰老師提到說我們做運維很苦，正好我大概在去年這個時候，我在百度的運維部門，講了一下做運維如何做得更高大上一些，我的題目叫做《我的運維之路》。我們先簡單看一下，我個人學術上的官方簡歷。
我讀了博士，然后在AT&T研究院實習，AT&T研究院前身是貝爾實驗室的一部分，這里面大概有200個博士，有C++發明者、防火墻之父，當然我其實沒有怎么見到過他們，但是辦公室是在一起的。之后在里面做了大概6年時間，發了不少論文，得了一些獎，發表了23項運維相關的專利。然后，回清華做了不少科研，這是我的官方簡歷。
實際上我在做什么事情?我就是一個運維人員。在一個30萬人的大公司里面做運維，當然主要是通過大數據分析的方法。我讀博期間跟美國各種運維人員打交道了五年;在實習過程中，喜歡上了分析實際的運維數據;真正在那邊工作的時候，基本上就是一個第五級的運維，做的事情是基于大數據技術管理網絡和應用的性能，各種網絡協議、IPTV、Video等等;回到清華做科研的時候，開設的也是網絡性能管理/應用性能管理相關的課程，所有的科研都是跟運維相關的，在國內有一些合作者，包括百度的運維部門、搜索部門以及中石油數據中心等等。我可以認為自己是一個運維人員，很高興在這里跟大家分享我們之前的一些經驗。
為什么說運維是可以做得很高大上的事情?這是一個會議叫SIGCOMM，網絡里面最頂級的會議，如果計算機網絡的事情是像電影一樣，這就是奧斯卡，每年大概錄用三四十篇論文，錄用一篇，就跟中彩票一樣。我們看它的submission，就是這么多，跟我們運維相關的占了40%。
再看評委會，我只列出了AT&T研究院里面的前實習人員和前員工的一些同事們，基本上現在都到大學里當教授了。所以說運維苦不苦，是不是可以做得更高大上一些，取決于怎么做。數據分析、機器學習，這是很好的路線。再看評委會，我只列出了AT&T研究院里面的前實習人員和前員工的一些同事們，基本上現在都到大學里當教授了。所以說運維苦不苦，是不是可以做得更高大上一些，取決于怎么做。數據分析、機器學習，這是很好的路線。
不光是最頂級的會議，我們還有一個專門做運維相關的會議。這個會議，就是這撥人里面，覺得SIGCOMM這個會一年30多篇，實在是收得太少了，我們再開一個會議，全部都是運維相關的，這是一個頂級的會議，是我科研領域一個主要的戰場之一。
鋪墊一下，就是說運維是有很多可以鉆研的地方，有很多科研問題。
簡單介紹一下我在清華大學的實驗室，叫NetMan。我的網絡管理實驗室做的科研，基本上都是跟NPM、APM運維相關的。我們跟互聯網公司做一些合作，主要做運維相關的自動化工作，跟SmoothAPP相關的運維工作，跟清華校園網WiFi做一些網絡性能優化的工作。我們做了一個核心的基于云的運維算法平臺，具體這些運維的應用，下面都有一個核心的算法，再下面還有一個大數據分析的平臺，就是常用的各種開源工具。
前面所講的是背景部分。我想要表達的一點，工業界、學術界應該在運維領域里面能夠密切合作，各取所需。工業界有很多實際問題，有很多的經驗，也有實際的數據，學術界老師們有時間，有算法，有學生，大家一起結合，這樣就會產生很好的效果。
值得各位運維界同仁們關注的就是學術界的頂級會議，我比較推薦的是上面圖中的這些會議，這些會基本上一年三五十篇論文的樣子，簡單瀏覽一下，跟大家做得工作是不是相關，瀏覽一下最新的會議論文集，看看有沒有相關的，還是很有幫助的。美國的工業界，像谷歌、Facebook都已經在這些會議上發表過一些論文，包括他們在工程上的一些實踐。
二、智能運維：從基于規則到基于學習
簡單介紹一下智能運維大概的歷程，基于規則到基于機器學習。我簡單回顧一下，我們這個趨勢，不光是說我們這個領域的趨勢，整個人工智能領域發展的趨勢。人工智能也是經歷了起起伏伏，最近又非常火?；練v程，就是從基于專家庫規則到逐漸變成機器學習，再到深度學習。
我講一下幾年前基于專家庫規則到機器學習的經歷。我們在做降維分析的時候，需要一個規則集，什么事件導致另外一個事件，再導致額外頂級的事件，最后倒推回來，什么導致了這個事情。我們當時針對骨干網做的各種事件的關聯分析，基本上是基于規則的。當時CDN的性能事件，這個事件導致這個事件，單獨對它進行分析，如果這個事件發生，可以通過監測到的各種事件一直推到這兒。當時做出來的時候，起到了很好的效果，發表了論文，審稿評價也很高，也有專利，現在還在非常常規地使用，并且用得很好，效果很好。但是這里面有個問題，規則是由運維人員給出來的，為什么能夠運行的很好?因為在網絡骨干網上面情況不是那么復雜，網絡協議一層接一層，事件比較少，所以比較容易把規則弄出來。
我們跟百度進行合作的時候，發現不是那么好做。因為在互聯網公司里面，大家都在講微服務，模塊特別多，規模很大，百度這邊一百多個產品線，上萬個微服務模塊，上萬臺機器，每天上萬個軟件更新，想通過人把這些規則表達出來，運行到你的系統里，根本就不行。我們試了一下，很快就碰壁了。最后怎么辦?我們采用了基于機器學習，把這些規則挖出來。我們在做的過程中不斷總結，不斷遇到新的問題，實現了基于規則的智能運維過渡到基于機器學習。
機器學習本身已經有很多年了，有很多成熟的算法。要想把機器學習的應用做成功，要有數據，有標注數據，還要有工具(算法和系統)，還要有應用。
對于我們運維領域來說，這幾點到底是怎么做的?
第一點是數據，互聯網的應用天然就有海量日志作為特征數據，想各種辦法做優化存儲。在運行過程中遇到數據不夠用還能按需自主生成，這是很好的。
第二點，在運維日常工作中還會產生各種標注數據，比如說工單系統，發生一次運維事件之后，具體負責診斷的人員會記錄下過程，這個過程會被反饋到系統里面，我們可以從里面學到東西，反過來提升運維水平。
第三點就是應用，做出來的系統，我們運維人員就是用戶，我們可以設計、部署、使用、并受益于智能運維系統，形成有效閉環。建模、測量、分析、決策、控制，很容易形成一個閉環。我們能夠形成閉環，因為我們有這樣的優勢。
總結一下，基于機器學習的智能運維具有得天獨厚的基礎，互聯網應用天然有海量日志作為特征數據，運維日常工作本身就是產生標注數據的來源，擁有大量成熟的機器學習算法和開源系統，可以直接用于改善我們的應用，所以我個人有一個預測，智能運維在今后若干年會有飛速的發展。
三、百度案例
下面講一下實際的案例，這邊有三個案例：
第一個場景，橫軸是時間，縱軸是百度的搜索流量，大概是一天幾億條的級別，隨著時間的變化，每天早上到中午上升，到下午到晚上下去，我們要在這個曲線里面找到它的異常點，要在這樣一個本身就在變化的曲線里面，能夠自動化的找到它的坑，并且進行告警。那么多算法，如何挑選算法?如何把閾值自動設出來?這是第一個場景。
第二個場景，我們要秒級。對于搜索引擎來說，就是要1秒的指標，這個時候有30%超過1秒，我們的目標是要降到20%及以下，如何找到具體的優化方法把它降下來?我們有很多優化工具，但是不知道到底用哪個，因為數據太復雜了，這是第二個應用場景。
第三個場景，自動關聯KPI異常與版本上線。上線的過程中，隨時都有可能發生問題，發生問題的時候，如何迅速判斷出來是你這次上線導致發生的問題?有可能是你上線導致的，也有可能不是，那么多因素，剛才說了幾十萬臺機器，你怎么判斷出來?這是百度實際搜索廣告的收入，我們看到有一個上線事件，收入在上線之后掉下來了。
下面這個是我們一個學生在百度實習的時候做出來的一個方案，基于機器學習的KPI自動化異常檢測。
橫軸是時間，縱軸是流量，要找到異常。我們要迅速識別出來，并且準確識別出來，幫助我們迅速進行診斷和修復，進一步阻止潛在風險。
我們學術界，包括其他的領域，包括股票市場，已經研究幾十年了，如何根據持續的曲線預測到下一個值是多少?有很多算法。我們的運維人員，就是我們的領域專家，會對自己檢測的KPI進行負責，但是我們有海量的數據，這KPI又是千變萬化各種各樣的，三個曲線就很不一樣，如何在這些具體的KPI曲線里取得良好的匹配?這是非常難的一件事情。
我們看看為什么是這樣的?有一個運維人員負責檢測這樣的曲線，假如說要試用一下算法，學術界的常規算法，要跟算法開發人員進行一些描述。算法開發人員說，你看我這兒有三個參數，把你的異常按照我的三個參數描述一下，運維人員肯定不干這個事情。開發人員還不了解KPI的專業知識，就想差不多做一做吧，做完了之后說你看看效果怎么樣?往往效果差強人意，再來迭代一下，可能幾個月就過去了。
運維人員難以事先給出準確、量化的異常定義;對于開發人員來說，選擇和綜合不同的檢測器需要很多人力;檢測器算法復雜，參數調節不直觀，這些都是存在的問題。
所以我們方法的主要思想是，做一個機器學習的工具。我們跟著運維人員學，做一個案例學一個，把他的知識學下來，不需要挑具體的檢測算法，把這個事情做出來，根據歷史的數據以及它的異常學到這個東西。
運維人員需要做什么事情?我看著這些KPI的曲線，這段是異常，標注出來，就有了標注數據。本身就是有特征數據的，提供一下，說你這個小徒弟，你要想把它做好，我有一個要求，準確率要超過80%，小徒弟就拼命的跟師傅學。
具體做的時候，比如說KPI的具體曲線，假如說這里有一個異常點，我們把能拿到的理論界上，學術界上的各種算法都已經實現了，它還有各種參數，把參數空間掃一遍，大概100多種，用集體的智慧把KPI到底是不是異常，通過跟運維人員去學，把這個學出來。為什么能夠工作?就是因為它的基本工作原理，就是我會學歷史信息，學到了之后生成一些信號，對于同樣的異常會有預測值，紅色是檢測出來的信號。檢測出來的信號略有不同，但是我們覺得集體的智慧，能夠最后給出一個非常好的效果，這就是一個基本的思路。
如何把它轉化成機器學習的問題?我們有特征數據、有標注，想要的就是它是異常還是非異常，就是一個簡單的監督機器學習分類的問題。運維人員進行標注，產生各種特征數據，這就是剛才100多種檢測器給出的特征數據，然后進行分類，效果還是比較理想的。
? 但是，還是有很多實際的挑戰，我們簡單提一個挑戰。第一個挑戰，我們運維人員需要標注，我得花多長時間去標注?在實際運維過程中，那些真正的異常并沒有那么多，本身數量相對比較少。如果能做出一些比較高效的標記工具，是能夠很好的幫助我們的。如果把這個標注工具像做一個互聯網產品一樣，做得非常好，能夠節省標注人員很多的時間。我們做了很多工作，鼠標加鍵盤，瀏覽同比、環比的數據，上面有放大縮小，想標注一個數據，拿著鼠標拖一下就OK了。一個月里面的異常數據，最后由運維人員實際進行標注，大概一個月也就花五六分鐘的時間，就搞定了。
?還有很多其他的挑戰，比如說歷史數據中異常種類比較少，類別不均衡問題，還有冗余和無關特征等。
下面是一個整體的設計。
那么，拿實際運維的數據進行檢測的時候效果怎么樣呢?
? 這里拿了四組數據，三組是百度的，一組是清華校園網的。一般的操作，分別對這些數據配一組閾值。我們不管這個數據是什么樣的，就是用一種算法把它搞定，就拿剛才給出的運維小徒弟這樣的算法，把100多種其他的算法都跑了一遍，比較了一下，在四組數據里面，我們算法的準確率不是第一就是第二，而且我們的好處是不用調參數。超過我們這個算法，普通的可能要把100多種試一下，我們這個不用試，直接就出來。
為了讓運維更高效，可以讓告警工作更智能，無需人工選擇繁雜的檢測器，無需調參，把它做得像一個互聯網產品一樣好。這是第一個案例，關于智能告警的。理論上學術界有很多漂亮的算法，如何在實際中落地的問題，在這個過程中我們使用的是機器學習的方案。
我們看一下第二個案例，剛才說的秒級。先看一個概念，搜索響應時間：
搜索響應時間，這個就是首屏時間了。對于綜合搜索來說，用戶在瀏覽器上輸入一個關鍵字，點一下按紐，直到首屏搜索結果返回來，當然這里面有一些過程。
這個為什么很重要?這就是錢。對于亞馬遜來說，如果響應時間增加100毫秒，銷量降低1%。對于谷歌來說，每增加100毫秒到400毫秒搜索，用戶數就會下降0.2%到0.6%，所以非常重要。
看一下在實際中搜索響應時間是什么樣的?
橫軸是搜索響應時間，縱軸是CDF。70%的搜索響應時間是低于1秒，是符合要求的。30%的時間是高于1秒的，是不達標的。那怎么辦呢?大于1秒的搜索原因到底是什么?如何改進?這里面也是一個機器學習的問題。各種日志非常多，答案就藏在日志里面，問題是如何拿到日志分析出來。我們看一下日志的形式：
對于用戶每一次搜索，都有他來自于哪個運營商，瀏覽器內核是什么，返回結果里面圖片有多少，返回結果有沒有廣告，后臺負載如何等信息。這次響應，它的響應時間是多少，大于1秒就是不理想，小于1秒就是比較理想，我們有足夠多的數據，一天上億，還有標注，這個標注比較簡單了。
我們現在來回答幾個問題，在這么多維度的數據里邊，如何找出它響應時間比較高的時候，高響應時間容易發生的條件是什么?哪些HSRT條件比較流行?如果找出流行的條件，我們就找到了一些線索，就知道如何去優化。我們能不能在實際優化之前，事先看一下，有可能優化的結果是什么?基本上想做的就是這么一個事情。這里面有些細節我們就跳過，想表達的意思是說對于多維度數據，如果只看單維度的數據，會有各種各樣的問題。
在分析多維屬性搜索日志的時候也會有很多挑戰：
第一，單維度屬性分析方法無法揭示不同條件屬性的組合帶來的影響。
第二，屬性之間還存在著潛在的依賴關系，所以單維度分析的結論可能是片面的。
第三，得到的HSRT條件可重疊，每次HSRT被計算多次，不易理解。你如果單維度看，圖片數量大于30%，貢獻了50%的響應時間，看一下其他的維度，加起來發現120%，這都是單維度看存在的問題。
因為每個維度有各種各樣的取值，一旦組合，空間就爆炸了，人是不可能做的，就算是做了可視化的工具，人是不可能一個個試來得出結論，必須靠機器學習的方法，所以我們把這個問題建模成分類問題，利用監督機器學習算法，決策樹得到直觀分類模型。
下面這個是我們當時設計的一個架構圖，每天日志來了之后，輸入到機器學習決策樹的模型里面，分析出每天高響應時間的條件，跨天進行分析，之后再去做一些準實驗，最后得出一些結果。
下面這個是我們第一步完成了之后，得出的一個決策樹，生成決策樹的過程，基本上拿一些現成的工具，把數據導進去，調一些參數就OK了。
我們會看一個月的時間內，每天都獲得的數據，我們得出一個月里面，哪些條件比較流行，然后，在此基礎上，做一些準實驗。不是說分析出來了之后，就真的上線調這些優化條件，比如說得出這樣的組合，當圖片數量大于10，它的瀏覽器引擎不是WebKit，里面沒有打廣告，它會容易響應時間比較高。給了我們一些啟示，具體哪個條件導致的?優化哪個維度會產生比較好的結果?這不知道。我如果把每個條件調一下，這個大于10，變成小于10，這個條件的組合，在實際的日志數據里面就是存在的，把這個數據取出來，看一下它的響應延遲到底是高還是低，這就是準實驗，諸如此類都做一些，很容易得出一些結論。
我們針對當時的場景，圖片數量過多是導致響應時間比較長的主要瓶頸，是當時最重要的瓶頸，具體對這個進行了優化，大家可能就比較熟悉了，部署了base64 encoding來提高“數量多、體積小”的圖片傳輸速度。
這里想強調一點，這個優化方式，大家都知道，但是在沒有這樣分析的情況下，你并沒有把握上線之后，就有效果。假如說你運維部門的KPI指標，超過20%就不達標，如果低于20%就達標了，上線這一個就達標了。各種比較都很清晰，就是這樣的一個工具，有很多日志，你做一些基于機器學習的分析，找到目前最重要的瓶頸，把這些瓶頸跟拿到手的各種優化的方式方法，應用一下，就能得到很好的效果，這個效果是很不錯的，通用性也比較高。
第三個案例跳過去吧，大概意思是說自動更新會產生很多問題，我簡單直接把案例給出來就好了。
最后給出一個案例，這個案例就是說百度上線了一個反點擊作弊的版本，上線之后，廣告收入就出現了下降，實際上用我們這個系統做了一下，10分鐘能夠準確檢測出問題。而人在具體做的時候，要客戶申述、檢查KPI、定位問題，要一個半小時，差異還是很大的。
剛才舉了幾個具體的案例，其實還有其他的很多案例：
• 異常檢測之后的故障定位
• 故障止損建議
• 故障根因分析
• 數據中心交換機故障預測
▪ 海量Syslog日志壓縮成少量有意義的事件
• 基于機器學習的系統優化(如TCP運行參數)
我們在學術界來說，我們也不做產品，我們是針對一線生產環境中遇到的各種有挑戰性的問題，做一些具體的算法。我們的目標就是做一些智能運維算法的集合，運行在云上面，它會有一些標準的API。標準的API支持任意時序數據，它有一個時間戳，有一個關鍵指標，這個關鍵指標針對不同場景會不一樣，有銷售額、利潤、訂單數、轉化率等等不同屬性，經過這樣的分析之后，跑到云里面，就能得出一些通用性的結果。
四、挑戰與思路
這里我想給大家一些具體的啟示，包括我們自己的一些思考。
智能運維到底有哪些可行的目標?我們的步子不能邁得太大，又不能太保守，我們到底想達到什么樣的效果?誰拿著槍，誰就處于主導地位。像R2-D2是運維人員的可靠助手，最后還是人來起主導作用。
很重要的就取決于人工智能本身發展到哪個地步，下面是我們清華大學張院士的一個報告。第一個圖中人工智能解決了一些問題，知其然，又知其所以然。第二個圖是知其然，不知其所以然，這個棋我知道它下的好，但是為什么好，計算機算出來的，我并不知道。人工智能發展到現在的階段，比較可靠的是這個地步：知其然，而不知其所以然，技術方面，通過機器學習相對成熟，在一定條件下比人好。到后面既不知其然，又不知其所以然，以及連問題都不知道，人工智能還沒有到那個地步。我們要自動化那些“知其然而不知其所以然”的運維任務。
2、如何更系統的應用機器學習技術。機器學習紛繁復雜，簡單說一下。特征選取的時候，早期可以用一些全部數據+容忍度高的算法，如隨機森林，還有特征工程、自動選取(深度學習);不同機器學習算法適用不同的問題;一個比較行之有效的方法，大家做日常運維過程中，可以跟學術界進行具體探討，針對眼前問題一起探討一下，可能比較容易找到適合的起點。工業界跟學術界針對具體問題進行密切合作是一個有效的策略。
3、如何從現有ticket數據中提取有價值信息。我們可以把ticketing系統作為智能運維的一部分來設計。
4、如何把智能運維延伸到智能運營?我們有各種各樣的數據，數據都在那兒，企業的痛點是，光有海量數據，缺乏真正精準的運營和行動之間有效轉化的工具。其實我們思考一下，我們看的那些KPI，如果抽象成時序數據，跟電商的銷售數據，跟游戲的KPI指標沒有本質的區別。如果抽象成算法層面，可能都有很好的應用場景，具體還會有一些額外的挑戰，但是如果在算法層面進行更多投入，可以跳出運維本身到智能運營這塊。
總結一下今天的報告。
• 基于機器學習的智能運維，在今后幾年會有飛速的發展，因為它有得天獨厚的數據、標注和應用。
• 智能運維的終極可行目標，是運維人員高效可靠的助手。
• 智能運維能夠更系統應用機器學習技術，學術界和工業界應能夠在一些具體問題上密切合作。
• 更系統的數據采集和標注會幫助智能運維更快發展
• 下一步把智能運維的技術延伸到智能運營里面。
Q&A
Q1：第一個案例中有標注過程，您做了一個工具加速了標注，我想問一下，因為您后來說你們的準確率已經達到100%了。
裴丹：沒有到100%，是說它性能比別的好，取決于不同的情況70%、80%、90%的都有。
Q2：做到80%、90%的標注，標注樣本有多少數量級?另外，肯定要持續運行，一共運行了多少個月達到80%多?
裴丹：標注樣本一個月大概十幾個、幾十個。一共大概運行了七、八個月，我們還在做另外一件事情，人工地注入一些異常，根據歷史數據學到異常的特征，人工注入，讓運維人員能夠進行標注。
Q3：人工注入是百度在線注入?可以手工去改嗎?
裴丹：歷史數據注入，可能在線注入。不能手工改的，是load到標注界面里去的。
Q4：特征提取和特征工程您是分開來說的，特征工程是指一些方法特征?還是什么意思?
裴丹：主要是推動各種統計方法學選哪些特征應該用在機器學習模型里，以及對哪些特征進行轉換。
Q5：剛才咱們那些所謂的算法都是已知算法?還是說我們能夠在這里面自己學習一些算法?
裴丹：我們現在正在用卷積神經網絡等，通過深度學習的方法，數據來了，我就把它自動學出來了，不用已知的算法。
Q6：剛才咱們那個采樣，很多都是指定的關鍵數據，關鍵數據的篩選能不能也是智能化的去做?
裴丹：這倒是一個很好的方向，目前還都是運維人員比較關心，并且已經檢測了的數據，數據已經采集上來了，我們做監控和異常檢測。下一步可以朝您剛才說的方向去做一下嘗試，就是說如何動態的、智能的去選取檢測哪些KPI，目前還沒有做這方面的嘗試。
Q7：咱們現在所有的數據都采集上來以后，是挑選了一些影響最大的數據進行處理和分析的嗎?
裴丹：剛才說的是，凡是已經進行監控的這些KPI，我們剛才聽到幾位老師介紹的，基本上可以監控的都監控，我說的進行智能的異常檢測是已經監控的KPI里面做更好的工作。
Q8：是有動作的成分了嗎?
裴丹：這個動作的成分是在很早之前發生的，沒有數據，我也沒法異常檢測，數據已經被采集了，前面做了很多大量的基礎工作，我們就常規采集了數據進行監測就行了。
特別提醒：本網內容轉載自其他媒體，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯系我們，本站將會在24小時內處理完畢。
