王華，2014年加入阿里，一直做大數據運維相關的事情，也在做運維平臺研發的事情。第一年做離線的運維，后來從2015年開始做流計算的運維，之前負責阿里云的流計算。

2017年開始負責 Flink 的運維，以及Flink運維管控建設。

一、阿里 Flink 集群運維挑戰

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

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

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

之后經常在內網上PK，這幾套引擎誰最牛逼。2017年左右 Flink 以低延時、高吞吐、一致性，從幾個流計算引擎里面脫穎而出，后來整個集團做了技術統一，其他引擎全部拋棄，用Flink來做，Flink是阿里統一的流計算引擎。有了這樣的基礎之后，業務不斷發展，所有的流計算引擎往 Flink 上遷移。

另外一個方面，我們對于數據的處理要求越來越高，現在盡可能往實時化，現在越來越多的Flink本身已經有很多批計算的邏輯和機器學習，綜合這三點，導致阿里的 Flink 集群發展非常大。

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

現在我們的集群規模有幾萬個計算節點，大部分還是傳統的物理機，還有大部分是 ECS和容器；有幾百個集群，Flink 一部分用戶是阿里內部的，集群最大的規模可能是五六千臺，但是對外阿里云上售賣的，一個用戶可以開通一個集群。

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

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

現在僅阿里內部的 Flink，每秒處理幾十億條數據，這個數據量非常龐大，一條數據1K，你想想這個數據有多大。規模這么大，運維上碰到了很多問題，挑戰分為下面幾部分：

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

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

我們不僅僅做 Flink運維，這么大的工作量，其實只有幾個人負責整個運維，而且業務規模基本上每年都在翻番，它是一頭奔跑著的大象。

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

二、阿里 Flink 運維管控

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

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

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

講一下整體架構，最下面就是數據層，就在做一件事情，做Flink實時運維元倉的建設，一部分是業務數據，Flink本身的數據，一部分是實時數據，一部分是圍表數據，還有一些公共數據，這層主要解決的是保證實時和準確。

數據層之上就是服務層，基礎運維服務，還有一塊是數據分析服務，大家經常聽到的地產檢測，日志聚類，還有最左邊的業務服務、診斷服務、資源服務。

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

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

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

這是診斷分析，下面會講，我們的目標就是說一個站點要能做到所有的集群的運維，這個其實是很有挑戰的，因為中間涉及到很多部署架構的異構，還有網絡域，阿里的網絡域比較復雜，有很大挑戰在后面。

三、Flink 運維解決方案

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

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

幾萬臺機器，一天按照一臺機器，半個小時升一下內核，升到猴年馬月，得升半年，這時又出現了業務可能要一批一批去升，這個更復雜了，如果說純計算節點，沒狀態，很簡單。你不能說三臺機器同時分布在不同機架上，數據就丟了，這是大數據分布系統的一個復雜點。

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

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

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

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

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

最終能夠做到用戶根據自己的業務屬性做批量自動化升級，我們會把升級的閉環全部打通，升級失敗了自動回滾，升級成功自動通知等等，這里面有比較多的技術細節。

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

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

但是其實我們去年做了一個事情，其實故障本身也是有一個完整的生命周期的，首先就是服務正常，目標就是來減少故障，每個系統都有自己的故障定義，開始有一些異常隱患，比如說集群有一個五千臺機器，有幾個作業很惡劣，現場慢慢在泄露，很多臺機器已經慢慢在漲了，但是沒有問題。

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

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

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

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

我們通過一條實時鏈路，因為異常事件如果進入一個系統里面，處理慢的話就會導致故障，進入下面的治愈系統里面，大家自己開發的，感知決策執行，我感知這個事件，然后做決策，最后執行，運維系統不斷把我們的經驗沉淀。

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

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

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

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

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

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

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

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

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

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

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

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

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

這就是我們可能大數據運維同學的一個比較強的感覺，我們很擅長利用自己運維的大數據系統，來解決我們自己在大數據運維當中碰到的各種問題。

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

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

邏輯是從整個淘寶支付寶那邊的交易數據庫同步到數據通道，起了一個Flink作業，這個作業不斷消費所有的交易日志，寫到另外一個存儲系統里面，前端來輪巡這個存儲系統，這個數據量很大，可以做到一整天下來，Flink的作業延時在秒級。

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

這是一個很復雜的場景，我們怎么把集群資源如何合理的高效的分配給用戶，我們希望做到最好的狀態是用戶不用關心資源，如果資源池無限大，哪都有資源，根本不用關心這個事情。

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

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

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

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

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

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

基本上資源跑不起來，都可以告訴你，因為資源跑不起來，應該怎么做怎么做擴容去哪做擴容，一站式的，還有就是昨天晚上有一臺機器下線了，還有就是可能告訴你哪個節點要調什么內存。

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

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

大數據運維難在哪，阿里的大數據形態和其他的很不一樣，我們很早就實現了，像技術統一是很早的，Flink 流計算大家統一的引擎，離線計算可能是 MaxCompute，集群的管理用天基。近幾年沒有出現重復的，這一方面促進了整個阿里的底層大數據基礎平臺業務發展非常快，機器規模發展也很多，更多的復雜性導致，運維的挑戰也越來越多。

以上為阿里大數據運維技術專家王華在 GOPS 2019 · 上海站的分享。