簡介：還記得這些年我們晚上爬起來重啟服務(wù)器的黑歷史嗎？雙十一期間，阿里巴巴是如何安全、穩(wěn)定、高效、順暢地管理數(shù)百萬主機的？阿里巴巴運維中心技術(shù)專家宋毅首次解密阿里巴巴IT運維的基礎(chǔ)設(shè)施，詳細分析了如何支撐百萬級規(guī)模服務(wù)器的管控？如何像生活中的水原煤一樣做好阿里巴巴運維的基礎(chǔ)設(shè)施平臺？

客人介紹

宋?。⊿ong Yi）：阿里巴巴運維中臺技術(shù)專家。經(jīng)過10年的工作，他依然專注于運維領(lǐng)??域，對大型運維系統(tǒng)和自動化運維有著深刻的理解和實踐。 2010年加入阿里巴巴，目前負責基礎(chǔ)運維平臺。加入阿里后負責：從零開始搭建支付寶基礎(chǔ)監(jiān)控系統(tǒng)，推進全集團監(jiān)控系統(tǒng)整合一、運維工具&測試PE團隊。

從云效應(yīng)來看2.0智能運維平臺（簡稱：）產(chǎn)品，運維可以定義為兩個平臺，基礎(chǔ)運維平臺和應(yīng)用運維平臺?；A(chǔ)運維平臺是統(tǒng)一的，稱為，不愧是阿里巴巴IT運維的基礎(chǔ)設(shè)施。

從10000臺服務(wù)器到臺服務(wù)器，再到數(shù)百萬臺服務(wù)器，基礎(chǔ)設(shè)施的重要性并不是一開始就意識到的，而是逐漸被發(fā)現(xiàn)的。無論是運維系統(tǒng)的穩(wěn)定性、性能還是容量，早已無法滿足服務(wù)器數(shù)量和業(yè)務(wù)的快速下滑。 2015年我們升級架構(gòu)，系統(tǒng)成功率從90%提升到99.995%，單日調(diào)用量也從1000萬提升到1億多。

全球擁有百萬級服務(wù)器規(guī)模的公司屈指可數(shù)。然而，許多公司已經(jīng)被業(yè)務(wù)拆分。每個企業(yè)管理自己的服務(wù)器，一個系統(tǒng)管理數(shù)百萬臺機器。應(yīng)該少一些，所以我們沒有太多可以學(xué)習(xí)的東西。在大多數(shù)情況下，我們都在以自己的方式前進，我們的系統(tǒng)也在這個過程中演變成今天的樣子。

產(chǎn)品介紹

如上圖，分為三層：主機層、運維層、業(yè)務(wù)層。每個團隊根據(jù)分層方法進行合作。通過這張圖，可以大致了解產(chǎn)品在組內(nèi)的位置，是組內(nèi)唯一的一個。官方默認代理。

應(yīng)用場景

貫穿整個服務(wù)器生命周期：

產(chǎn)品數(shù)據(jù)

這也是我們在阿里產(chǎn)品的一些數(shù)據(jù)。每天晚上有上億臺服務(wù)器操作，1分鐘可以操作50萬臺服務(wù)器，有150多個插件，管理服務(wù)器規(guī)模在百萬級，Agent資源占用率也很低支持 Linux/主流發(fā)行版。

產(chǎn)品特點

核心功能可以概括為兩大部分：控制通道和系統(tǒng)配置。這個和開源的//和其他配置管理產(chǎn)品差不多，我們做的更精細一點。

按照API、Agent細分的功能列表主要供一線開發(fā)運維朋友使用。 API 多用于底層運維系統(tǒng)調(diào)用。 Agent代表了可以在每臺機器上直接使用的能力。

API

代理

圖：左邊是web終端，手動發(fā)信號，可以以JS的形式嵌入到任何網(wǎng)頁中。左邊是批量執(zhí)行命令的功能。首先選擇一批機器，在這個頁面輸入的命令會發(fā)送到這批機器上。系統(tǒng)架構(gòu)

邏輯架構(gòu)

我們的系統(tǒng)是三層架構(gòu)。每臺機器安裝代理，完善長連接。之后，連接代理的信息會定期上報給中心，中心會維護完整的代理和關(guān)系數(shù)據(jù)。共享兩個進程：

1.代理注冊

代理有一個默認配置文件。啟動后，它首先連接。連接時會上報本機IP、SN等必要信息。它估計應(yīng)該連接到哪個集群，并將其返回到列表中。然后和它建立一個長連接。

2.發(fā)送命令

外部系統(tǒng)調(diào)用代理發(fā)出命令。 proxy收到請求后，會根據(jù)目標機器找出對應(yīng)關(guān)系，然后下發(fā)任務(wù)給agent，再把命令轉(zhuǎn)發(fā)給agent執(zhí)行。

部署框架

最底層是每個IDC，每個IDC會部署一個集群服務(wù)器運維技術(shù)，Agent會在其中一個隨機建立一個長連接。里面是中心。中心部署了兩個機房進行容災(zāi)，同時在線提供服務(wù)。其中一間機房的死亡不會影響業(yè)務(wù)。

問題與挑戰(zhàn)

如上圖：是前年在系統(tǒng)建設(shè)中遇到的問題：

前三個問題有點類似，主要是任務(wù)是狀態(tài)引起的。 1.0 可以理解為 2.0 中的代理，相當于一直有大量系統(tǒng)在線 發(fā)出命令時，如果重啟 //agent 的任何角色在 1.0 中，此鏈接上的任務(wù)將失敗。比如連接到它的agent重啟后會斷開連接，因為鏈條斷了，當時這個站下達的命令是拿不到結(jié)果的。重啟會導(dǎo)致負載不均的第六個問題。假設(shè)一個IDC有10000臺機器，兩臺機器分別連接5000臺機器。重啟后，10000臺機器全部連接到一臺機器上。

如果用戶調(diào)用API發(fā)出命令失敗，他們會過來讓我們檢查原因。有時候確實是系統(tǒng)問題，但是也有很多環(huán)境問題，比如機器宕機、SSH失敗、負載過高等等。當磁盤滿了等等，百萬級的服務(wù)器有10000臺機器，而每晚有百分之一的機器?；卮饐栴}的數(shù)量可想而知。那個時候，我們很郁悶。每天晚上有一半的團隊成員在回答問題。晚上有一次斷網(wǎng)演習(xí)，我們只好爬起來重啟服務(wù)恢復(fù)。

如何解決這個問題？我們將問題分為兩類：系統(tǒng)問題和環(huán)境問題。

系統(tǒng)問題

我們已經(jīng)對系統(tǒng)進行了徹底的構(gòu)建，采用分布式消息架構(gòu)，或者以發(fā)送如下命令為例，每次都是一個任務(wù)，每個任務(wù)的狀態(tài)在2.0 , 代理收到發(fā)出命令的請求后，會先記錄并設(shè)置接收任務(wù)的狀態(tài)，然后發(fā)送給代理。代理收到任務(wù)后，會立即響應(yīng)。代理收到代理的響應(yīng)后，將狀態(tài)設(shè)置為執(zhí)行期間，代理在執(zhí)行完成后主動上報結(jié)果，代理收到結(jié)果后將狀態(tài)設(shè)置為執(zhí)行完成。

整個過程中proxy和agent之間的消息都有確認機制，重試會在不確認的情況下進行。這樣，如果重啟了任務(wù)執(zhí)行過程中涉及的角色，對任務(wù)本身不會有太大影響。

2.0 集群中的機器會相互通信服務(wù)器運維技術(shù)，定期上報連接的agent數(shù)量等信息，并將接收到的信息與自己的信息結(jié)合起來。如果連接的agent太多，會手動斷開最近沒有任務(wù)執(zhí)行的機器，通過這種方式解決負載均衡問題。中心節(jié)點與所有節(jié)點有長期連接，并存儲每個連接的代理數(shù)量。當發(fā)現(xiàn)某個機房出現(xiàn)異?；蛉萘窟^高時，會手動觸發(fā)擴容或臨時借用其他機房。擴展將被手動移除。

環(huán)境問題

在2.0中，每一層proxy//agent都有詳細的錯誤碼。通過錯誤碼，可以直觀的判斷出任務(wù)錯誤的原因。

對于機器本身的問題，連接監(jiān)控系統(tǒng)中的數(shù)據(jù)。任務(wù)失敗后會觸發(fā)環(huán)境檢測，包括宕機時間、磁盤空間、負載等，如果有相應(yīng)問題，API會直接返回本機。數(shù)據(jù)負責人也返回，讓用戶看結(jié)果就知道原因和處理誰。同時，這些診斷能力會以釘釘機器人的形式開放，讓你平時可以直接在群@機器人做測試和確認。

穩(wěn)定

從上面的介紹可以看出，我們可能是運維的基礎(chǔ)設(shè)施。就像生活中的水、電和煤一樣，您所有的服務(wù)器運營都非常依賴我們。當我們出現(xiàn)故障時，如果線上業(yè)務(wù)也出現(xiàn)嚴重故障，那么業(yè)務(wù)故障只能等待。由于服務(wù)器無法操作，無法發(fā)布和更改，因此對系統(tǒng)穩(wěn)定性的要求非常高。在同城雙機房、異地多中心容災(zāi)部署中，依賴的存儲是mysql/redis/hbase，而這個存儲本身就有高可用保障。單個存儲故障不會影響業(yè)務(wù)，相信業(yè)內(nèi)很少有系統(tǒng)能達到這個水平。

安全

1分鐘可以操作50萬臺服務(wù)器，輸入命令回車瞬間可以操作上萬臺機器。如果是惡意破壞性操作，其影響可想而知。因此實現(xiàn)了攔截高危指令的功能，對一些高危操作進行人工識別和攔截。整個調(diào)用鏈也經(jīng)過加密和簽名，確保第三方難以破解或篡改。針對API賬號可能泄露的問題，還開發(fā)了命令映射功能，通過映射改變操作系統(tǒng)中的命令。例如，要執(zhí)行命令，可能需要傳入 a1b2。每個API賬號的映射關(guān)系都不一樣。

環(huán)境

連接監(jiān)控數(shù)據(jù)可以解決機器停機等環(huán)境問題。前面說了，網(wǎng)絡(luò)隔離的問題就不過多討論了。這里我們重點關(guān)注CMDB中錄入的數(shù)據(jù)與Agent采集的數(shù)據(jù)不一致的問題，主要是SN、IP等基礎(chǔ)信息，因為你在使用的時候，首先從CMDB中提取機器信息，而然后調(diào)用我們的系統(tǒng)。如果不一致會直接導(dǎo)致調(diào)用失敗，為什么會出現(xiàn)SN/IP不一致的問題？

CMDB 中的數(shù)據(jù)通常是由手動或其他系統(tǒng)觸發(fā)和輸入的，而 Agent 實際上是從機器上收集的。有的機器顯卡上沒有SN編程，有的機器網(wǎng)卡很多等等，環(huán)境比較復(fù)雜，各種情況都有。

這些情況都是通過構(gòu)建規(guī)范來解決的，分別制定SN和IP采集規(guī)范，允許在機器上自定義機器的SN/IP，并提供采集工具配合規(guī)范。除了我們的Agent，其他所有機器信息都被收集了這個收集工具可以在所有場景中使用。當規(guī)范更新時，我們會同步更新，實現(xiàn)對底層業(yè)務(wù)的透明化。

原創(chuàng)

更多技術(shù)干貨，請關(guān)注云棲社區(qū)知乎組織號：阿里云云棲社區(qū)-知乎