點選有驚喜

導讀：還記得那些年我們半夜爬起來重啟伺服器的黑暗歷史嗎？雙11期間，阿里巴巴百萬量級主機管理能安全、穩定、高效，如絲般順滑是如何做到的？阿里巴巴運維中臺技術專家宋意，首次直播揭祕阿里IT運維的基礎設施StarAgent，詳細分析StarAgent是如何支援百萬級規模伺服器管控？如何像生活中的水電煤一樣，做好阿里運維的基礎設施平臺？ 嘉賓介紹 宋健(宋意)：阿里巴巴運維中臺技術專家。工作10年一直專注在運維領域，對於大規模運維體系、自動化運維有著深刻的理解與實踐。2010年加入阿里巴巴，目前負責基礎運維平臺。加入阿里後曾負責：從零建立支付寶基礎監控體系、推動整個集團監控體系整合統一、運維工具&測試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不通、負載高、磁碟滿等等，百萬級規模的伺服器，每天百分之一的機器也有一萬臺，由此帶來的答疑量可想而知。當時我們非常痛苦，團隊每天一半的人員在做答疑，半夜有斷網演練還需要爬起來去重啟服務來恢復。

點選有驚喜