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

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

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

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

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

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

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

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

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

現(xiàn)在我們的集群規(guī)模有幾萬(wàn)個(gè)計(jì)算節(jié)點(diǎn)，大部分還是傳統(tǒng)的物理機(jī)，還有大部分是 ECS和容器；有幾百個(gè)集群，F(xiàn)link 一部分用戶是阿里內(nèi)部的，集群最大的規(guī)?？赡苁俏辶_(tái)，但是對(duì)外阿里云上售賣的，一個(gè)用戶可以開(kāi)通一個(gè)集群。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

等到漲到一定的值，比如一臺(tái)機(jī)器的內(nèi)核線到十萬(wàn)，可能開(kāi)始load很高很高，大量的時(shí)候CPU都消耗在內(nèi)核線程切換上。如果再不處理，因?yàn)榉植际较到y(tǒng)，其他的作業(yè)，運(yùn)行的所有的作業(yè)會(huì)有心跳嗎？心跳超時(shí)，就有故障了。

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

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

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

我們通過(guò)一條實(shí)時(shí)鏈路，因?yàn)楫惓Ｊ录绻M(jìn)入一個(gè)系統(tǒng)里面，處理慢的話就會(huì)導(dǎo)致故障，進(jìn)入下面的治愈系統(tǒng)里面，大家自己開(kāi)發(fā)的，感知決策執(zhí)行，我感知這個(gè)事件，然后做決策，最后執(zhí)行，運(yùn)維系統(tǒng)不斷把我們的經(jīng)驗(yàn)沉淀。

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

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

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

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

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

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

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

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

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

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

再來(lái)說(shuō)和Flink有點(diǎn)關(guān)系的，大促的壓測(cè)怎么做，用戶有很多作業(yè)在線上跑，我們要做一件事情，把用戶的作業(yè)，因?yàn)槊總€(gè)作業(yè)的計(jì)算邏輯代碼都不一樣，我們需要把用戶計(jì)算邏輯考一份到備鏈路，看能不能達(dá)到要求。

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

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

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

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

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

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

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

這是一個(gè)很復(fù)雜的場(chǎng)景，我們?cè)趺窗鸭嘿Y源如何合理的高效的分配給用戶，我們希望做到最好的狀態(tài)是用戶不用關(guān)心資源，如果資源池?zé)o限大，哪都有資源，根本不用關(guān)心這個(gè)事情。

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

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

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

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

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

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

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

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

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

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

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