摘要： 12月13-14日，由云棲社區與阿里巴巴技術協會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中為大家分享了2017雙11背后的黑科技。本文是《阿里智能運維平臺如何助力研發應對雙11挑戰》演講整理，在回顧了阿里巴巴運維歷程后，為我們講解了阿里基礎運維平臺和應用運維平臺，并介紹了阿里相關運維產品及阿里在智能運維平臺上的發展成果。

12月13-14日，由云棲社區與阿里巴巴技術協會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中為大家分享了2017雙11背后的黑科技。本文是《阿里智能運維平臺如何助力研發應對雙11挑戰》演講整理，在回顧了阿里巴巴運維歷程后，為我們講解了阿里基礎運維平臺和應用運維平臺，并介紹了阿里相關運維產品及阿里在智能運維平臺上的發展成果。內容如下。

分享嘉賓：

如柏（毛茂德），阿里巴巴高級技術專家，Apache頂級項目CXF初創成員之一，阿里集團基礎架構事業群運維中臺負責人，親歷者。

如柏：雙11已經過去兩周了，但雙11的熱度還在繼續。雙11從09年開始，到12年就變成了一個節日，變成了消費者日，商家感恩消費者的節日。不僅是阿里奉獻給國人的一個節日，更是阿里奉獻給世界的全球購物狂歡節，因為今天阿里的業務已經遍布全世界。業務的爆炸式的增長給技術帶來前所未有的挑戰，今年雙11在技術上又創造了新的高峰。所以在在阿里內部，我們也常說雙11是技術的練兵場，是業務和技術的大協同。每年雙11后，阿里都會給大家分享阿里在雙11中的前沿技術理念和技術成果，運維是阿里雙11技術分享以來的首次分享。運維是業務的重要支撐，運維平臺如何讓業務在如此迅猛的發展下依然穩定、高效的發展是對我們巨大的挑戰。

今天我給大家分享的是阿里智能運維平臺如何協助研發應對雙11的挑戰。今天的分享主要分為四個部分：
回顧阿里運維歷程
基礎運維平臺分享
應用運維平臺分享
阿里在智能運維平臺上的發展成果
阿里運維歷程
阿里的運維和很多公司有相似之處，也經歷了四個階段：
使用命令行工具運維
系統化工具運維
自動化平臺
智能化平臺與無人值守實踐
每個階段的轉變都是一個非常漫長的過程。在這個過程中我們一直秉承一個原則：讓機器做人去做的事；讓系統做可重復的事；讓系統做人做不好的事。

運維是一個非常大的概念。很難用一兩句話能描述清楚，在維基百科中，Operations有十幾個解釋。在我看來中文的“運維”其實非常好的描述了運維的本質，“運”就是讓業務穩定持續的運行，“維”就是運行過程中針對任何出現的問題進行維護，使業務保持繼續運行的能力。運維本質就是讓業務穩定、高效的運做，并在此基礎上逐步降低運維成本。運維的職責覆蓋了產品從設計到發布、運行、成本技術優化及至下線的生命周期。

我們把運維分成五個層次。
資源：Quota管理、資源規劃、資源采購、資源調度、bootstrap
變更：變更信息、應用變更、基礎軟件變更、網絡變更、IDC變更
監控：基礎監控、業務監控、鏈路監控、報警、視圖
穩定性：多活、故障修復、故障定位、故障注入、全鏈路壓測
規模化：一鍵建站、搬遷、騰挪、單元調整
在產品發布前，運維需要對產品的整體架構做合理評估，把控資源訴求，分析產品是否有單點、是否有足夠的容量，是否可容錯，是否有強耦合等。資源規劃評估，包括所需的服務器資源、網絡資源以及資源的分布等，同時把相關產品對資源預算申請的合理性，控制服務成本。
當所有的資源都到位后，把服務部署到線上，形成線上運行的業務。由于軟件需要不停的迭代，這個過程中會發生如網絡架構的變化、服務器淘汰等各種變更。
在運行過程中，監控是必不可少的。基礎服務、基礎軟件、業務、輿情等各方面都需要做監控。
互聯網的快速發展導致業務必須具備非常快速的迭代、快速部署，這要求運維要有規模化的能力，能進行快速復制。比如，如何讓新收購的海外公司融入集團運維體系里，這是一個非常關鍵的業務。
基礎運維平臺
運維的五個層次不可能只用一個系統來承載，每個層次都是有非常多的系統。基礎運維平臺和應用運維平臺主要體現在資源和變更層次，一些監控、規模化的內容也涵蓋在這里。我們把基礎運維平臺定義成IT運維的基礎設施。

基礎設施是怎樣的？電、水、橋梁、機場都是日常生活中的基礎設施，這些基礎設施都有一些共同特征：穩定、安全、統一、有預見性、無需感知。如果電力的供應不穩定，經常發生斷電，我們的財產和日常工作都會遭受到非常大的損失。如果自來水不安全，居民的生命也會造成非常大的損。在運維領域，我們也需要有穩定、安全、統一、有預見性的基礎設施，保證業務的持續穩定發展。

StarAgent就是阿里運維的基礎設施，它的穩定性已經達到99.995%。它也非常安全，因為它關系到整個阿里巴巴所有服務器、所有網絡、所有業務。它有自我保護措施，保證任何人的操作都不影響整個集團的業務。

基礎設施的統一包含統一的標準和統一的數據。統一有三個好處；
保證不需重復建設一些系統；
便于做全局優化；
便于統一規劃，避免不必要的返工。
多個BU建設幾個同樣的基礎設施跟一個BU建設一個基礎設施的成本投入是有很大差別的。如果不同團隊做同一個設施，只有10%的差別，而專門的團隊做基礎設施可以做的非常精非常深。在阿里，我們利用中臺的思想，把所有的基礎設施統一到StarAgent上。
統一基礎設施使我們能看到全局概況而不是某一個BU的情況，方便做全局的優化和高度抽象，保證系統具有可擴展性，能適應所有場景，這也是阿里中臺思想的核心概念。
如果修馬路的人只關注修馬路而缺乏統一規劃思想，忽略管線的鋪設，把馬路修完后又重新刨開處理管線的問題，就會造成很大的損失。運維基礎設施也是一樣，統一規劃能避免重復的返工和成本的浪費。

基礎設施必須具備預見性。新一代StarAgent在設計之初就考慮到了服務器數量和業務增長的趨勢對穩定性和性能可能帶來的沖擊，保證在3-5年內無需重新架構，在這兩方面都必須有預見性的考慮。
基礎設施還有一個特點，就是我們不需要任何人感知到它的存在。如果人們都能感知到基礎設施的存在，說明基礎設施不夠穩定，性能不夠好。阿里做到現在很少有研發真正能感知到StarAgent系統，就像我們感知不到電，感知不到水，因為現在這些基礎設施已經非常穩定，無需我們關注。
阿里運維基礎設施產品介紹
堡壘機主要是負責管理整個阿里賬號、權限、訪問控制、高危攔截、事后審計。阿里堡壘機在阿里是非常具有特色和競爭力的產品，能同時容納5000人在線，也符合ISO的各個行業規范。

StarAgent是一個運維通道，是基礎設施中最核心的功能。它主要分3層架構：中央管控、每個機房集群的管控，物理機、虛擬機、容器上的Agent。Agent是一個插件式管理。截止到目前為止，我們已經有150多個插件，1/3的插件屬于后臺進程類。

StarAgent的職責是保證所有插件、所有后臺進程的穩定運行和作為運維的通道。我們在資源上做了很多限制，在插件安裝前，開發者會定義每個插件所用到的內存、CPU、磁盤、網絡上的流量。如果進程的運行超過限定范圍，我們就把這個進程殺掉來保障服務器的安全。在運維通道方面，我們做了同步命令執行和異步命令執行，目前日均訪問量達1個億。
在安全方面，我們和集團的安全部合作，安排安全演練和攻防演練，保證系統的安全。我們也做了很多命令的攔截、全鏈路命令的加密等。
雖然系統龐大，需要的運維的人員并不多，95%的工作都已經自動化，包括IP端的自動關聯、Agent的自檢自愈等，因此百萬級服務器只需半個人負責運維。當然要從半個人運維進化到無人值守運維是需要付出巨大的努力的。

蜻蜓是基于P2P技術的智能文件分發系統，在架構上與StarAgent類似。下圖為蜻蜓與wget的技術對比。X軸代表并發客戶端數量，從200到7000；Y軸代表完成一個500Mb文件分發的耗時。

從圖中可以看到，隨著客戶端數量的增長，蜻蜓的耗時時間都控制在10秒左右，而傳統文件分發工具耗時升高，甚至在客戶端增長到1200個后，整個集群已無法工作，因為數據源已經被打爆了。蜻蜓不僅可以保護數據源、加快分發速度，也能節省跨IDC帶寬，尤其在跨國業務上，能節省很多跨國帶寬。在今年11月10日10點， 10000PB同時分發5GB預熱數據到上萬臺服務器，這對蜻蜓是一個前所未有的挑戰，也是業務方首次第嘗試。今年雙11我們完美完成了這個任務，并達到100%的成功率。

蜻蜓運用的主要場景是軟件安裝，阿里的發布系統也非常依賴于蜻蜓，目前阿里已整體實現Pouch化，所有的業務都已被容器化，在容器鏡像的傳輸方面也是用的蜻蜓。蜻蜓除了支持特大文件傳輸外，還包括斷點續傳及一些智能化特性如智能網絡、I/O的流控、智能磁盤I/O控制、智能動態壓縮等等。

蜻蜓的訪問次數已經突破了20億次，分發量方面已突破了4PB/月，從圖中可以看到分發量和鏡像分發的占比，通過動態壓縮，整體提速了30%。

蜻蜓已經在GitHub上開源了，開源協議是Apache2.0，蜻蜓開源版可以在https://github.com/alibaba/dragonfly訪問獲取。蜻蜓企業版可以在云效或阿里云容器服務中訪問獲取。開源版與企業版蜻蜓有略微差別。
開源版功能：P2P文件分發，容器鏡像分發、局部限速、磁盤容量預熱
企業版功能：斷點續傳、全局限速、鏡像預熱、支持內存文件系統、智能網絡流控、智能動態壓縮、智能調度策略

鏡像預熱可以幫助我們在業務龐大時快速拉取鏡像。比如應用有上萬臺服務器，如果發布過程中同時拉取鏡像，耗時是非常長的。所以我們在發布前把鏡像推送到就近機房的節點中。在真正發布時，就近拉取鏡像，這樣能大幅度減小的耗時。在實際運營中，根據雙11的數據統計，經過預熱后鏡像拉取耗時降低了67%。
應用運維平臺
應用運維平臺是真正面向研發的運維平臺，是研發經常需要用到的平臺。在應用運維平臺上，我們提供了以下幾個能功能。第一個功能是基礎設施即代碼。一個應用可以通過代碼描述的形式把它需要的所有基礎設施、所有資源描述清楚，并保存在CMDB上作為用戶對應用的資源的需求。所有資源的變更都會被保存下來并且都是版本化的，運維人員可以非常清晰的看到資源的變化情況和操作者是誰。基于這個文本，定義后臺所有資源的生產。我們還有定期巡檢，查看實際資源與用戶定義是否有差異。如果有差異，我們會自動化地幫用戶調整資源，資源的彈性擴容和縮容也是基于這種方式做的。基于傳統模式生產資源構建應用與這種模式相比效率相差幾乎20倍。通過這種方式AE能快速在全球部署一個站，快速復制俄羅斯的一個站點等，得到很大的效率提升。

第二個功能是無人值守發布變更。傳統研發在發布過程的每一步結束時查看各種監控指標及應用日志。在無人值守發布過程中，這個工作交給系統，系統會告訴你哪項指標有異常。人只需要在接收到指標時做評判和決策。判斷異常是不是問題，如果不是，類似的問題可能不會再提出來。舉個簡單的例子，我們在寫代碼的時候都會寫日志并保存下來，分析日志里是否發生異常。當分析出異常時，判斷這個異常是否從未發生過，如果從未發生過，我們就會提示用戶有一個新的異常，發布暫停并讓用戶確認。如果這個異常曾經發生過，但頻率沒有這次發布中高，我們也會認為這是一個異常并提示用戶。類似這樣的指標共有四十多項。通過無人值守發布，降低在發布過程中可能產生的業務故障。實際11月11日的24小時內，我們有大量的發布同時發生，無人值守系統非常好的保障了上線代碼的質量。

應用運維平臺在WEB端和移動端都可以使用，用戶非常容易就可以在手機端得到無人值守發布、資源的創建等情況的消息并快速做出決策。除手機屏外，在阿里雙11協同作戰中也用到了很多監控大屏，這對溝通成本的降低非常有幫助。實際上，整個業務運維平臺上有非常多運維大屏、業務大屏、技術大屏等。整個業務運維平臺有PC端大屏、移動端小屏、作戰大屏。下圖是阿里全新設計的UI，也是在今年雙11用到的大屏。

阿里智能運維進展
AIOps是2016年Gartner發布的新概念，強調基于算法的IT運維實踐，核心是數據和機器學習。在AIOps閉環里會用到監控，觀察所有業務運行狀況，將這些數據分析處理，最后形成自動化執行任務。在智能運維里，最重要的是場景、數據、算法。所以AIOps跟阿里運維過程是密不可分的，在整個智能運維過程中核心問題是如何保證業務發展的穩定，在業務發展穩定后如何提升效率和降低成本。

“亻動”是日語里的自動化的“動”字，概況了我們目前在運維領域的狀態，實際上我們所謂的自動化還是需要人的介入，人是非常關鍵的一個因素，所以智能化運維跟最終實現無人值守運維還存在非常大的差距。

下圖是智能化運維的整體劃分，跟自動駕駛非常相似的，從人工運維過渡到自動化，并且能一鍵化提示，最終實現無人值守運維的過程。

我們在運維平臺做的最多的兩件事是如何保證業務的穩定性和在業務穩定的基礎上如何提升運維效率。在穩定性方面，我們做了異常檢測、根因分析、根源定位，并且嘗試做故障的自愈、故障的預測。在運維效率上我們做了智能參數的調整嘗試。蜻蜓跟IDST合作在智能網絡流控上做了一些工作，它的核心思想是蜻蜓在網絡流控上提供參數，幫助我們設定蜻蜓可利用網絡帶寬的量，保證業務不受影響的情況下，最大限度的利用所有網絡資源。之前我們讓用戶非常方便地設定參數，實際上這是不科學的。我們會做一個全局設定，通過智能化的參數調控、實時大數據分析知道下一個時刻需要用多少網絡帶寬，所有參數包括網絡、磁盤、智能壓縮都不再需要通過人為設定，而是系統在運行中自動化調整到最優的狀態。

在自動化操作包括擴容、限流、降級也是同樣的思想，不需要再人為設定固化的參數，讓系統自動化的調到最優的狀態。我們核心的思想就是希望以前基于專家的經驗轉化成算法和機器學習，充實到整個運維平臺里。

上圖是整個StarOps產品體系，最底層是所有的資源，包括云上資源、混合云資源。在這之上是基礎運維平臺，基礎運維平臺里由很多的模塊組成的，如堡壘機、文件分發等。在基礎運維平臺上是應用運維平臺，它涵蓋資源、變更、監控、故障治理、日常運維等。橫向的來看我們的算法平臺覆蓋了所有板塊。除了上圖顯示的這些系統外，還有很多流程規范、運維紅線、故障管理等。面向用戶側的是最上面的一層，有PC端的web、API、SDK、命令行、移動端運維、大屏等。

總結

以上是生活随笔為你收集整理的阿里智能运维平台如何助力研发应对双11挑战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。