雙11黑科技，阿里百萬級服務器自動化運維繫統StarAgent揭祕

摘要：

還記得那些年咱們半夜爬起來重啓服務器的黑暗歷史嗎？雙11期間，阿里巴巴百萬量級主機管理能安全、穩定、高效，如絲般順滑是如何作到的？阿里巴巴運維中臺技術專家宋意，首次直播揭祕阿里IT運維的基礎設施StarAgent，詳細分析StarAgent是如何支持百萬級規模服務器管控？如何像生活中的水電煤同樣，作...

導讀：還記得那些年咱們半夜爬起來重啓服務器的黑暗歷史嗎？雙11期間，阿里巴巴百萬量級主機管理能安全、穩定、高效，如絲般順滑是如何作到的？阿里巴巴運維中臺技術專家宋意，首次直播揭祕阿里IT運維的基礎設施StarAgent，詳細分析StarAgent是如何支持百萬級規模服務器管控？如何像生活中的水電煤同樣，作好阿里運維的基礎設施平臺？

嘉賓介紹

宋健(宋意)：阿里巴巴運維中臺技術專家。工做10年一直專一在運維領域，對於大規模運維體系、自動化運維有着深入的理解與實踐。2010年加入阿里巴巴，目前負責基礎運維平臺。加入阿里後曾負責：從零創建支付寶基礎監控體系、推進整個集團監控體系整合統1、運維工具&測試PE團隊。

StarAgent

從雲效2.0智能化運維平臺(簡稱：StarOps)產品的角度來看， 能夠將運維劃分爲兩個平臺，基礎運維平臺和應用運維平臺。基礎運維平臺是統一的，叫StarAgent，它能夠當之無愧的說是阿里巴巴IT運維的基礎設施。

從1萬臺服務器發展到10萬臺，又逐步達到百萬級服務器，基礎設施重要性並非一開始就被意識到的，是逐漸被發現的過程。不管是運維繫統穩定性、性能、容量顯然已經沒法知足服務器數量和業務的快速增加。在2015年咱們作了架構升級，StarAgent系統成功率從90%提高到了99.995%，單日調用量也從1000萬提高到了1億多。

服務器規模達到百萬級的企業，在全球應該也是屈指可數的，並且不少企業內部又按業務作了拆分，各業務管理本身的服務器，一套系統管理百萬臺機器的場景應該更少，所以咱們沒有太多能夠借鑑的東西，大部分狀況都是本身在摸索中前進，咱們的系統也是在這個過程當中一步步演變成今天這個樣子。

產品介紹

如上圖所示，StarAgent分了三層：主機層、運維層、業務層，各團隊按分層的方式進行協做，經過這個圖能夠大體瞭解StarAgent產品在集團所處的位置，是集團惟一官方默認的Agent。

• 主機層：指全部服務器，每臺機器上默認安裝了咱們的Agent。
  
• 運管層：指運維管控系統，包括應用運維體系、數據庫運維體系、中間件運維體系、安全體系，各專業領域產品有獨立Portal，經過StarAgent來實現對服務器的操做。
  
• 業務層：指各個BU的業務，大部分BU會直接使用運維層的管控系統，但有的BU可能會有些個性的需求，因此也會有基於下層能力封裝出面向本身業務的一個專用運維portal。
  

應用場景

StarAgent貫穿整個服務器的生命週期：

• 資產覈對：服務器上架後會設置爲網絡啓動，而後會加載一個mini的OS在內存中運行，這個OS中就已經包含了咱們的Agent，OS啓動後就能夠下發指令來採集服務器的硬件信息作資產覈對，如CPU、內存、磁盤的廠商及大小信息等。
  
• OS安裝：交付業務前會先安裝OS，安裝什麼樣的OS也是向這個內存中的Agent下發命令實現的。
  
• 環境配置：OS安裝完成後像機器上的帳號、通用運維腳本、定時任務等基礎環境的初始化。
  
• 應用發佈：應用配置與軟件包的上線發佈。
  
• 運行監控：上線後應用與業務的監控腳本、監控Agent的安裝。
  
• 平常運維：登陸服務器、單機、批量等平常運維操做，包括業務下線前的清理工做等。
  

產品數據

這也是咱們產品在阿里內部的一些數據，天天有上億次的服務器操做，1分鐘能夠操做50萬臺服務器，插件有150多個，管理服務器規模在百萬級，Agent資源佔有率也特別低，支持Linux/Windows主流發行版。

產品功能

StarAgent核心功能能夠總結爲兩大塊：管控通道和系統配置。

這與開源的saltstack/puppet/ansible等配置管理產品相似，咱們作的更精細一些。

• 管控通道：全部運維操做最終都會轉化爲命令到服務器上去執行，這個命令通道是全網惟一的，這裏會有相應的用戶權限控制、操做審計、高危命令攔截等能力。
  
• 系統配置：公共運維腳本、定時任務、系統帳號、監控Agent等等，這些配置會在Agent啓動後自動初始化，OS中默認打包有Agent，因此能夠作到開機後全自動完成服務器運維基礎環境的初始化。

按照Portal、API、Agent細分後的功能列表，Portal主要給一線開發與運維同窗使用， API更可能是給到上層運維繫統來調用，Agent表明每臺機器上直接可使用的能力。

Portal

• 運維市場：也叫插件平臺，相似於手機中的應用市場。各個業務的負責人在市場中若是發現了一些不錯的小工具，點下安裝就能夠自動安裝到業務對應的機器上，業務若是新擴容了服務器也會自動地安裝這些小工具。小工具的開發也是來自於一線的同窗，你們均可以把本身開發的工具上傳到運維市場，分享給其餘人使用。
  
• WEB終端：在Portal上點下一臺機器後會自動彈出一個終端，和SSH登陸到服務器的效果徹底同樣，基於當前登陸人信息全自動鑑權，這個終端還能夠經過JS的方式嵌入到任何其它網頁中。
  
• 文件分發：比較好理解就不展開介紹了。
  
• 定時任務：與crontab相似，不過咱們支持秒級而且能夠打散執行，好比對一批機器增長每分鐘執行一次的定時任務，用crontab全部機器會固定的在每分鐘第1秒執行，咱們在保證每分鐘執行一次的同時每臺機器上的執行時間不同。
  
• 主機帳號：包括三塊功能：我的登陸服務器的帳號、機器上admin等公共帳號、一臺機器與其它機器之間打通SSH通道。
  
• API帳號：與右邊的API功能是緊密相關的，若是要使用右邊這些能力，必須先申請一個API帳號。
  

API

• CMD：調用時傳入目標機器與命令信息，就能夠實現讓指定臺機器執行命令，登陸機器上執行的命令均可以經過CMD接口來調用。
  
• Plugin：對應前面的運維市場，若是經過運維市場把一些腳本安裝到機器上，能夠經過plugin的方式來直接執行這些腳本。
  
• File/Store：二者都是作文件分發，區別是file依賴下載源，store能夠在調用HTTP API時直接把腳本內容POST過來。File基於P2P實現，在阿里內部有一個叫蜻蜓的產品專門作文件下載，好處是幾百臺、幾千臺機器同時下載時只會回源一次，對源的壓力很是小，機器之間可以互相共享下載，目前蜻蜓已經開源。
  
• Action：對以上功能組裝使用，例：先用file去下載腳本，下載完成後再用cmd來執行，而且中間支持and or的條件判斷，下載成功纔會用cmd執行。
  

Agent

• Hostinfo：提供採集服務器的主機名、IP、SN等信息。
  
• 數據通道：在每臺機器上執行的命令或腳本的輸出直接丟到這裏，會自動把數據上傳到中心，而後在中心消費這些數據。
  
• 增量日誌和P2P文件：都是第三方來開發的，在運維市場經過插件的方式安裝到每臺機器上。
  

圖：左邊是Web終端，自動鑑權並且能夠經過JS的方式嵌到任何web頁面裏面。

右邊是批量執行命令的功能，先選中一批機器，在這個頁面輸入的命令都會發到這一批機器上。

系統架構

邏輯架構

咱們的系統是三層架構，Agent安裝在每臺機器上，與channel創建長鏈接，而後channel按期把鏈接本身的agent信息上報到中心，中心會維護完整的agent與channel關係數據。分享兩個流程：

1.Agent註冊

Agent有一個默認配置文件，啓動後首先鏈接ConfigService，鏈接時會上報本機的IP、SN等必要信息，ConfigService計算出應該連哪一個channel集羣，返回給channel列表，收到結果後斷開與ConfigService的鏈接，而後與channel創建起長鏈接。

2.下發命令

外部系統都是調用proxy來下發命令，proxy收到請求後會根據目標機器查出對應channel，而後把任務下發給channel，channel再把命令轉發到agent去執行。

部署架構

最下面是每一個IDC，channel會在每一個IDC中部署一套集羣，Agent會隨機在其中的一臺創建長鏈接。上面就是中心，中心作了雙機房容災部署，同時在線提供服務，其中一個機房掛掉對業務是沒有影響的。

問題&挑戰

如上圖：是咱們前年在作系統重構時遇到的問題：

前三個問題有點相似，主要是任務由狀態致使，1.0的manager能夠理解爲2.0中的proxy，server等同於channel，每時每刻線上都有大量系統在下發命令，在1.0中若是把manager/server/agent任何一個角色重啓，那麼在這條鏈路上的任務都會失敗，好比server重啓後與它相連的agent都會斷開，由於鏈路斷了，當時通過這臺server下發的命令就拿不到結果了。重啓server又會引起第六個負載不均的問題，假設一個IDC中有一萬臺機器，兩臺server各連了5000臺，重啓後這一萬臺就全連到了一臺server上。

用戶若是調用API下發命令失敗就會找過來讓咱們查緣由，有的時候確實是系統的問題，但也有不少是自己的環境問題，好比機器宕機、SSH不通、負載高、磁盤滿等等，百萬級規模的服務器，天天百分之一的機器也有一萬臺，由此帶來的答疑量可想而知。當時咱們很是痛苦，團隊天天一半的人員在作答疑，半夜有斷網演練還須要爬起來去重啓服務來恢復。

面對這些問題如何解決呢？咱們將問題分爲系統問題和環境問題兩大類。

系統問題

咱們把系統作了一次完全的重構，採用分佈式消息架構，仍是如下發命令爲例，每次下發是一次任務，在2.0中對每一個任務增長了狀態，proxy在收到下發命令請求後，會先記錄並把狀態置爲收到任務，而後再向agent下發，agent收到任務後會當即響應，proxy收到agent的響應後會把狀態置爲執行中，agent執行完成後主動上報結果，proxy收到結果後再把狀態置爲執行完成。

整個過程當中proxy與agent之間的消息都有確認機制，沒有獲得確認就會進行重試，這樣任務執行過程當中涉及角色若是重啓，對任務自己就沒有太大影響了。

2.0中channel集羣內的機器之間會互相通訊，按期報告本身連的agent數量等信息，結合收到的信息與本身的信息，若是本身連的agent過多，會自動斷開近期無任務執行的機器，經過這樣的方式解決負載均衡的問題。中心節點與全部channel都有長鏈接，同時保存有每臺channel鏈接的agent數量，當發現某個機房有channel異常或者容量太高時，會自動觸發擴容或者從其它機房臨時借調channel，在容量恢復後又會自動剔除擴容的channel。

環境問題

在2.0中proxy/channel/agent每一層都有詳細的錯誤碼，經過錯誤碼能夠直觀判斷是什麼緣由致使的任務出錯。

針對機器自己的問題，與監控系統中的數據打通，任務失敗後會觸發環境檢查，包括宕機、磁盤空間、負載等，若是有相應問題API會直接返回機器有問題，而且把機器的負責人也一併返回，這樣用戶一看結果就知道什麼緣由該找誰處理。同時還會把這些診斷能力用釘釘機器人的方式開放出來，這樣你們平時能夠直接在羣裏@機器人來作檢查確認。

穩定

經過前面的介紹能夠看到咱們實際上是運維的基礎設施，就像生活中的水電煤同樣，你們全部對服務器的操做強依賴咱們。當咱們出現故障的時候，若是線上業務也出現了嚴重故障，這時候業務故障只能乾等着，由於操做不了服務器，作不了發佈和變動，因此對系統穩定性的要求很是高，作到了同城雙機房、異地多中心容災部署，依賴的存儲有mysql/redis/hbase，這些存儲自己就有高可用保障，在這個之上咱們又作了存儲間的冗餘，確保任何一個單一存儲故障不會影響到業務，相信整個業內不多有系統會作到這個程度。

安全

1分鐘能夠操做50萬臺服務器，輸入命令敲回車就這麼一瞬間，就能夠操做數萬臺機器，若是是個惡意的破壞性操做，影響可想而知。因此作了高危命令阻斷的功能，對於一些高危操做自動識別與攔截。整個調用鏈路也是通過加密與簽名，確保第三方沒法破解或篡改。針對API帳號可能存在的泄露問題，還開發了命令映射的功能，把操做系統中的命令用映射的方式改掉，好比執行reboot命令，可能要傳入a1b2才行，每一個API帳號的映射關係都是不同的。

環境

機器宕機這類環境問題，經過與監控數據打通解決，前面已經講過，網絡隔離的問題也再也不過多陳述。這裏重點說明下CMDB中錄入的數據與Agent採集的數據不一致的問題，主要是SN、IP這些基礎信息，由於你們在使用的時候都是先從CMDB取出機器信息，再來調用咱們的系統，若是不一致就會致使調用直接失敗，爲何會出現SN/IP不一致的問題？

CMDB中的數據通常由人工或者其它系統觸發錄入，而Agent是從機器上真實採集的，有的機器主板沒燒錄SN、有的機器有不少塊網卡等，環境比較複雜各類狀況都有。

這種狀況就是經過創建規範來解決，分別制定SN、IP採集規範，容許機器上自定義機器的SN/IP，配合規範還提供有采集工具，不只是咱們的Agent，全部其它採集機器信息的場景均可以使用這個採集工具，當規範發生更新時咱們會同步更新小工具，以此實現對上層業務的透明化。