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

客人介紹

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

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

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

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

產(chǎn)品介紹

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

應(yīng)用場(chǎng)景

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

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

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

產(chǎn)品特點(diǎn)

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

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

API

代理

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

邏輯架構(gòu)

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

1.代理注冊(cè)

代理有一個(gè)默認(rèn)配置文件。啟動(dòng)后，它首先連接。連接時(shí)會(huì)上報(bào)本機(jī)IP、SN等必要信息。它估計(jì)應(yīng)該連接到哪個(gè)集群，并將其返回到列表中。然后和它建立一個(gè)長(zhǎng)連接。

2.發(fā)送命令

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

部署框架

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

問題與挑戰(zhàn)

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

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

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

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

系統(tǒng)問題

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

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

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

環(huán)境問題

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

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

穩(wěn)定

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

安全

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

環(huán)境

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

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

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

原創(chuàng)

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