阿里海量大數據平台的運維智能化實踐

本文根據徐小飛在2018年5月12日【第九屆中國資料庫技術大會(DTCC)】現場演講內容整理而成。

講師簡介：

徐小飛，阿里巴巴技術專家，目前就職於阿里計算平台大數據基礎工程技術團隊，主要負責支撐阿里大數據智能運維體系(公司內部產品名稱——Tesla)的建設，團隊致力於打造通用的智能化SRE中台，目前該中台運維體系承載阿里10w+規模節點運維工作。

本文摘要：

介紹Tesla如何支撐阿里離線計算和實時計算兩大海量大數據平台的標準化日常運維運營，以及探索如何構築運維領域的知識圖譜，打造針對大數據平台和大數據業務的數據化全息投影，實現多維的立體化監控、智能決策分析、自動化執行的運維閉環。Tesla是面向企業級複雜業務系統的數據化驅動運維解決方案，解決方案包含一個統一運維門戶(運維工單、運維垂直搜索)和四個運維基礎平台(流程平台、配置平台、作業平台、數據平台)，集日常運維工單管理、自動化發布變更、統一配置管理、統一任務調度、智能監控告警管理、異常檢測預測、故障自愈等。

分享大綱：

• 運維新趨勢
• Tesla運維解決方案
• DataOps數據化運維
• 數據價值轉化
• AIOps征程

演講正文：

大家好，我叫徐小飛，很開心能夠有這樣的一個機會在這裡和大家交流。今天主要給大家介紹一下圍繞阿里大數據體系的的運維智能化實踐。

我所在的團隊叫大數據基礎工程技術，通俗點說就是大數據SRE(為什麼起基礎工程技術這個名字? SRE文化里有個最核心的點就是使用軟體工程的思想來解決運維問題)，我們團隊支撐的是整個阿里大數據生態的運維運營，並沉澱出一套自己的運維解決方案體系——Tesla，這套體系是一個分層體系，包含了面向運維領域功能的運維中台和面向具體大數據平台業務的運維應用。目前Tesla承載了阿里大數據平台及業務共10w+規模節點的日常運維工作。相信了解阿里的人都聽過這樣一個詞——「大中台和小前台」戰略，同樣在運維領域，我們也是利用這個戰略來構築我們的業務：大中台提供通用的運維領域功能，而小前台可以基於業務場景快速試錯、創新。首先我們先看下運維的新趨勢。

一.運維新趨勢

剛好這幾天Google IO大會也正在召開，相信在座的很多同學都會關注，今年的大會中有一個很吸引眼球的話題，就是在開場第一天放出來的兩段Demo視頻，是個電話錄音視頻，內容是Google助手幫助客戶打電話到髮廊或餐廳去做預約。那麼亮點在哪裡呢?在整個電話預約的過程中，髮廊和餐廳的人完全沒有感知到和他們交流的是AI機器人。換句話說，AI機器人已經達到了以假亂真的效果，不僅在交流過程中有語氣詞和思考，而且當話題出現中斷時，還會提出反問句，能讓話題回到機器人所要的情景進行下去。

Google對外宣稱在某些特定領域，例如預約領域，他們已經通過了圖靈測試。圖靈測試大家可以去了解一下，圖靈有一篇針對未來機器智能的論文，一句話解釋論文里的圖靈測試：當人機交互時，人類完全感覺不到對方是個機器人，那麼就標誌著進入了機器智能的時代。

大概在三年前，Google提出了AI戰略。時至今日，我們看到Google在很多領域都滲透了AI，Google的AI並不是做一個全新的AI產品，而是將AI賦能到它的頂尖產品中。所以，我們表面看到的是預約服務，但其實為了達到這個效果是需要很強大的數據+演算法的支撐。我們經常提到的ABC(AI，BigData，Cloud)，想要實現AI，前提一定是大數據和雲計算，而在運維領域也同樣是如此。這兩年AIOps特別火，同樣地我們認為要實現AIOps，一定是先有運維的數據和計算，就是說從DevOps到AIOps之間，有一段DataOps必經之路。

如何理解DataOps呢?首先，我們要拿數據來感知我們所運維的系統，繼而利用數據分析做一些決策，再往下就是去觸發自動化的智能閉環。我們認為DataOps中最核心的過程就是運維感知、決策和執行。

我們把無人駕駛和無人運維做了一個類比。無人駕駛也是Google第一個提出來的，現在有很多廠商投身其中，如果細看無人駕駛，其實我們發現與無人運維類似——無人駕駛是在傳統汽車上附加智能感知、決策、智能控制系統。但是真正的無人駕駛還沒有達到，即使是Tesla(馬斯克的特斯拉)也不例外。而終極AIOps想要達到的是也是無人運維的效果，即在DataOps 的感知、決策和執行三個階段都附加上AI智能。接下來先看下整體的Tesla運維解決方案。

二.Tesla運維解決方案

上面這張圖是阿里大數據的體系，左邊最底層是基礎設施，包含了底層依賴，機房、天基、Staragent;其上有兩大基礎平台，一個是飛天平台，這是完全自研的，另一個是Hadoop平台。這兩套平台之上分別對應的是MaxCompute和StreamCompute兩大存儲計算平台;再往上是數據應用層。而右邊是Tesla大數據運維解決方案，我們可以看到Tesla貫穿了整個阿里的大數據體系，負責從基礎設施到基礎平台到存儲計算平台的所有產品的運維支撐。

簡而言之，Tesla就是在為阿里的大數據保駕護航。

MaxCompute是大數據的核心業務，而DataWorks可以理解為是一個面向開發者的前端，是MaxCompute的門戶。 MaxCompute基本上承載了集團90%以上的計算和存儲。在阿里，凡是和數據打交道同學都會用到DataWorks。StreamCompute承載了集團幾十個BU的實時作業。大家可能感觸最多的是每年的雙11大屏，這背後都是由StreamCompute實時作業傳上去的，可以達到秒級、毫秒級。最後是我們內部的機器學習PAI和AnalyticDB。

這張圖是Tesla運維解決方案架構圖。整個Tesla運維解決方案是一個分層的體系，從SRE中台到SRE應用。整體是一個垂直體系，也可以拿SPI來分，中台最底層是IaaS，IaaS層是最基礎的公共集團的設施，之上是核心運維PaaS層，其中包含四大平台+兩大類服務。 四大平台與運維人日常的工作相關，分別是配置平台、作業平台、流程事件平台和數據分析平台。再往上就是SaaS層，提供了所有的平台和服務。Tesla平台支撐了阿里大數據的十幾個平台，因為每個大數據平台業務產品的運維特性都是不一樣的，肯定無法做到一套運維繫統支撐所有的產品運維運營，所以我們就採用了分層戰略： 運維開發團隊提供平台，而針對具體產品的運維應用由SRE同學利用平台去構築。典型的SRE應用包括常見的集群管理、資源管理、監控告警、故障管理等。在這張圖裡我們可以看到DataOps體現在數據分析平台這一層。

這張圖是應用維度。SRE應用這一層的功能也是分層的，最下面是其所依賴的基礎平台，往上是面向業務的功能(包含業務中心、服務管控、平台運營、工具服務、運維中心和運籌優化)，利用這些功能向上支撐具體的運維場景(圍繞穩定性、成本、質量、效率、安全以及體驗的維度)，最終服務好業務的各類用戶。

在運維/運營平台中抽象出了幾塊內容，開發框架、資源整合、運維數據化和智能分析。因為最終系統都是相似的，所以我們會給提供前後端框架、服務網關、二方依賴包以及工具插件，業務SRE只需在環境上去獲取數據，做數據處理、元數據管理以及提供數據查詢的服務。運維數據化(DataOps)就是我們前面提到的，智能分析支撐常見的運維場景，比如最典型的故障處理、監控分析、大促保障以及值班客服等，他們面臨的客戶是一堆客戶，這也是DataOps在SRE應用上的體現。接下來我們重點解釋到底什麼是DataOps。

三.DataOps數據化運維

什麼是DataOps?如何做DataOps?阿里五新戰略中有一個新能源，我們認為數據就是新能源，現在已經進入到信息爆炸的時代，大家刷淘寶天貓時的每一次行為都會觸發日誌，這些日誌最終都流到我們的平台里。如此海量的數據，如果能有效的組織管理好，那麼就可以從中挖掘出價值，但如果管理不好，就可能會是個大災難。

演算法+技術，再結合數據就會產生新能源，而現在比較通用的數據挑戰是我們怎麼有效的去收集、清洗數據?如何保證數據的實時性、準確性?如何將無序的、沒有結構的數據有序、有結構的分類、組織、存儲管理起來?如何通過演算法去打通數據，連接、分析數據，並從中提煉出價值?這一系列的問題就是DataOps需要解決的。

什麼是數據化運維? 我們這樣定義：就是把所有系統的運維數據全部採集起來、真正打通，深度挖掘這些數據的價值，為運維提供數據決策基礎和依賴。 從系統「穩定性、成本、效率、安全」多個維度去驅動自動化、智能化的運維運營，從而助力實現真正的AIOps。

相比於傳統運維，DataOps的改變可能就是把傳統的使用命令、人工決策的運維過程轉變成數據+演算法的模式。

DataOps是實現AIOps的一個必經之路，是一個運維閉環。如何做數據化運維呢?右邊這張圖來自《大數據之路》這本書，當然這張圖說的是阿里整個的數據中台，阿里數據中台把全公司所有和數據相關的東西都整合了起來，提供了一套統一的數據中台。其中，最下面是數據採集層，往上是資料庫同步工具，中間是MaxCompute和StreamCompute，也就是數據存儲計算層，最上面是數據服務層和數據應用層。

數據中台中的方案體系是OneData，它是用來規範數據中台，如何維護、組織、管理和使用數據的。OneData之上是OneService，有了這套組織管理和兩大計算平台之後，就可以提供各式各樣的數據服務，並再向上提供數據應用。在阿里，基本上所有的業務部門都是按照這個套路來做的。

如何做數據化運維?其實就是利用這套大數據體系來構築大數據的數據化運營體系。這句話可能有點難以理解，更直白一點說，這套體系是由我們來運維保障的，但是過程中我們也利用其來構築了運維運營體系。因為我們的使命是為阿里大數據保駕護航，而我們的做法也是用阿里大數據來做運維分析，數據化運維分解下來就是運維的數據採集、運維的數據計算、運維的數據服務以及運維的數據應用。

前面講的是方法論，現在講講具體的實操。利用數據中台，我們首先做的是按照OneData規範建立運維的數據倉庫，然後把所有運維相關的數據做分類抽象，包含公共數據、業務數據、元數據，runtime實時數據。基於這些數據抽象，我們提供了大量的運維服務和數據服務，比如異常檢測分析、故障自愈、可視化流程、運維搜索、運籌優化、全鏈路診斷以及業務驅動。下面結合幾個例子來具體解釋下如何做數據化運維。

以全鏈路分析診斷為例，MaxCompute是一套離線計算平台框架，每天有百萬級的任務在跑，這些任務都是由開發同學提交，當作業因為各種原因出現不可預知的錯誤，大家就會@運維值班人員看看是哪裡的問題。後來我們發現，大部分問題是相似的，所以就總結經驗，從用戶都在這個平台上提交作業到最後執行的每個階段都去打點、採集分析，做了一套全鏈路作業診斷工具。

這是一個自助式的全鏈路診斷產品，提供一個入口，用戶只要輸入作業ID，我們就能延伸到整個上下游去查詢所有的有可能的問題，包括它的資源申請情況、配置是否正確、數據依賴是否都已滿足、歷史情況如何、是否有長尾傾斜等等。

上圖中有我們工具的頁面截圖，可以看到左邊是有分類的，其實在做這個全鏈路分析工具的時候，我們就把這個場景和去醫院體檢做了個類比，體檢時醫生要針對病人的各個環節做判斷，然後輸出病人的狀態，OK還是不OK?如果有問題，立即提出來讓病人去某診室隨診。同樣的，我們也是針對作業做了多個維度的檢測，而且還會將診斷詳情、時間分析、圖表分析以及歷史對比等，全部都透視給用戶。最後的結果報告是用圖表分析的，例如稀疏圖形資源爭搶，毛刺圖形部分長尾、任意機器進程CPU消耗分析。

第二個案例場景是硬體自愈，目前我們已經有10萬+台物理機了，每天有大量的硬體故障在發生，比如硬碟壞了，主板壞了等等。如果機器比較少，那麼我們可能人肉或者直接提單就可以了，但是當量級到了一定程度，每天幾十單或者是上百單的硬體故障，這種方式就不適用了。

所以我們就利用這套數據化的思路做了一個硬體自愈的流程。我們也是從伺服器上採集到數據，然後流進流計算平台Blink再到數據倉庫，做檢測分析並得出決策。決策觸發流程平台做一些自動化執行的action，調用集群操作系統去做機器維修等。

硬體自愈的本質也是一個三階段的閉環，在這其中我們的角色有很多。例如有些故障重啟一下服務或者雙向配置即可解決，而有些故障需要使用萬能大法，重啟機器才能解決。如果碰到解決不了的問題就要進入無盤狀態，去做業務隔離、重新克隆、整機維修，維修完之後自動上線。整套流程全部是自動流轉，我們是無人值守的狀態。

四.數據價值轉化

通過前文的方法論和兩個案例，我們大概解釋了一下如何做數據化運維，接下來，我們再透視一下數據化運維的本質——從運維數據到知識的價值提取。

這裡會涉及到幾個概念，數據化運維的前提是先將一切對象數據化，也就是運維的全域數據，構築完之後，使用知識圖譜將這些數據連接起來，之後將數據當做服務提供給人，利用運維搜索去提供一些快速直達的服務。然後讓數據說話，數據即視圖，最後數據如果能清洗到一個決策時——有價值的知識，那麼我們就認為數據可以驅動決策。

全域數據，基本上是運維相關的日誌、事件、指標、報警等，特徵也比較多，多維度、多層次、時效性、關聯性等。這些東西的本質其實就是運維對象和運維事件。

有了全域數據之後，如何把數據連接起來?我們就利用實體與關係這兩個概念來構築運維知識圖譜。下面圖片是一個全息投影，可以比較形象地描述我們利用圖譜來做的事情。我們就是儘可能的利用實體及實體之間的關係，再結合一些外部runtime的數據去還原當時系統的運行情況，然後把它映射到現實場景上去做精細粒度的感知。

當前我們整套知識圖譜的數據量，實體數據大概在百萬級，關聯數據在千萬級，同時我們還關聯了很多外部runtime數據。

有了知識圖譜之後，要給SRE同學使用。我們提供了一套運維垂直搜索功能，這是一個工作模式的改變，之前運維同學都是將很多功能分門別類的排布好，但是當功能堆得越來越多時，用戶可能不知道要去哪裡找他要的東西。而我們提供的搜索功能，它可以通過關鍵詞來搜索相關的信息，例如搜索一個機器，那麼我們就把這個機器相關的信息都推給他，包括這個機器當前安裝的軟體、進程狀態、CPU內存、IO曲線等。

除此之外，我們還整合了阿里集團的所有運維資源，目的是為SRE提供一個垂直領域的搜索服務，改變運維習慣。同時，還提供了一個功能就是嵌入到某一個站點，提供站內的垂直搜索。

數據即視圖，當有了大量的數據之後，我們會希望在很多地方將這些數據展示出來。但我們發現這其中有很多事情都是重複工作，所以我們就基於運維的可視化整合了這條鏈路，我們把所有的數據都按照要展示的格式規範起來。這樣的話，只需要提供數據就可以在任意的地方展示，相當於數據本身是結構化的、可視化的。

可視化是基於Grafana，對接了很多的數據源。不過，由於Grafana是angularjs寫的，而我們的很多前端站點都是React，所以我們做了一套基於React的前端組件來適配Grafana後端數據源，提供無縫的圖表能力。根據SRE同學的反饋，幾分鐘之內就可以完成一張可靠的圖表開發。

數據決策。以前都是人去提單，然後由工單來驅動運維操作來對所用的對象進行管理。但是現在整個思路發生了逆轉，首先我們通過事件、監控等透視運維對象，並通過規則、演算法等決策服務做出決策，最終完成action執行。簡單來說，以前是人圍著機器轉，現在可能是機器圍著人轉。

以ChatOps智能運維助理為例，這個場景是某個同學想要知道某一台機器當前是什麼情況，他在工作群里@一下助理，然後輸入hostname，機器人就會返回這台機器的狀態，機器所在的分組、隸屬的集群、當前系統狀態是不是OK、硬體狀態是不是OK、安裝的服務軟體的狀態是不是OK……這其中每個狀態的結果都是一個鏈接，點擊之後就會跳轉到針對這個問題的詳細情況。

現在，針對服務狀態、機器狀態，我們正在把更多的場景都往ChatOps這套理念來推。它所做的就是將一些簡單重複的工作沉澱下來，讓這些信息直達用戶，縮短用戶與功能之間的距離。同時，我們還有一個兜底的意圖，因為ChatOps畢竟還是通過一些意圖去規則、處理東西，當沒有匹配到你的意圖的時候，可能就找不到了。這時，怎麼辦呢?我們把前面做的運維搜索來兜底，如果根據關鍵詞沒有搜索到，那麼我們就調用搜索介面來做反饋。

五.AIOps征程

說了這麼多，到底什麼是AIOps?AIOps中的AI經過修改後，目前最新的釋義是Artificial Intelligence。為什麼說實現AIOps必須要經過DataOps階段?因為我們認為AIOps其實就是在傳統的DataOps之上附加智能，如果在感知、決策、執行每個階段都附加上AI的附加值之後，我們認為這才真正實現了AIOps。常見的AI手段包括演算法、深度學習、神經網路等等。

AIOps絕對不是從無到有，它一定是隨著你在某個領域持續地構築、持續地積累，然後在每個階段附加上新的AI。

這張圖是我們團隊頭腦風暴出來的，我們發現無人駕駛和無人運維很像。SAE將無人駕駛劃分了六級L0到L5，他們認為當前市面上大部分的車都處於L2階段，即實現了一些基礎自動化，比如ABS防抱死系統、自動定速巡航等等。L1階段可能就是乞丐版，不具備這些功能的車。L3是有條件的自動駕駛(馬斯克的Tesla實際上只是L2.5)， L4是高度的自動駕駛，如果說L3還需要駕駛員坐在旁邊，出現問題時接管，而L4基本上在特定條件的路上完全無需駕駛員介入，車子能自動判斷做出決策。L5是完全自動駕駛，是一種理想狀態，可能很難達到。根據文檔的描述，L5階段，給定車輛一個起始地點和結束地點，其它就不用去管了(跨越國家、左道右道都能自動切換)，它自己會去判斷、處理一切，淡化了司機的概念。

類比無人駕駛，無人運維也可以分為6個階段，L0是人肉運維，L1是腳本、工具化運維，是當前各大公司都具備的一個狀態，L2是開發運維一體化DevOps，它的最大特徵是有一些簡單的規則、閾值的判斷，L3是數據化運維DataOps，最核心的東西就是數據化演算法，L4是高度智能化運維，這時系統已經完全具備了自動運維的能力，並能夠提供人機對話的交互。L5是 完全智能化運維，可能就像電影里的天網系統完全自主防禦，你想破壞它都不可能。最後以一個案例來介紹下我們在AIOps上的嘗試。

以Project智能遷移場景為例，在計算平台中，所有用戶的資源管理都是申請一個Project，計算平台根據配額組來分配資源，當前配額組的資源是不是夠用，有沒有超過預算?同時，對於系統我們也會有個期望，系統應該運行在一個什麼樣的狀態，核心指標應該是多少，水位是百分之多少，正常情況下不會觸發哪些相關事件……一旦系統在後台觸發了事件，系統會做自動判斷，執行智能遷移的Plan計算。如果想要達到系統所期望的運行狀態，需要將哪些Project做遷移，遷移到哪些集群，這時我們會通過ChatOps與人做一個確認的交互報備，通過自動智能的Project遷移之後，系統再次回到我們期望的狀態。在整個過程中，我們可以做到無人值守。

最後再整體回顧一下，首先，我們講了DevOps到AIOps的一個概念，重點講述了什麼是Tesla;然後定義了DataOps數據化運維，並以兩個案例講述了如何做DataOps;接下來，我們分析了數據化運維的本質，包括運維全域數據、知識圖譜和搜素、數據即視圖、數據驅動業務;最後，我們講述了AIOps並不是無中生有，而是DataOps+AI，並與無人駕駛做了類比。最後再來個廣告。

我們這裡有很多優勢也有很多挑戰。來阿里最大的優勢就是這套大數據體系實在太成熟了，以前我做數據化運維的相關工作都需要我去從無到有構築數據化體系，但在阿里，這一套觸手可用;同時我們所運維的對象本身就是阿里大數據，這又是一個可以跟阿里大數據親密接觸的地方;我們的舞台足夠大，量級至少在國內可以稱得上No.1，同時所運維的對象也很複雜，所以我們需要更高效更智能的手段。

簡而言之，玩數據，來阿里，准沒錯!

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！