阿里海量大資料平臺的運維智慧化實踐

本文根據徐小飛在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，同時所運維的物件也很複雜，所以我們需要更高效更智慧的手段。

簡而言之，玩資料，來阿里，準沒錯!