分享：范倫挺-高級運維專家
編輯：白凡
講師介紹：
首先簡單介紹一下我自己，我叫范倫挺，也算是運維的老兵了，大概 2008年開始進入運維行業(yè)，現(xiàn)在就職于阿里巴巴計算平臺事業(yè)部大數(shù)據(jù)基礎工程技術團隊。
先后負責過阿里 MaxCompute、AnalyticDB、PAI等大數(shù)據(jù)產(chǎn)品運維工作，目前主要專注于實時計算平臺 Stream-Compute 的運維工作。
今天我的演講主要從以下四部分來講：
一、運維進階；
二、一體化運維平臺；
三、重點介紹一下 DataOps 實踐
最后一部分是在 AIOps 方向的探索
運維的階段可能很多場合很多人都講過，但這里有一點不一樣，從人肉運維到自動化運維，再到 AIOps 中間應該還有個過渡階段，當然大家也可以把它理解為 AIOps 的初級階段。
那這個和 AIOps 之間的區(qū)別是什么？DataOps 從理論上來講也是一樣，主要依據(jù)于數(shù)據(jù)加各種算法模型能夠給出一個比較智能的結(jié)果。它相比 AIOps 更多是在于它給出的結(jié)果是一個輔助決策的作用，就你不敢拿它的結(jié)論直接去對接你的自動化平臺。
AIOps 實際在人這個決策上會有很大的區(qū)別，只是進行一些異常的響應，平常沒事就不需要人的干預。DataOps 還是需要經(jīng)過人的決策過程，這是兩者之間最大的區(qū)別，目前還是主要處在 DataOps 的階段，離 AIOps 還是有一定距離。
這是整個阿里巴巴計算平臺事業(yè)部所負責的一些技術架構，下面有兩大分布式計算引擎，在此之上會有很多的大數(shù)據(jù)計算平臺，像剛剛提到 MaxCompute 等等，各種類型的離線計算平臺、實時計算平臺、存儲平臺、數(shù)據(jù)通道等等都是基于下面兩個大的計算引擎去構建的，這整體的物理體量在10w 以上。
這里有幾個可能大家比較熟悉一點的，GMV 媒體大屏，這就是基于實時計算的計算平臺做的匯總。生意參謀，提供行業(yè)內(nèi)的各種營銷數(shù)據(jù)。
那為了解決或者運維好多引擎多平臺的應用，我們構建了這樣一個分層的運維解決方案，整體來講我們把運維平臺也抽象成了三層：
運維的 laaS 層，這些主要依賴于集團的基礎設施，不需要我們部門投很多的力量去解決的。
基于它之上就有所謂的運維 PaaS 層，也包括公共服務的用戶管理、角色管理。
那再上一層 PaaS，客戶對于這些平臺所希望得到的功能訴求也是不一樣的，所以應用這一層個性化的，基于公共的服務層快速構建自己的應用站點。
我們看一下所謂的一站式運維平臺到底在解決什么問題，因為不同公司的場景不一樣，是不是一定要到那繁雜的程度也是不一定的，能解決自己的問題就好。你看看運維在這角色中到底每天在忙什么，是什么樣的人來找你，他們找你是因為什么樣的事情。
實際上這里大的類別來講就是解決兩個信息流的問題：
一是信息流由下往上，就是看“看”的問題，到底服務穩(wěn)不穩(wěn)定、服務運行怎么樣；
二是命令流，從上往下，包括自己服務的上下線等等，所以自己去規(guī)劃的時候一般是運維平臺要解決的問題從“看”和“做”兩方面，去做一些解決自己痛點的落地。
所謂的自動化程度在這里會有一個UI視圖，人可以通過這個視圖去解決這兩個大的問題，再厲害一點可能連接這兩個信息流之間的是AI技術，形成一個信息流的閉環(huán)，在這個階段可能就是所謂的AI Ops，正常來講是信息收集、加工處理、決策，再信息回流看反饋是什么樣的。
既然把這個階段叫做 DataOps，肯定是離不開數(shù)據(jù)的，數(shù)據(jù)是它的基礎，運維的數(shù)據(jù)是需要按照標準的數(shù)倉原則進行建設。右邊這張圖顯示的是整個數(shù)據(jù)正常的采集、存儲最后到加工、應用層的常見步驟，這是從《大數(shù)據(jù)之路》中拿來的。
常見的運維數(shù)據(jù)，第一類是維度數(shù)據(jù)（元數(shù)據(jù)），服務器、服務器IP是什么，類似于這樣的一些靜態(tài)信息。另一類是度量數(shù)據(jù)（運行時），也就是指標或者事件類的，還有一類是日志類的。這是運維中最重要的幾大類型數(shù)據(jù)，也是做 DataOps的基礎。
這個復雜圖是當前我們做 DataOps 的數(shù)據(jù)架構圖，在這里拿出來和大家交流一下，首先左邊還是提到剛才的原則，數(shù)倉建設的規(guī)范。
我們會把數(shù)據(jù)做一個抽象，上面有好幾個大數(shù)據(jù)平臺要管，每個大數(shù)據(jù)平臺會有對應小組的人去負責它的應用那一層運維，所以我們會把重復的，公共的，各個產(chǎn)品都會用到的數(shù)據(jù)，像機器、指標、日志、監(jiān)控、報警等的公共信息全部抽取在一起，放在一起去做清洗加工存儲。所以會分為公共數(shù)據(jù)和業(yè)務數(shù)據(jù)兩大類型，基于這之上再去構建各種各樣的運維場景，像故障自愈、異常檢測。
下面就這里的一些場景給大家舉些例子。
第一個例子是運維搜索的，簡單講一下知識圖譜，運維世界里更多是實體與實體間的關系，用知識圖譜的表達方式或者數(shù)據(jù)的存儲形式去表達會更合適一些，尤其是在后面講到的搜索場景里，有其獨特的優(yōu)勢。
基于知識圖譜的運維搜索，前面看到一站式的運維體系，這個平臺是比較龐大的，比較復雜，那用戶進來以后大家都會面臨一個問題，總有些人不滿意說找不到點，所以我們會有個一站式的搜索入口，你在搜索框里敲想要什么想干什么，比如說有人想做個隊列擴容，那只要輸入隊列，就會把隊列相關的實體、動作，包括屬性有哪些全部列在這里，那肯定有一個是他想干的。
當然你也可以直接輸入這個隊列的名稱，然后也能給出來這個隊列相關的。用起來還是很好用，站點過于龐雜，面對的用戶又很多，很難滿足所有人的胃口，那讓他們方便的來使用這個平臺。
基于這個還可以去做 ChatOps，比如說你輸一個機器，機器現(xiàn)在的狀態(tài)怎樣，哪個分組，哪個機房，也可以有些基礎的基于文檔常見問題的問答，或者說讓它開一個缺陷出來，類似這樣。
當前ChatOps做的還是比較簡單一點，還是以查詢式的為主，就主要是解決重復的一些簡單的答疑類的操作。也就說真正執(zhí)行命令操作類的基于ChatOps的目前做的還少一點。
下一個場景是關于作業(yè)診斷，那么多的用戶會來問這個作業(yè)跑的有點慢，你來幫我看看怎么了，這是很煩人的一個事情。為了解決這個問題就提供端到端的作業(yè)診斷，用戶輸入作業(yè)以后它會去診斷，跟著這個作業(yè)全生命周期的流程，我這里講的所有都是基于說有能力且已經(jīng)收集好那些信息，而且有了實時性才能去做的。
這里會去看說這個作業(yè)分工在哪些機器上，會把相關的機器拉出來，這些機器本身又有沒有問題，有了這個以后基本上初級的問題就不用再來問。
后面再來深入展開一下機器診斷，如果它有fover就給出理由。大家可以看首先機器是不是正常，這就是機器硬件級別的檢測，硬件沒有問題的話會有一個IO診斷，這邊會給出來說分區(qū)上的文件，次數(shù)是怎么樣的，是在讀。
還有網(wǎng)絡的診斷，針對網(wǎng)絡流量滿的情況下，哪個進程流量占了多少。這樣來解決用戶經(jīng)常問的基于作業(yè)運行情況的答疑。
下面介紹兩個異常檢測的例子，可能這兩天下來大家在很多場聽了很多，最多的就是基于時序的，所以我們講點不一樣的。
除了時序的還有基于聚類的，適用的場景是有很多大量同質(zhì)的主機，上面跑的任務都是類似的，而且資源調(diào)度器也是比較高效的，能公平的去調(diào)度這些作業(yè)，理論上這些機器的負載基本上是均衡的，所以可以基于它的CPU、系統(tǒng)的復雜、網(wǎng)絡等去做聚類，看看有沒有某些機器和別人表現(xiàn)不一樣，不一樣的話這些機器肯定是有它的各種原因。
根據(jù)這個聚類拿到異常組之后再去看它們有沒有什么共性，比如說是不是同一天開機的，上面是不是運行同一個作業(yè)等等。DBScan的好處是不拘泥于聚類組的數(shù)量，如果覺得只要能夠發(fā)現(xiàn)異常的問題就調(diào)的粗獷一點。
第二個是基于日志的日常檢測，這個大家講的可能會稍微少一點。我們更多的是把日志進行模式的提取，模式提取的算法有很多，網(wǎng)上也有很多查到的，比如說文本之間的相似度，就有很多的方式去找日志之間的相似度或者說它們是不是統(tǒng)一類的，有了這個數(shù)據(jù)之后就可以切面，我們做的時候是把日志的異常檢測變成指標類的。
這是日志異常檢測的實際例子，大家可以發(fā)現(xiàn)說忽然某一類模式的日志變多了，可以看到某個時間段內(nèi)出現(xiàn)的日志數(shù)量達到這么多，也就說大量的作業(yè)在某一個時間點出現(xiàn)同類型的日志，很有可能是平臺的問題，因為對于我們做平臺來講，更關注的是平臺為主的問題，我們可以給它提供這樣的渠道去提醒它。
這時候我們可能會懷疑是不是平臺有問題了，那可以在日志詳情里去看到底是哪類日志，這個例子其實講的是實時計算的上游那里出了問題。
DataOps 還有一個很大的分支就是運籌優(yōu)化，可能運維的“運”本來就包含了運籌的意思。運籌優(yōu)化的例子比較多，多個集群之間容量的均衡，配置的優(yōu)化等等。
下面舉一個例子，關于同步任務的優(yōu)化，這個例子比較簡單，對大家的理解方面、啟發(fā)方面好理解一點。同步任務就是說在ETL離線處理的第一步，從不同的第一里面把數(shù)據(jù)統(tǒng)一過來。
我們可以看到這些同步任務A和B是阿里不同的兩個BU，寫的同步作業(yè)的速度完全不一樣，ABU平均速度能夠達到4兆多，而BBU平均只有1.8幾兆，在每個不同的速度區(qū)間做一個分布也是完全不一樣的，原因是因為ABU的人比較有經(jīng)驗一點或者他們做的時間更久一點。
我們能做的事情是怎么樣把ABU的經(jīng)驗快速地復制到BBU，而不需要BBU的開發(fā)者再去學一遍，這個場景在大家的工作中也應該是能很容易找到落地點。
我們可以把同步任務的屬性拿出來，把它們分為固定屬性和可配屬性，所謂固定屬性是指本身作業(yè)固有的屬性，對同步任務來講有源類型，包括它的宿類型，還有一些在運行中可以配置的，比如說并發(fā)性、jvm參數(shù)是多少等。
固定屬性K-means聚類，去找到我們這么多的同步作業(yè)到底有多少種類型，找到一個分類，盡可能類型差不多的分在同一類型里面。
完成這個以后再在同一類里面去找到一個比如說單資源情景下的同步速度最高的作業(yè)，作為這一類作業(yè)的最佳實例，把這個最佳實例的配置應用到同類型里的其他作業(yè)，這個問題就解決了，其實是一個自動的聚類、分類，然后再在里面找一個最佳實例。
這是這個配置解決的最后效果，基本上平均速度有7倍的提升，收益還是蠻大的，不用一個個人再去調(diào)作業(yè)做優(yōu)化。
AIOps 我個人認為離它還是蠻遠的，但并不是遙不可及，AIOps 只要滿足它的一個模式的定義，就可以稱之為 AIOps，甚至有一些原來在自動化運維場景就已經(jīng)實現(xiàn)的了，這是我個人一些淺漏的理解。我的概念里只要是說它能中間利用數(shù)據(jù)、算碼模型做一些決策，且這些決策能夠自動的去應用到線長，形成這樣一個閉環(huán)，不需要人干預的，我認為這個場景就可以稱之為AIOps。
最頭疼的是半夜收到告警、周末收到告警、看電影時收到告警，這里面把它用AI Ops的框架再去梳理一下，提升它的效果。
主要是三大部分：
第一部分是感知，怎么去感知到異常事件的發(fā)生，如果做監(jiān)控自愈的話來源就比較簡單
第二部分是決策，做實時的決策處理。
第三部分是自愈，同時還要再去關注一下是否都解決了
作業(yè)平臺推給流程平臺，流程平臺中會就人介入做一個審核，可能有些重要的機器是不能重啟的，或者在某些告警情況下不適合做下線，這可以分階段去做。
整個計算平臺物理機這塊非常多，如果人去做硬件故障發(fā)現(xiàn)、保修，至少要投一個人全職在這件事情上。在這些服務器上會裝上一個系統(tǒng)，它會去采集硬件故障判斷相關的例子，采集完以后通過SLS數(shù)據(jù)通道，再通過流計算做分析聚合，最后放到OLAP里面，結(jié)合它原有的模型去做一個判斷，說這臺機器是不是有問題了，同時也會受業(yè)務安全模型的制約。
最后它會產(chǎn)生動作，會把這個動作扔到事件中心，就產(chǎn)生下線或者重啟等。也正是基于這樣一套系統(tǒng)可以幫我們把這方面的人力省下來，一年處理20萬次自愈事件，服務器可用率99%以上。
怎么給集群的作業(yè)劃分quota組最合理？首先要建立資源劃分的滿意度模型，因為你不可能讓所謂的AI模塊自己去判斷說這用戶用的爽不爽，這不可能的。
那資源滿意度模型可以根據(jù)自己的業(yè)務特點去建，一套綜合評價體系主要包含用戶資源搶占、等待分配時間、資源滿足率等，用Tdata時序異常檢測模型跟蹤用戶滿意度變化情況。有滿意度模型且能夠發(fā)現(xiàn)異常以后，那就去做智能的資源調(diào)配的事情，選一個模型對未來一周的用戶組的資源做一個預測，當然這方面的模型比較多我也不詳細地展開了。
最后基于每個配額組未來一周的資源消耗預測值結(jié)合該配額組的歷史用戶滿意度數(shù)據(jù)和所在用戶等級的服務SLA，根據(jù)這三項結(jié)合，最后給出這個資源組配置的推薦值。
當然這個值過去以后還會形成一個閉環(huán)，因為用戶滿意度的異常檢測是實時一直在線上跑的，如果忽然發(fā)現(xiàn)某個用戶不滿意的話會及時調(diào)整。
說明：以上內(nèi)容為 GOPS 全球運維大會 2018 · 上海站演講。
2018 年即將遠去
2019 年即將到來~
新的一年
運維行業(yè)怎么能不搞事情呢？
GOPS 2019 · 深圳站
早鳥票限時搶購
