阿里智能運維平臺如何助力研發應對雙11挑戰

摘要： 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運維的基礎設施。

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

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/dr...。蜻蜓企業版能夠在雲效或阿里雲容器服務中訪問獲取。開源版與企業版蜻蜓有略微差異。
開源版功能：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、命令行、移動端運維、大屏等。