導讀：DevOps 的概念提出接近10年了，提升協作效率，降低開發成本，更穩健可持續的業務運營是DevOps的主旋律。根據2016年DevOps調查報告顯示，一個低效的IT組織跟一個高效的IT組織相比，差距可能是200倍，換句話說低效組織發佈一個功能，高效組織可能已經發布了200個功能；故障恢復的效率差距可能是幾十倍，低效組織花費幾個小時恢復的故障，高效組織可能幾分鐘就搞定了。
在日益激烈的商業競爭環境下，這麼低效的IT組織註定在商業上也是要失敗的。因爲現在是快魚吃慢魚的時代。去年Gartner又提出了AIOps的概念，就是用基於算法來提升運維效率，國內很多公司在各個運維的場景都有了不同程度的應用。
阿里巴巴對DevOps和AIOps有自己的理解和實踐，外界也比較關注擁有衆多業務的龐大組織，是如何開展DevOps的？ 帶着這些問題，阿里集團基礎架構事業羣運維中臺負責人如柏，在2017杭州雲棲大會企業高效研發實踐專場上，詳細介紹了阿里運維體系的演進和在智能化運維方面的工作，希望能給大家帶來一些啓發和借鑑。
嘉賓簡介
毛茂德(花名：如柏)：阿里集團基礎架構事業羣運維中臺負責人。主要負責 IDC 建設、網絡建設、基礎數據庫運維、大數據運維，研發協同等事項，並主導設計構建高可靠、高併發、大規模的基礎運維平臺和應用運維平臺。十餘年來堅持不懈的追求研發、測試、運維效率提升，推動DevOps實施落地。現在正致力於打造基於混合雲的應用運維無人值守解決方案，以及自動化、數據化、智能化應用運維解決方案。
更多智能運維乾貨，關注雲效微信公衆號（ali_yunxiao）!
阿里巴巴是怎麼看運維的？
阿里大致也是經歷了這麼幾個階段：從最開始的人肉運維， 到簡單的工具、自動化， 到系統化和平臺的過程， 自動化到一定程度後，開始探索智能化，無人化運維這些領域， 並在阿里的多個運維繫統裏有所沉澱。
在這個演進過程中，我們始終秉承一種原則， 能用機器去做的就不要讓人去做，自動化一切可以自動化的。很多簡單重複的日常運維操作，開始由研發通過運維平臺來完成。
阿里巴巴運維能力分層圖
上圖是阿里對運維領域的大致分層。每個層都會有不同平臺/系統來承載，運維團隊整體上會幫助業務團隊搞定資源，實現高可用的架構，資源成本優化等問題。有了資源，業務就可以部署代碼，對外提供服務， 代碼上線後會有各種運行時的變更操作， 當然也會有橫向的運維操作， 比如操作系統更新，網絡升級，DNS，IP等等變更操作。監控也是分層的，橫向的有服務器的監控，網絡監控， IDC監控， 縱向來看， 有面向業務的監控，確保系統的各種異常能被檢測到，並及時提供多種途徑的報警。當業務真的發生故障時，我們也有系統需要能及時的恢復故障，定位故障，甚至能故障自愈，故障預測等。
針對雙11這樣的大型活動，我們會做大規模全鏈路的壓測模擬，來發現各種系統異常，爲大促做好充分準備。我們也有定期的故障演練系統，來不斷提升故障恢復速度。橫向，縱向之外，我們還有規模化的運維，這個在大促和業務快速擴張時非常有用。
運維是很大的一個概念，裏面有很多專業，這5個能力層次每一層就有很多產品組成。從雲效2.0-智能化運維平臺（以下簡稱：StarOps）產品的角度來看， 我們可以劃分爲兩個平臺，基礎運維平臺和應用運維平臺。基礎運維平臺是統一的，在阿里有且只有一個，內部叫StarAgent。但是應用類型比較多，每個業務都有特殊性，所以允許除了通用的“應用運維平臺”外，有多個面向業務的特色的“應用運維平臺”，但也都是構建在通用的“應用運維平臺”之上，內部叫Normandy。
StarOps當然不會包含所有的運維能力。但對於互聯網企業或者傳統企業+互聯網的場景，大部分公司需要的是運維能力，StarOps會全部包含，主要集中在基礎運維能力(服務器管理)到應用運維能力(PaaS平臺)上。而且可以根據用戶自身的需求來自定義選擇。兩個平臺本身也具備擴展能力，可以根據我們的SDK來擴展企業自身的業務特色。
除了運維平臺本身外，還包含軟性的一些運維規範，故障治理的原則等。另外，我們在智能化運維方面已經有了實踐， 通過算法平臺融入到了兩個平臺的能力上。在界面上，我們提供Web， API，命令行工具，手機客戶端，甚至提供大屏產品。
基礎運維平臺
基礎運維平臺可以說是IT運維的基礎設施， 阿里非常重視運維基礎設施的建設，這個系統是對衆多運維繫統共性部分的抽象，對上層的運維業務建設至關重要。 在前面提到的5個運維能力層次中的所有系統都要依賴他， 所以重要性也尤其突出。基礎運維平臺主要功能是服務器訪問的通道（命令通道、文件通道、數據通道），職責是維護企業所有服務器訪問的安全，這裏的服務器包括物理機、虛擬機和容器。
StarOps產品裏主要包含有三大系統：1.堡壘機 2.StarAgent 3. 蜻蜓
堡壘機
阿里巴巴堡壘機
堡壘機，也可以叫跳板機， 是服務器訪問的一道屏障。阿里的堡壘機是全球部署的，具備統一的賬號/權限/密鑰等管理，訪問控制，高危攔截，操作錄屏等功能， 最高可以承載5000人同時在線， 並通過了ISO27001等認證。
StarAgent
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終端，分佈式定時任務等，在雲效使用手冊裏可以找到。不再贅述。
手冊查看：雲效微信號（ali_yunxiao）菜單欄-雲效產品-使用指南
蜻蜓
蜻蜓是基於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
簡單的講運維本質是幫助業務持續穩定的運行所要做的所有維護性的工作。 在保持業務穩定性的基礎上能降低運維成本，提升運維效率，是運維繫統的核心本質。
智能運維(AIOps)是需要融入在平臺方方面面的。智能運維是從手工運維到自動化運維一步步走過來的一個自然的結果， 需要場景、數據和算法。
我個人對智能運維的理解是：利用運維算法實現運維的自動化，最終走向無人化運維。所以Gartner對AIOps的解釋是Algorithm IT Operations，並不是一開始以爲的人工智能(Artificial Intelligence)運維。
我個人認爲AIOps可以在兩方面來幫助運維：
一、穩定性：運維的本質就是維護系統的穩定性，如何能讓系統平穩的運行，變更更加穩定，故障全面治理是首要考量的，所以穩定性方面的智能運維技術演進大致是：
異常檢測(Reactive)-> 根因分析(Root Cause Analysis)->根源定位(real time) -> 故障自愈(auto-healing)-> 故障預測(proactive)
無人值守發佈中應用的是異常檢測的算法，而智能故障定位需要用到的就是後兩種技術。
二、效率：在穩定的基礎上我們希望能看到極致的運維的效率，極低的運維成本。
智能參數調整系統優化
智能調度、擴容、限流、降級…
智能運維的場景很多，在運維的每層都有用武之地。每個點的微創新的累積最終會給智能運維帶來顛覆性的變化。真正實現這種專家經驗和”拍腦袋“運維模式轉變爲基於算法和人工智能的自動化運維，最終走向無人化運維。
“無人化”當然短期內只是一個“自動化程度非常高的”的代名詞，在可以看到的未來，“無人化”還是由人來干預或者參與的，尤其是故障處理。
其實自動化被叫做“自働化”更爲合理， 人和機器更多是職能上的區別，需要優勢互補，人不再做具體的操作了，由機器替代，但人依然是運維的靈魂，是運維的制定者和修改者，機器只是執行者，機器只是幫助人或者提醒人來完成運維操作。
阿里巴巴智能化運維能力體系
總結
運維對企業很重要，可以說是核心競爭力，不能讓運維拖了業務的後腿。
- 基礎運維平臺是運維體系建設的基礎設施， 是運維成敗的關鍵。
- 穩定是運維的本質， 在穩定性的基礎上追求極致的運維效率和極低的運維成本。
- 智能運維不能一蹴而就，必須按部就班，重在場景和數據的建設。
雲效2.0 智能化運維產品體系
很多公司業務發展的非常好，但就是運維做的不好，導致業務非常不穩定，三天兩頭出故障，一出故障半天才能恢復。一做發佈變更就交易跌0造成資損。如果長期這樣的話，再好的業務也會做黃。這種例子我們看到的比較多。
隨着阿里巴巴越來越重視技術，也越來越開放，運維的幾個產品會逐步開源，同時也會有商業化的產品孵化，比如最近在做的雲效2.0-智能化運維產品StarOps，我們希望阿里在運維領域多年來沉澱的經驗、走過的彎路，能給大家帶來些啓發，也希望StarOps產品能真正爲企業的業務保駕護航。
雲效2.0 智能化運維產品體驗：https://www.aliyun.com/product/yunxiao