王華，2014年加入阿里，一直做大數(shù)據(jù)運(yùn)維相關(guān)的事情，也在做運(yùn)維平臺研發(fā)的事情。第一年做離線的運(yùn)維，后來從2015年開始做流計算的運(yùn)維，之前負(fù)責(zé)阿里云的流計算。

2017年開始負(fù)責(zé) Flink 的運(yùn)維，以及Flink運(yùn)維管控建設(shè)。

一、阿里 Flink 集群運(yùn)維挑戰(zhàn)

首先說一下流計算，批計算就是數(shù)據(jù)集是有限的，每次的計算都可以拿到一樣的結(jié)果，在批計算之上，如有很多個批，這個數(shù)據(jù)永久不斷過來的時候就變成了流。

流計算是批計算以上的概念，很多用流計算的，比如說每天把所有的前端日志導(dǎo)到流上算一天，但是有了流計算之后，一條路過來就可以實時算出網(wǎng)站的UV。

說一下阿里的流計算引擎，2015年在 Galaxy 自研的流計算，2014年的時候阿里就有了流計算，那個時候還有JStorm和Flink，分別分布在搜索和中間件其他的部門。

之后經(jīng)常在內(nèi)網(wǎng)上PK，這幾套引擎誰最牛逼。2017年左右 Flink 以低延時、高吞吐、一致性，從幾個流計算引擎里面脫穎而出，后來整個集團(tuán)做了技術(shù)統(tǒng)一，其他引擎全部拋棄，用Flink來做，F(xiàn)link是阿里統(tǒng)一的流計算引擎。有了這樣的基礎(chǔ)之后，業(yè)務(wù)不斷發(fā)展，所有的流計算引擎往 Flink 上遷移。

另外一個方面，我們對于數(shù)據(jù)的處理要求越來越高，現(xiàn)在盡可能往實時化，現(xiàn)在越來越多的Flink本身已經(jīng)有很多批計算的邏輯和機(jī)器學(xué)習(xí)，綜合這三點，導(dǎo)致阿里的 Flink 集群發(fā)展非常大。

據(jù)我了解，像谷歌、Facebook 沒有用。只要用 Flink，阿里的 Flink 集群是全世界最大的。

現(xiàn)在我們的集群規(guī)模有幾萬個計算節(jié)點，大部分還是傳統(tǒng)的物理機(jī)，還有大部分是 ECS和容器；有幾百個集群，F(xiàn)link 一部分用戶是阿里內(nèi)部的，集群最大的規(guī)模可能是五六千臺，但是對外阿里云上售賣的，一個用戶可以開通一個集群。

所以有上百個集群，一個集群可以有成百上千臺機(jī)器，整個系統(tǒng)非常復(fù)雜，因為 Flink是一個計算的，不負(fù)責(zé)數(shù)據(jù)的源和目標(biāo)存儲，所以要從上游讀數(shù)據(jù)，然后寫到下游的數(shù)據(jù)庫或者其他系統(tǒng)里面去，大概幾十個上下游，而且整個 Flink 的底座也很多。

最早有基于 Hadoop 的底座和阿里飛天系的底座，還有現(xiàn)在基于云原生 Kubernetes 的底座。另外，出口非常多，基本上分布在全世界各地都是可以看到 Flink 的應(yīng)用。

現(xiàn)在僅阿里內(nèi)部的 Flink，每秒處理幾十億條數(shù)據(jù)，這個數(shù)據(jù)量非常龐大，一條數(shù)據(jù)1K，你想想這個數(shù)據(jù)有多大。規(guī)模這么大，運(yùn)維上碰到了很多問題，挑戰(zhàn)分為下面幾部分：

第一部分是故障，特別實時計算系統(tǒng)，都在 Flink 上運(yùn)行，所以我們對故障的要求是比較苛刻的；第二部分是大促穩(wěn)定性怎么保障，大量的日常運(yùn)維操作怎么保持一致性；

再就是成本，包括硬件成本怎樣管理，用戶資源怎樣合理分配和合理均衡，怎么樣降低運(yùn)維人力成本。

我們不僅僅做 Flink運(yùn)維，這么大的工作量，其實只有幾個人負(fù)責(zé)整個運(yùn)維，而且業(yè)務(wù)規(guī)?；旧厦磕甓荚诜且活^奔跑著的大象。

首先運(yùn)維靠人堆是絕對不可能的，這也是大數(shù)據(jù)運(yùn)維和其他的運(yùn)維不一樣的點，靠人堆絕對不可能贏，我們要以技術(shù)為基礎(chǔ)，所有的運(yùn)維的出發(fā)點，要以技術(shù)為基礎(chǔ)，我們做了一個 Flink 運(yùn)維管控，最上面是Flink運(yùn)維管控上承載著很多 Flink 的技術(shù)解決方案，我把兩個“技術(shù)”都標(biāo)紅，我們在任何時候都不要忘記我們要用技術(shù)去解決這些問題。

二、阿里 Flink 運(yùn)維管控

2015年不叫Flink運(yùn)維管控，叫做流計算運(yùn)維平臺，17年的時候把這個東西做的更大一點。左邊這個圖，我們運(yùn)維的是集群，集群就是一堆 IDC 資源的整合：網(wǎng)絡(luò)、機(jī)器、內(nèi)核。集群之上部署了軟件，分布系統(tǒng)的軟件和 Flink 軟件，軟件上跑的業(yè)務(wù)。

運(yùn)維主要是面向集群業(yè)務(wù)和軟件的。用戶分為幾塊，一開始的用戶是我們自己平臺的SRE，運(yùn)維和運(yùn)維研發(fā)（Flink的開發(fā)）、平臺的業(yè)務(wù)方，還有很多駐場外包也在用，整個權(quán)限的設(shè)計圍繞著四大類用戶。它提供了很多功能，整個 Flink 是機(jī)器-集群-服務(wù)-業(yè)務(wù)的方式來運(yùn)作的。所以，帶來了各種維度的產(chǎn)品化運(yùn)維，比如從一個管控上面一鍵發(fā)布，停止服務(wù)，還提供實時秒級監(jiān)控報表，里面有一套監(jiān)控系統(tǒng)。

整個 Flink 管控上做了資源生命周期管理，不僅僅是硬件的，還有一些數(shù)據(jù)化運(yùn)維和越位增值公司，現(xiàn)在的智能診斷，還有故障自愈。

講一下整體架構(gòu)，最下面就是數(shù)據(jù)層，就在做一件事情，做Flink實時運(yùn)維元倉的建設(shè)，一部分是業(yè)務(wù)數(shù)據(jù)，F(xiàn)link本身的數(shù)據(jù)，一部分是實時數(shù)據(jù)，一部分是圍表數(shù)據(jù)，還有一些公共數(shù)據(jù)，這層主要解決的是保證實時和準(zhǔn)確。

數(shù)據(jù)層之上就是服務(wù)層，基礎(chǔ)運(yùn)維服務(wù)，還有一塊是數(shù)據(jù)分析服務(wù)，大家經(jīng)常聽到的地產(chǎn)檢測，日志聚類，還有最左邊的業(yè)務(wù)服務(wù)、診斷服務(wù)、資源服務(wù)。

最上面是功能層，也很清晰，就是先業(yè)務(wù)，用戶有自己的業(yè)務(wù)中心，圍繞著穩(wěn)定、成本、效率三大塊做的，首先要說穩(wěn)定性，我們怎么做，我們圍繞著軟件的發(fā)布，整個生命周期來講，每一環(huán)是怎樣解決的，第二塊就是成本，資源的生命周期是怎樣解決的，再就是日常運(yùn)維效率怎么解決的。

這是一個Flink運(yùn)維管控功能的布局，其實這里功能很多，光菜單布局就有很多版，后來我們找到了一個清晰的思路，就是業(yè)務(wù)有用戶、作業(yè)、監(jiān)控等等。

接下來是運(yùn)維，運(yùn)維就是穩(wěn)定，面向運(yùn)維的實體有集群、機(jī)器、業(yè)務(wù)、服務(wù)，還有就是運(yùn)營，KPI的衡量；分析就是提升效率的，面向用戶的業(yè)務(wù)有實時所有的作業(yè)，隊列、預(yù)算等等。這是運(yùn)維，面向管控的，有幾個運(yùn)維，每個點進(jìn)去可以管理一個集群，也可以管理幾百個集群。

這是診斷分析，下面會講，我們的目標(biāo)就是說一個站點要能做到所有的集群的運(yùn)維，這個其實是很有挑戰(zhàn)的，因為中間涉及到很多部署架構(gòu)的異構(gòu)，還有網(wǎng)絡(luò)域，阿里的網(wǎng)絡(luò)域比較復(fù)雜，有很大挑戰(zhàn)在后面。

三、Flink 運(yùn)維解決方案

先說發(fā)布變更，我前幾年 GOPS 大家都在談自動化發(fā)布變更，這兩天聽下來，沒有人聊發(fā)動變更了，說明已經(jīng)做的很牛逼了，你發(fā)現(xiàn)阿里前兩位同學(xué)都講的發(fā)布變更，其實發(fā)布變更在阿里還是挺難的，為什么？

首先阿里的場景很復(fù)雜，那個同學(xué)提了，我們幾萬臺機(jī)器的內(nèi)核，怎么從3.x升到4.x，天基可以把機(jī)器關(guān)機(jī)升內(nèi)核然后啟動，但是在升級之前要把業(yè)務(wù)下掉，業(yè)務(wù)上面布了十個軟件，哪個軟件提供了一個接口，告訴他十個軟件已經(jīng)全下完了，這還不夠。

幾萬臺機(jī)器，一天按照一臺機(jī)器，半個小時升一下內(nèi)核，升到猴年馬月，得升半年，這時又出現(xiàn)了業(yè)務(wù)可能要一批一批去升，這個更復(fù)雜了，如果說純計算節(jié)點，沒狀態(tài)，很簡單。你不能說三臺機(jī)器同時分布在不同機(jī)架上，數(shù)據(jù)就丟了，這是大數(shù)據(jù)分布系統(tǒng)的一個復(fù)雜點。

另外一個就是流程很復(fù)雜，復(fù)雜在哪？從一個軟件包發(fā)出來，有很多模塊，然后到測試環(huán)境，到預(yù)發(fā)布再生產(chǎn)環(huán)境，這個流程有層層審批機(jī)制，可能會有熔斷、回滾、驗證，這個流程非常復(fù)雜。

最下面是發(fā)布一個技術(shù)服務(wù)，下面也會調(diào)用一些天基等等其他能力，范圍是發(fā)布流程，最后是發(fā)布場景，用戶和平臺側(cè)的發(fā)布，我們把很多場景工單化，預(yù)先定義好所有的發(fā)布流程，只要提一個單子，所有發(fā)布的計劃都編排好了。

這周發(fā)這兩個集群，所有的發(fā)布計劃都已經(jīng)編排好了，然后發(fā)布之后進(jìn)行執(zhí)行，能做到分鐘級別的提單，但是最終也是面向中臺的，可能會利用天基的能力，做到全服務(wù)集群的自動化，保持一致。

剛才說了軟件發(fā)布，這里講一個Flink的，軟件包發(fā)到集群上面后，怎么樣讓用戶用起來，用戶的作業(yè)是長任務(wù)，是一直跑在線上的，除非要停下來，用新的版本把資源全部傳上去，才能升級到新的，這是流計算本身的原理。

數(shù)據(jù)是一個時間軸，在10點鐘停了，怎么保證在11點起來？怎么樣保證自對回追回來，有一個state，把所有的計算中心結(jié)果都寫在本地存儲上面，不同版本之間有不同的兼容情況，而且整個升級非常復(fù)雜，幾萬個作業(yè)升級也是非常難的。在業(yè)務(wù)的發(fā)布上，天基解決不了我們的問題。我們有自己的一套方案，大家對這塊有很多技術(shù)細(xì)節(jié)，大家對Flink不了解，我就暫時不說了。

最終能夠做到用戶根據(jù)自己的業(yè)務(wù)屬性做批量自動化升級，我們會把升級的閉環(huán)全部打通，升級失敗了自動回滾，升級成功自動通知等等，這里面有比較多的技術(shù)細(xì)節(jié)。

軟件上線以后，用戶用起來了，接下來怎么樣保證用戶平穩(wěn)運(yùn)行，其實就是故障。我覺得GOPS大家把故障和異常，通過異常，平時有一個報警也算異常，但是我們最關(guān)心的如果按報警來做，報警太多了，我們對關(guān)心的是故障，傳統(tǒng)的故障。

大家都知道，感覺故障這個東西不期而至，沒有辦法避免這個故障什么時候來，每次來你好像都很被動，和小孩一樣，什么時候哭不知道，來臨的時候各種問題，老板在問你，出什么問題了，業(yè)務(wù)各種反饋，你就手忙腳亂的。結(jié)束之后很累，可能想報警沒覆蓋到，加一些報警吧，或者說流程有問題，改善一下流程。故障就是這樣，很難。

但是其實我們?nèi)ツ曜隽艘粋€事情，其實故障本身也是有一個完整的生命周期的，首先就是服務(wù)正常，目標(biāo)就是來減少故障，每個系統(tǒng)都有自己的故障定義，開始有一些異常隱患，比如說集群有一個五千臺機(jī)器，有幾個作業(yè)很惡劣，現(xiàn)場慢慢在泄露，很多臺機(jī)器已經(jīng)慢慢在漲了，但是沒有問題。

等到漲到一定的值，比如一臺機(jī)器的內(nèi)核線到十萬，可能開始load很高很高，大量的時候CPU都消耗在內(nèi)核線程切換上。如果再不處理，因為分布式系統(tǒng)，其他的作業(yè)，運(yùn)行的所有的作業(yè)會有心跳嗎？心跳超時，就有故障了。

故障發(fā)生開始查，查完之后恢復(fù)故障，又恢復(fù)到正常，又開始不斷循環(huán)，這是一個完整的生命周期，其實把這些故障拆借一下，分成兩部分，一部分是故障的隱患，我們沒有故障，但是系統(tǒng)已經(jīng)有異常了，這個時候不用背什么責(zé)任，這個時候我們要做到主動發(fā)現(xiàn)和治愈。

第二點發(fā)生了怎么，發(fā)生沒轍，只能快速發(fā)現(xiàn)，迅速恢復(fù)。故障其實是有生命周期的，正確理解生命周期之后，可以通過一些技術(shù)手段系統(tǒng)解決故障，并且能夠做到低成本維持住。

故障隱患我們怎么發(fā)現(xiàn)和治愈，分兩部分，有潛伏期和暴露的。潛伏期就是不知道，暴露就是電話報警，會分析各種數(shù)據(jù)，把數(shù)據(jù)拿過來之后，第二部分就是分析，可以用監(jiān)控，傳統(tǒng)的閾值監(jiān)控也可以，對于有一個異常事件，這是一個潛伏期的事件，主動發(fā)現(xiàn)的異常事件。

我們通過一條實時鏈路，因為異常事件如果進(jìn)入一個系統(tǒng)里面，處理慢的話就會導(dǎo)致故障，進(jìn)入下面的治愈系統(tǒng)里面，大家自己開發(fā)的，感知決策執(zhí)行，我感知這個事件，然后做決策，最后執(zhí)行，運(yùn)維系統(tǒng)不斷把我們的經(jīng)驗沉淀。

舉個例子，潛伏期有哪些自愈場景，有些作業(yè)磁盤寫的很猛，還有一些作業(yè)掛了，一個作業(yè)掛了沒什么問題，已暴露自愈系統(tǒng)，報警，異常事件，進(jìn)行感知，我們找到一百臺機(jī)器，然后進(jìn)行作業(yè)，解決問題之后通知用戶已經(jīng)恢復(fù)。

我們動作這套系統(tǒng)和理論，這是真實的場景，之前電話告警每周有28個到29個左右，現(xiàn)在我們做到了個位數(shù)，每周只有兩三個電話。

故障隱患階段，我們可能盡力了，但是真的出故障了，到了第二個階段。真的故障了，故障怎么發(fā)現(xiàn)和恢復(fù)，GOPS很多場都說了，有一個異常，異常檢測，根因分析，然后反饋。

首先我們有一個故障定義，因為系統(tǒng)很大，需要找出一到兩個指標(biāo)，能說清楚，這個指標(biāo)有問題，我的服務(wù)就有問題。像淘寶天貓，下單是一個KPI，支付是一個KPI，跳轉(zhuǎn)又是一個KPI，前端訪問不了沒有影響，越往下的指標(biāo)沒有意義的。

整個集群的水位突然掉下來，有可能是軟件升級，也有可能是一部分用戶停了一部分作業(yè)，自己人為操作的，不算故障。越往下的指標(biāo)越?jīng)]有意義，但是流量如果跌下來了，很有可能是故障，但是也不一定，但是起碼誰位越往上指標(biāo)肯定更有意義，噪音越來越小。

Flink拿每個運(yùn)行狀態(tài)，把這個作業(yè)狀態(tài)做成很多條曲線，反映服務(wù)的情況，最終這個指標(biāo)的黃金指標(biāo)，要衡量一個服務(wù)好不好的最后一個黃金指標(biāo)肯定很簡單，不可能有很多很多條曲線，那肯定是不可能的，如果有那肯定就是黃金指標(biāo)，提取沒有對，基于這個黃金指標(biāo)進(jìn)行檢測。

第二個是多指標(biāo)關(guān)聯(lián)，我們要關(guān)聯(lián)異常曲線上去，一個是斷崖式的，一個是突增的，接下來是故障定位，故障定位一定要說清楚，現(xiàn)在到底出什么問題了；我要把我的故障量化出來，我哪里出了問題，大概出了什么問題，我現(xiàn)在到底受了多少損失，我們一定要說清楚，哪個服務(wù)，哪個地方哪個集群有問題，大概多少個作業(yè)受影響了，這些東西一定要說清楚。

再就是根因定位，其實這塊很難，我們沒有用很多亂七八糟的所發(fā)，我們就是根據(jù)自己的經(jīng)驗把那些經(jīng)驗代碼一個一個寫下來，我知道故障發(fā)生的根因，我就開始自愈，這也沒有那么簡單，有些簡單的場景可以做自動化恢復(fù)的，比如說哪有問題一把切，可以從第三個服務(wù)診斷，你們看到了這里可能不是很清晰，是一個出故障的時候我們釘釘有推送，有什么問題出來了。

現(xiàn)在Flink服務(wù)是不是正常的？這是一個比較難的問題，因為整個系統(tǒng)非常復(fù)雜，很龐大，不是一條鏈路，甚至不是一個鏈路下來的，可能會有異步的，也沒有一個ID，不同的運(yùn)維時期里面對象都是不一樣的，而且故障排查率低的話還有可能會造成故障。

我們怎么診斷這個事情，一個系統(tǒng)，一個集群有很多模塊存儲調(diào)度，管控，每個模塊也根據(jù)剛才的規(guī)則嘗試提取一到兩個黃金指標(biāo)，衡量模塊好不好，基于這個黃金指標(biāo)做模塊診斷，然后再說集群好不好，集群診斷做完之后，就可以做服務(wù)診斷，這是夸張一點，分鐘界別發(fā)現(xiàn)故障，根因和恢復(fù)建議我們做不到，這個還不行。

再來說和Flink有點關(guān)系的，大促的壓測怎么做，用戶有很多作業(yè)在線上跑，我們要做一件事情，把用戶的作業(yè)，因為每個作業(yè)的計算邏輯代碼都不一樣，我們需要把用戶計算邏輯考一份到備鏈路，看能不能達(dá)到要求。

如果能夠達(dá)到的，相當(dāng)于雙十一可以解決問題，克隆一個影子作業(yè)，替換了上下游，就開始不斷加壓力，做各種實時監(jiān)控性能報表，一個作業(yè)只要在平臺上點一下，就可以自動完成這些事情。

再說一個大家直觀感受的東西，剛才說了整個服務(wù)本身已經(jīng)每秒在處理幾十億表數(shù)據(jù)了，按照正常雙十一的量，肯定是平時的幾倍，你要造出來的量也應(yīng)該是幾十億的幾倍不然邏輯說不過去，這是一個非常難的事情，給你一百個機(jī)器人也解決不了，更不用說小腳本，根本不可能。

這就是我們可能大數(shù)據(jù)運(yùn)維同學(xué)的一個比較強(qiáng)的感覺，我們很擅長利用自己運(yùn)維的大數(shù)據(jù)系統(tǒng)，來解決我們自己在大數(shù)據(jù)運(yùn)維當(dāng)中碰到的各種問題。

我們想了一個很巧妙的方案，我們用 Flink 自己的能力，這些 Flink 可以很巧妙解決兩個問題，壓測過程當(dāng)中壓力大的問題，充分利用 Flink 的分布式計算很牛逼的能力，解決了壓力瓶頸。

壓力不能一上來就把集群打掛了，一定得循序漸進(jìn)。如何精準(zhǔn)控制，我們通過不同的Flink作業(yè)數(shù)量，通過這種方式，很巧妙的解決了這個問題。這是Flink最重要的業(yè)務(wù)，GMV大屏成交額，每天可能看到PR公關(guān)上一分鐘成交多少億，十分鐘成交多少億，那個任務(wù)就是在Flink集群上的。

邏輯是從整個淘寶支付寶那邊的交易數(shù)據(jù)庫同步到數(shù)據(jù)通道，起了一個Flink作業(yè)，這個作業(yè)不斷消費(fèi)所有的交易日志，寫到另外一個存儲系統(tǒng)里面，前端來輪巡這個存儲系統(tǒng)，這個數(shù)據(jù)量很大，可以做到一整天下來，F(xiàn)link的作業(yè)延時在秒級。

再來說一下用戶資源，只有我們阿里人可以體會用戶資源，說白了你有五萬臺機(jī)器，可能有五百萬個CPU，怎么把資源合理分配給現(xiàn)場用戶，有些用戶說我的業(yè)務(wù)很重要。

這是一個很復(fù)雜的場景，我們怎么把集群資源如何合理的高效的分配給用戶，我們希望做到最好的狀態(tài)是用戶不用關(guān)心資源，如果資源池?zé)o限大，哪都有資源，根本不用關(guān)心這個事情。

其實用戶資源也有一個生命周期，從開始的提預(yù)算，再到線上資源擴(kuò)容，再到上線之后有一些用戶濫用，拿很多資源不用，我們怎么做優(yōu)化，還有就是怎么做均衡，均衡之后怎么回收資源，怎么樣計量計費(fèi)，整個生命周期通過預(yù)算服務(wù)、資源服務(wù)，整個管控做起來。

第二塊硬件資源怎么管理，如果按照一天一萬臺機(jī)器只掛一臺，我們每天都要掛幾臺機(jī)器，萬分之一的宕機(jī)率，一天還要維護(hù)幾臺機(jī)器，一周就是幾十臺，怎么做自動化的維修，如果這個效率過程當(dāng)中很低的話就會導(dǎo)致下面故障的機(jī)器越來越多，過一年幾千臺機(jī)器，怎么做高效的資源上下線。

機(jī)器上線、擴(kuò)容、硬件維修、縮容、過保，機(jī)器的生命周期我們都管起來，這可能和天基講的，我們會用天基很多能力，但是這里面有很多業(yè)務(wù)邏輯，我們從業(yè)務(wù)視角來看機(jī)器生命周期，我們希望做到自己的平臺上選擇一堆機(jī)器下線可以自動下線，從而降低成本。

再說一下Flink作業(yè)是否正常，我們做了一整套作業(yè)診斷，比較復(fù)雜，整體思路下面有很多事件、日志、接口、指標(biāo)，下面有一個診斷服務(wù)，主要做幾件事情，運(yùn)行狀態(tài)，哪個狀態(tài)到底什么階段，日志和運(yùn)行指標(biāo)，下面有很多入口。

第一部分就是作業(yè)狀態(tài)，只要搞清楚Flink的狀態(tài)，每個狀態(tài)的原因是什么，第二塊就是日志聚類，我聽了幾場，把海量日志收集起來，把相同日志模式合起來，通過一些算法會寫到一個庫里面。

這個庫里面這個日志是屬于這個實體的，原因是什么，原因不知道，我們需要專家去標(biāo)注，標(biāo)注之后下一次有一個新的報錯進(jìn)來之后找到這個日志，原因是因為什么，就可以直接告訴他這個作業(yè)怎么處理，這是一個診斷思路，這是我們落地的結(jié)果。

基本上資源跑不起來，都可以告訴你，因為資源跑不起來，應(yīng)該怎么做怎么做擴(kuò)容去哪做擴(kuò)容，一站式的，還有就是昨天晚上有一臺機(jī)器下線了，還有就是可能告訴你哪個節(jié)點要調(diào)什么內(nèi)存。

除了作業(yè)診斷，思路都是一樣，就是把經(jīng)驗原理和數(shù)據(jù)通過一些技術(shù)實心來實現(xiàn)診斷，最終做到問題定位根因和恢復(fù)意見。我們不僅僅做到作業(yè)診斷，還做了機(jī)器診斷，一臺機(jī)器輸入進(jìn)來告訴你機(jī)器好不好。

最后講智能運(yùn)維機(jī)器人，這個很解問題，我們答疑量特別大，用戶會有各種各樣的問題，以前都是靠人。我們通過釘釘，運(yùn)維只需要把文檔、操作、流程，把知識圖譜構(gòu)建起來，結(jié)合釘釘做整體協(xié)同，很簡單讓用戶完成端到端的答疑。這里面有很多功能，就不一一細(xì)說了。

大數(shù)據(jù)運(yùn)維難在哪，阿里的大數(shù)據(jù)形態(tài)和其他的很不一樣，我們很早就實現(xiàn)了，像技術(shù)統(tǒng)一是很早的，F(xiàn)link 流計算大家統(tǒng)一的引擎，離線計算可能是 MaxCompute，集群的管理用天基。近幾年沒有出現(xiàn)重復(fù)的，這一方面促進(jìn)了整個阿里的底層大數(shù)據(jù)基礎(chǔ)平臺業(yè)務(wù)發(fā)展非常快，機(jī)器規(guī)模發(fā)展也很多，更多的復(fù)雜性導(dǎo)致，運(yùn)維的挑戰(zhàn)也越來越多。

以上為阿里大數(shù)據(jù)運(yùn)維技術(shù)專家王華在 GOPS 2019 · 上海站的分享。