應對雙11挑戰，阿裏巴巴智能化運維體係演進與建設

導讀：DevOps 的概念提出接近10年了，提升協作效率，降低開發成本，更穩健可持續的業務運營是DevOps的主旋律。根據2016年DevOps調查報告顯示，一個低效的IT組織跟一個高效的IT組織相比，差距可能是200倍，換句話說低效組織發布一個功能，高效組織可能已經發布了200個功能；故障恢複的效率差距可能是幾十倍，低效組織花費幾個小時恢複的故障，高效組織可能幾分鍾就搞定了。

在日益激烈的商業競爭環境下，這麼低效的IT組織注定在商業上也是要失敗的。因為現在是快魚吃慢魚的時代。去年Gartner又提出了AIOps的概念，就是用基於算法來提升運維效率，國內很多公司在各個運維的場景都有了不同程度的應用。

阿裏巴巴對DevOps和AIOps有自己的理解和實踐，外界也比較關注擁有眾多業務的龐大組織，是如何開展DevOps的？ 帶著這些問題，阿裏集團基礎架構事業群運維中台負責人如柏，在2017杭州雲棲大會企業高效研發實踐專場上，詳細介紹了阿裏運維體係的演進和在智能化運維方麵的工作，希望能給大家帶來一些啟發和借鑒。

毛茂德(花名：如柏)：阿裏集團基礎架構事業群運維中台負責人。主要負責 IDC 建設、網絡建設、基礎數據庫運維、大數據運維，研發協同等事項，並主導設計構建高可靠、高並發、大規模的基礎運維平台和應用運維平台。十餘年來堅持不懈的追求研發、測試、運維效率提升，推動DevOps實施落地。現在正致力於打造基於混合雲的應用運維無人值守解決方案，以及自動化、數據化、智能化應用運維解決方案。

阿裏巴巴是怎麼看運維的？

阿裏大致也是經曆了這麼幾個階段：從最開始的人肉運維， 到簡單的工具、自動化， 到係統化和平台的過程， 自動化到一定程度後，開始探索智能化，無人化運維這些領域， 並在阿裏的多個運維係統裏有所沉澱。

 

在這個演進過程中，我們始終秉承一種原則， 能用機器去做的就不要讓人去做，自動化一切可以自動化的。很多簡單重複的日常運維操作，開始由研發通過運維平台來完成。

阿裏巴巴運維能力分層圖

上圖是阿裏對運維領域的大致分層。每個層都會有不同平台/係統來承載，運維團隊整體上會幫助業務團隊搞定資源，實現高可用的架構，資源成本優化等問題。有了資源，業務就可以部署代碼，對外提供服務， 代碼上線後會有各種運行時的變更操作， 當然也會有橫向的運維操作， 比如操作係統更新，網絡升級，DNS，IP等等變更操作。監控也是分層的，橫向的有服務器的監控，網絡監控， IDC監控， 縱向來看， 有麵向業務的監控，確保係統的各種異常能被檢測到，並及時提供多種途徑的報警。當業務真的發生故障時，我們也有係統需要能及時的恢複故障，定位故障，甚至能故障自愈，故障預測等。

 

針對雙11這樣的大型活動，我們會做大規模全鏈路的壓測模擬，來發現各種係統異常，為大促做好充分準備。我們也有定期的故障演練係統，來不斷提升故障恢複速度。橫向，縱向之外，我們還有規模化的運維，這個在大促和業務快速擴張時非常有用。

 

運維是很大的一個概念，裏麵有很多專業，這5個能力層次每一層就有很多產品組成。從雲效2.0-智能化運維平台（以下簡稱：StarOps）產品的角度來看， 我們可以劃分為兩個平台，基礎運維平台和應用運維平台。基礎運維平台是統一的，在阿裏有且隻有一個，內部叫StarAgent。但是應用類型比較多，每個業務都有特殊性，所以允許除了通用的“應用運維平台”外，有多個麵向業務的特色的“應用運維平台”，但也都是構建在通用的“應用運維平台”之上，內部叫Normandy。

StarOps當然不會包含所有的運維能力。但對於互聯網企業或者傳統企業+互聯網的場景，大部分公司需要的是運維能力，StarOps會全部包含，主要集中在基礎運維能力(服務器管理)到應用運維能力(PaaS平台)上。而且可以根據用戶自身的需求來自定義選擇。兩個平台本身也具備擴展能力，可以根據我們的SDK來擴展企業自身的業務特色。

 

除了運維平台本身外，還包含軟性的一些運維規範，故障治理的原則等。另外，我們在智能化運維方麵已經有了實踐， 通過算法平台融入到了兩個平台的能力上。在界麵上，我們提供Web， API，命令行工具，手機客戶端，甚至提供大屏產品。

基礎運維平台可以說是IT運維的基礎設施， 阿裏非常重視運維基礎設施的建設，這個係統是對眾多運維係統共性部分的抽象，對上層的運維業務建設至關重要。 在前麵提到的5個運維能力層次中的所有係統都要依賴他， 所以重要性也尤其突出。基礎運維平台主要功能是服務器訪問的通道（命令通道、文件通道、數據通道），職責是維護企業所有服務器訪問的安全，這裏的服務器包括物理機、虛擬機和容器。

阿裏巴巴堡壘機

堡壘機，也可以叫跳板機， 是服務器訪問的一道屏障。阿裏的堡壘機是全球部署的，具備統一的賬號/權限/密鑰等管理，訪問控製，高危攔截，操作錄屏等功能， 最高可以承載5000人同時在線， 並通過了ISO27001等認證。

StarOps套件中的基礎運維平台，就是在阿裏巴巴運維多年實踐上沉澱的結果。這個產品的名字叫StarAgnet，它可以當之無愧的說是阿裏巴巴IT運維的基礎設施。

 

從1萬服務器發展到10萬台，又逐步達到百萬級服務器，基礎設施重要性並不是一開始就被意識到的，是逐漸被發現的過程。無論是運維係統穩定性、性能、容量顯然已經無法滿足服務器數量和業務的快速增長。在2015年我們做了架構升級，StarAgent日均的訪問量從1000萬提升到了1億多，係統穩定性從90%提升到了99.995%。

 

穩定性另外體現在高可用上，我們內部有定期的斷網演練，任何一個機房網絡斷掉，自身服務終止影響麵都控製在一定範圍，都不會對整體的穩定性產生影響， 隻要網絡、服務恢複，受影響的集群就自動恢複。這種演練在內部是常態進行的，保證我們每個版本的代碼都保持健壯。

 

StarAgent 是安全的，我們有非常多的安全策略，比如命令執行的範圍控製，賬號控製，白名單、黑名單控製，高危命令審計/攔截，全鏈路加密簽名等，在阿裏內部安全部有定期的攻防演練，StarAgent無疑就是演練重點。

 

在阿裏內部如果說運維效率比較高，原因之一就是我們的StarAgent基本上統一了運維的通道，任何BU任何係統都不會擅自也不允許去建設自己的通道，統一的好處就是可以統一監管，同時也減少了不必要的重複建設。每個業務運維係統隻要建設自己的業務即可。

 

剛才提到了基礎設施影響麵比較大，所以在建設的時候必須有預見性，在性能方麵我也對未來5年服務器和業務的增長作出了預估，使我們的這次架構升級至少5年內不需要再次重構， 我們可以在此架構之上構建更多的業務，不會讓穩定性和性能羈絆運維業務的發展。目前StarAgent可以滿足每分鍾55萬次調用，幾乎對外部係統沒有強依賴，數據庫、緩存即使失敗也不會對係統造成非常重大的影響。

 

StarAgent的架構是靈活的，新的架構是基於插件的模式，插件可以是靜態的(腳本、命令)，也可以是動態的(後台服務)，Agent Core 會保證這些插件執行的安全，同時又保證在一定的資源消耗之內， 否則就會殺掉(重啟)這個插件進程，插件的開發者當然會收到消息。插件的使用者可以決定在自己的機器上(業務範圍內)運行哪些插件，或者停用哪些插件，以及插件需要的版本，默認情況下插件的版本會自動更新。默認的插件當然是平台來維護的， 目前在阿裏內部我們已經有了150多個插件，其中包括監控、日誌服務、調度、文件分發等。每個插件都可以看作是一個運維係統，而StarAgent的職責就是守護這些運維係統的執行，保證全集團服務器和業務的安全運行。

 

插件的模式同時也簡化了Agent本身的運維，Agent Core 是沒有任何業務屬性的， 職責清晰簡單，隻做插件的維護和必要的自運維， 所以在版本穩定後，基本上不需要太頻繁的更新， 這也符合裝機鏡像3個月更新一次的頻率。

 

對於一個運維百萬級服務器的基礎平台，本身的運維負擔也是比較重的，以前至少需要3個專職的運維，尤其是阿裏的網絡、服務器環境比較複雜，每天答疑工作也不少。但很多工作其實可以總結出規律，提煉抽象，讓機器去做， 所以目前新版的StarAgent自運維能力已經達到95%，不再需要專職的運維了。

 

其他功能諸如Web終端，分布式定時任務等，在雲效使用手冊裏可以找到。不再贅述。

手冊查看：雲效微信號（）菜單欄-雲效產品-使用指南

蜻蜓是基於P2P的文件分發係統，不管是什麼類型的業務運維都需要文件分發，所以也是基礎設施之一。它的好處是保護數據源，加速分發速度，節約跨IDC和跨國的帶寬。

 

下圖是一個500MB文件分發的對比測試，X軸是客戶端數量，Y軸是分發時長，可以看出傳統的文件分發係統隨著客戶端數量的增加，時長就會增加，而且到1200客戶端後就沒有數據了， 因為數據源已經被打爆， 在該測試中蜻蜓可以完美的支持到7000客戶端，分發時長基本保持在10秒左右。

在阿裏內部，典型的應用場景包括：軟件安裝包、配置文件、數據文件、靜態文件、鏡像等。鏡像包括了物理機鏡像、虛擬機鏡像、容器鏡像。對於容器可以支持Docker，Pouch(阿裏自研的容器技術)，Hyper等。架構上非常靈活，沒有侵入性，不需要對容器技術做任何改造。

 

高級的功能特性還包括斷點續傳、智能網絡流控、智能磁盤流控、動態壓縮、鏡像預熱等。

  

在阿裏內部這個係統的業務覆蓋率在95%以上，月均分發量達到了15億次，容量達到3000TB以上。蜻蜓同時也是雙11背後的支撐技術，在雙11前，需要完成15GB的數據文件分發到超過1萬台服務器上。

StarOps套件中另一個是應用運維平台，是架構在基礎平台之上的混合雲PaaS平台，在內部我們叫Normandy。

 

 

一個應用要正常運行，需要資源，資源不僅僅是服務器（物理機、虛擬機、容器）， 還包括網絡（VIP、SLB、DNS等），存儲，數據庫，中間件等，凡是一個應用正常運行需要的所有的物理資源和服務資源都包括。

Normandy是通過資源編排實現資源的provision(生產)的，通常也被叫做Infrastructure as Code。通過代碼的形式將一個應用需要的所有的物理資源和服務資源，以及他們之間的關係都編寫在一段類JSON的代碼裏， 並保存在CMDB中，而且是版本化的， 也就是說資源的任何一次變更改動都會被記錄在案。 這也就形成了用戶(通常就是應用的研發)對應用部署的基礎架構(infrastrucure)的基本需求或者定義。

 

Normandy對於資源的需求和資源實際情況(通常稱為資源實例Instance)會做對比(difference)，如果資源實例和資源的用戶的定義不同，則會觸發資源的生產(provision)直到資源的需求被滿足。這也可以被稱為自動化的資源生產，也可以被稱為資源管理的自愈。如果僅僅就服務器來說，它的功能和Kubernates的ReplicaController是一致的。

 

既然是混合雲PaaS平台當然是支持企業內部IDC的同時也支持阿裏雲，所以應用可以是部署在自有IDC也可以部署在阿裏雲，也可以一部分在自有IDC，一部分在阿裏雲上。

 

混合的模式適合那種初步嚐試公有雲的企業， 也適合那種在個別時間段(比如大促場景，或者壓力測試)下需要額外資源的企業，需要的時候在公有雲上“彈”(scale out)，用完了再縮回來(scale in)。

阿裏巴巴監控智能基線視圖

發布(Release)和部署(Deploy)其實是兩個不太一樣的概念， 發布是用戶可見的，部署則未必。Normandy當然可以同時滿足客戶兩種不同的選擇。默認情況下部署就等同於發布，當然用戶可以自己定製部署而不發布應用(這種需求比較小眾)。

 

Normandy支持的發布模式比較多樣，發布策略也很多，這跟阿裏內部需求的多樣性有關。同時也支持容器發布和非容器的發布(我們叫基線模式)。除此外，還支持動態配置或者開關類型的發布(需要中間件支持)。在能力上則支持2萬台服務器同時發布，日均可以支持50萬次發布。

 

在發布上我們有運維算法平台的支持，可以做到“無人值守”發布， 所謂的“無人值守”發布意味著用戶不再需要盯著發布了， 發布係統如果發現係統有故障就會自動停止發布並通知用戶， 如果一切正常則自動發布完成，無需人的幹預。

 

運維越來越需要得到算法平台的幫助，將人的經驗“沉澱”到係統裏，不斷的累積和完善數據，並依靠算法的幫助來提高運維係統的自動化程度，讓人少犯錯，尤其是低級的錯誤。而發布部署是很多故障造成的根源，這種故障給很多企業造成了巨大損失。如果能在這個地方堵住故障，將極大地提升企業運維穩定性。

StarOps套件還提供了不同維度的監控係統，我們有基礎監控(IDC層麵)也有係統監控和業務監控，可以分別部署。監控係統我們也在做智能化運維探索，比如智能基線， 可以讓我們徹底結束一個業務監控數十個監控配置的困擾，可以預測下一個時間點的業務走向，監控配置隻要根據這個“智能基線”來配置閾值即可。同時我們的監控係統還具備智能故障定位的功能。

 

曆經阿裏紛繁複雜的業務和雙11的各種考驗，監控除了豐富的功能和穩定健壯的內核，還提供了非常炫目的視覺產品，除了傳統的PC屏外，我們還有大屏產品可以獨立部署。

   

阿裏巴巴智能化運維大屏

除了前麵提到的基礎運維平台、應用運維平台、監控、算法平台外， StarOps套件還包括了諸如掌上運維(支持IOS， Android)，ChatOps等功能。            

簡單的講運維本質是幫助業務持續穩定的運行所要做的所有維護性的工作。 在保持業務穩定性的基礎上能降低運維成本，提升運維效率，是運維係統的核心本質。

 

智能運維(AIOps)是需要融入在平台方方麵麵的。智能運維是從手工運維到自動化運維一步步走過來的一個自然的結果， 需要場景、數據和算法。

 

我個人對智能運維的理解是：利用運維算法實現運維的自動化，最終走向無人化運維。所以Gartner對AIOps的解釋是Algorithm IT Operations，並不是一開始以為的人工智能(Artificial Intelligence)運維。

 

 

一、穩定性：運維的本質就是維護係統的穩定性，如何能讓係統平穩的運行，變更更加穩定，故障全麵治理是首要考量的，所以穩定性方麵的智能運維技術演進大致是：

 

異常檢測(Reactive)-> 根因分析(Root Cause Analysis)->根源定位(real time) -> 故障自愈(auto-healing)-> 故障預測(proactive)

 

無人值守發布中應用的是異常檢測的算法，而智能故障定位需要用到的就是後兩種技術。

 

二、效率：在穩定的基礎上我們希望能看到極致的運維的效率，極低的運維成本。

 

智能參數調整係統優化

智能調度、擴容、限流、降級…

 

智能運維的場景很多，在運維的每層都有用武之地。每個點的微創新的累積最終會給智能運維帶來顛覆性的變化。真正實現這種專家經驗和”拍腦袋“運維模式轉變為基於算法和人工智能的自動化運維，最終走向無人化運維。

 

“無人化”當然短期內隻是一個“自動化程度非常高的”的代名詞，在可以看到的未來，“無人化”還是由人來幹預或者參與的，尤其是故障處理。

 

其實自動化被叫做“自働化”更為合理， 人和機器更多是職能上的區別，需要優勢互補，人不再做具體的操作了，由機器替代，但人依然是運維的靈魂，是運維的製定者和修改者，機器隻是執行者，機器隻是幫助人或者提醒人來完成運維操作。

阿裏巴巴智能化運維能力體係

運維對企業很重要，可以說是核心競爭力，不能讓運維拖了業務的後腿。

 

• 基礎運維平台是運維體係建設的基礎設施， 是運維成敗的關鍵。
  
• 穩定是運維的本質， 在穩定性的基礎上追求極致的運維效率和極低的運維成本。
  
• 智能運維不能一蹴而就，必須按部就班，重在場景和數據的建設。

雲效2.0 智能化運維產品體係

 

很多公司業務發展的非常好，但就是運維做的不好，導致業務非常不穩定，三天兩頭出故障，一出故障半天才能恢複。一做發布變更就交易跌0造成資損。如果長期這樣的話，再好的業務也會做黃。這種例子我們看到的比較多。

 

隨著阿裏巴巴越來越重視技術，也越來越開放，運維的幾個產品會逐步開源，同時也會有商業化的產品孵化，比如最近在做的雲效2.0-智能化運維產品StarOps，我們希望阿裏在運維領域多年來沉澱的經驗、走過的彎路，能給大家帶來些啟發，也希望StarOps產品能真正為企業的業務保駕護航。

 

雲效產品體驗：https://www.aliyun.com/product/yunxiao 

 

• 11月02日20:00：Mock平台讓測試插上翅膀

• 11月02日20:30：測試數據中心-互聯網模式下新型的數據準備引擎

• 11月03日15:00：玩轉《阿裏巴巴開發手冊》 P3C插件

• 11月09日20:00：智能運維——百萬級服務器自動化運維怎麼玩？

雲效2.0智能運維平台誠聘資深技術/產品專家，共同打造具備世界級影響力的智能運維平台。