差不多在兩年前，阿里內(nèi)部出現(xiàn)了很多運維中臺、研發(fā)中臺等等，那有沒有后臺呢？不好意思，我們只有中臺，沒有后臺，會在中臺上構(gòu)建與業(yè)務(wù)相關(guān)的各個前臺。

[[232760]]

目前阿里的業(yè)務(wù)幾乎覆蓋了所有行業(yè)，有著很多業(yè)務(wù)線，如果業(yè)務(wù)線的前臺到中臺全部都是我們自己去建設(shè)，會造成一個巨大的浪費。

我們需要去構(gòu)建整個集團、或是阿里巴巴經(jīng)濟體所需要的統(tǒng)一的平臺，避免重復(fù)性的建設(shè)。

最近我們在思考運維的本質(zhì)到底是什么，就突然聯(lián)想到一部名叫《太空旅客》的電影。

電影里的飛船裝了 5000 個乘客和大約 50 多個機組人員，從地球飛往其他星球要飛 120 年。

這意味著整艘飛船必須是無人駕駛的，因為沒有人可以活 120 年，靠人去操控這樣一艘飛船根本不可能。

所以飛船里有一套運維系統(tǒng)，也就是靠這套系統(tǒng)的運作，整艘飛船才可以飛 120 年不出故障。

這和我們現(xiàn)在做的運維系統(tǒng)是一樣的。我認為運維的本質(zhì)就是在線，即如何讓這種在線的業(yè)務(wù)能持續(xù)不斷地運行，滿足客戶的需求。

如果把業(yè)務(wù)比作一艘飛船，你能否讓飛船持續(xù)運行？遇到了任何故障或問題時能否自動解決？我覺得這就是運維的作用——穩(wěn)定性。

而隨著業(yè)務(wù)復(fù)雜度越來越高，已經(jīng)沒有辦法靠人來運維整個平臺和業(yè)務(wù)了?？梢栽囅耄绻咳?，那需要投入多少人力？

當(dāng)發(fā)生問題時，我們?nèi)藶榈厝ジ兄獑栴}后排查問題、定位問題，這時業(yè)務(wù)可能已經(jīng)掛了很長時間。

所以這也是我今天想跟大家分享的，我們基于對運維的理解構(gòu)建起的智能化運維平臺。

本文分為如下四個部分進行分享：

• 阿里運維歷程
• 基礎(chǔ)運維平臺
• 應(yīng)用運維平臺
• AIOps

阿里運維歷程

阿里的運維和很多公司有相似之處，也經(jīng)歷了四個階段：

• 使用命令行工具運維
• 系統(tǒng)化工具運維
• 自動化平臺
• 智能化平臺與無人值守實踐

按照上圖這個層次，我們把運維的工作進行劃分。對于雙十一這樣大型的活動，承載這么大的流量就必須要有很多資源。

我們每年在準備資源的過程中會花大量的人力和資源，并且持續(xù)時間長，大概需要提前半年準備。

而在近幾年，阿里云發(fā)展起來了，等到更加成熟了就會把這個業(yè)務(wù)往云上搬。

我們會先把機器買進來，把阿里云的整個基礎(chǔ)設(shè)施裝起來后，就把阿里的所有電商業(yè)務(wù)部署到它上面。

等雙十一結(jié)束后，有很多業(yè)務(wù)其實不需要用那么多機器，我們就把這些資源重新做一個格式化，再還給阿里云，由阿里云做另外的售賣。

這也是為什么阿里會做阿里云的原因。因為這種大促的時間比較短，但特別耗資源，且需要大量的運維人員和工程師，所以我們會在資源這個層面做大量工作。

現(xiàn)在我們的平臺實際上會更加自動化，用公有云的資源去做一些彈性，包括資源的利用率。

而最近我們有一個系統(tǒng)，是屬于做資源調(diào)度的系統(tǒng)，它能夠更好地利用云資源，提升資源的利用率。

事實上阿里的整個電商的資源利用率是比較低的，平均下來只有 10% 左右，所以我們會在這塊大力投入，包括做一些智能化的東西。

而有了資源后就需要部署，所以我們就提前鋪設(shè)了一層，包括數(shù)據(jù)庫的一些東西，這屬于一個變更，即把代碼部署上去，或做網(wǎng)絡(luò)的更新等。

等代碼鋪設(shè)上去后，還要清楚線上運行后的狀況，因此監(jiān)控是必不可少的。我們有很多監(jiān)控系統(tǒng)，比如說監(jiān)控 IDC 層面的濕度、溫度等，如果這個地方出現(xiàn)問題，那整個機房就會過載。

網(wǎng)絡(luò)則是另一個專業(yè)領(lǐng)域的東西，我們需要去監(jiān)控整個網(wǎng)絡(luò)、交換機，讓網(wǎng)絡(luò)處于一個健康的狀況。

再次，還需要有服務(wù)器層面的監(jiān)控，應(yīng)用、業(yè)務(wù)層面的監(jiān)控等，所有的這些都是不一樣的，屬于不同領(lǐng)域，因此我們的監(jiān)控系統(tǒng)也比較多。

再往上就是運維最核心的本質(zhì)——穩(wěn)定性了，我認為這是怎么強調(diào)都不為過的。

我們的很多業(yè)務(wù)部門都有一個專門做穩(wěn)定性的團隊，覆蓋從業(yè)務(wù)到技術(shù)的環(huán)境。

而像阿里這種體量的公司，規(guī)模化是必不可少的，我們現(xiàn)在正在收購很多公司，那怎么讓這些公司的運維體系能一次性快速便捷地搬遷進來，利用到我們中臺的能力？

比如我們做雙十一大促銷活動時，如何能快速把業(yè)務(wù)部署到云上？這些都需要做規(guī)?；墓ぷ?。

在以上這張圖里，我負責(zé)的是藍色部分的工作，主要是應(yīng)用運維平臺和基礎(chǔ)運維平臺，包括螞蟻金服、菜鳥等個性化的東西，可以基于我們的應(yīng)用運維平臺做一些定制化的工作。

基礎(chǔ)運維平臺

基礎(chǔ)運維平臺是中臺最核心的部分，是全部都打通的。我們的基礎(chǔ)運維平臺和基礎(chǔ)設(shè)施是一樣的。這就是剛才提到的中臺概念，沒有必要讓所有人都去建設(shè)這個基礎(chǔ)設(shè)施。

就像國家的基礎(chǔ)設(shè)施不會讓每個人都去建設(shè)，而是由國家統(tǒng)一去做，能節(jié)約大量的人力和資本，并把基礎(chǔ)設(shè)施做精、做深，這是非常有必要的，可以避免大量重復(fù)性工作。

運維通道：StarAgent

StarAgent 就是阿里運維的基礎(chǔ)設(shè)施，它是一個運維通道，是基礎(chǔ)設(shè)施中最核心的功能，主要是做命令的下發(fā)與執(zhí)行。

所有阿里的運維進程都在這上面，包括監(jiān)控系統(tǒng)、調(diào)度所需的所有東西、數(shù)據(jù)采集等。信息的采集都在這個平臺上，以插件的形式運行。

這個系統(tǒng)一天差不多有一個多億的訪問量且還在不斷增長，因為我們的服務(wù)器數(shù)量在不斷增長，業(yè)務(wù)的數(shù)量也在不斷增長，但它的穩(wěn)定性還是達到了 99.995%

場景

在阿里運維的整個生命周期，包括裝機、應(yīng)用發(fā)布、配置變更、信息采集、監(jiān)控和日常運維等，我們都會用到這個場景。

核心功能

核心功能如上圖所示，就是命令的通道執(zhí)行這樣的一些方式，功能比較簡單，主要核心能力是在穩(wěn)定性和性能上面。

系統(tǒng)架構(gòu)

這個系統(tǒng)是由三層架構(gòu)搭建而成的，第一層就是我們中央的一層?xùn)|西，用戶如何訪問這個？

我們會通過用戶的 API 做調(diào)用，如果權(quán)限足夠大，可以給全網(wǎng)所有的機器下發(fā)指令。

每一個機房都有一個管控的服務(wù)器，即管控這個機房所有的機器，服務(wù)器都通過長鏈接的方式連到這個地方。

還有末端的，就是一個插件的結(jié)構(gòu)，大概如上圖所示，會把信息全部都上報上來等等，這個也是能夠支持網(wǎng)絡(luò)結(jié)構(gòu)的。

穩(wěn)定性

穩(wěn)定性其實是最重要的，我們做了很多這方面的優(yōu)化，但因為細節(jié)太多，此處就不具體展開了，最主要的是你如何能保證這個系統(tǒng)是穩(wěn)定/活的。它比監(jiān)控還重要，因為我們的監(jiān)控也是依賴這個。

當(dāng)監(jiān)控系統(tǒng)掛掉之后，監(jiān)控錄像或其他都有可能出現(xiàn)問題，會出現(xiàn)循環(huán)依賴。

因此不能單獨依賴一個存儲的系統(tǒng)，反而要依賴更多的存儲系統(tǒng)，來保證系統(tǒng)的健壯性。

這是非常重要的，如果一個掛了就有可能導(dǎo)致我們回到非常原始的手工運維狀態(tài)。

安全

上圖是安全方面的策略，我們有比較多重的保護，包括保護下發(fā)指令的安全不被篡改，以及整個賬號體系有非常健壯的設(shè)計，來保證命令執(zhí)行的安全性。我們所有的命令都會做一個映射。

另外，權(quán)限還是非常大的，這里必不可少的就是要保護整個系統(tǒng)，如果有特別高風(fēng)險的命令在執(zhí)行，我們必須能夠快速準確地識別出來，從而保護整個服務(wù)器的安全。

自動化運維

自動化運維非常重要，我們不可能投入過多的人力去運維這么龐大的系統(tǒng)來管理所有的服務(wù)器。

如果有哪怕 1% 的服務(wù)器出現(xiàn)了連接問題，我們都得投入大量人力去做，這也是為什么自動化運維非常重要的原因。

以前可能需要十幾人，每個人要頻繁地去處理各種連接性的問題，所以我認為自動化運維是根本的東西。

插件平臺

[[232762]]

最后簡單介紹一下插件平臺。這是一個描述文件，即你要跑什么進程、利用多少 CPU 內(nèi)存等都可以設(shè)定。

當(dāng)這個系統(tǒng)發(fā)生各種問題時，會自動幫你把這個進程解決掉，再通知你上線去做一些排查。

因為阿里的服務(wù)器和網(wǎng)絡(luò)都非常復(fù)雜，我們在一個業(yè)務(wù)線里測試的結(jié)果沒問題，并不代表能保證所有的業(yè)務(wù)線都沒有問題。命令一直在下發(fā)，如果不退出，累計起來就會有很大問題。

這個系統(tǒng)本質(zhì)上是保障服務(wù)器的穩(wěn)定性，所以不管發(fā)生什么情況，我們要把服務(wù)器上的所有命令都管控起來，只要有問題就采取一定措施。

智能文件分發(fā)系統(tǒng)：蜻蜓

要做容器化，文件的分發(fā)尤其是鏡像的分發(fā)已經(jīng)變成了一個非常大的問題。

我們經(jīng)常在此過程中碰到這樣的問題：原本只需要傳一個包，現(xiàn)在要傳一個鏡像，但如果研發(fā)不太好，一出來就是一個多 G 的鏡像在分發(fā)，會導(dǎo)致網(wǎng)絡(luò)的堵塞。

在這樣的挑戰(zhàn)下，我們當(dāng)時就做了一個 P2P 的文件分發(fā)系統(tǒng)，非常好地解決了這樣的問題。

在上圖中，紅色部分就是傳統(tǒng)的文件分發(fā)方式，藍色部分是我們用蜻蜓做的一個文件分發(fā)系統(tǒng)。

其中，X 軸是客戶端的數(shù)量，最大程度是 7000 個客戶端同時下一個文件。不管有多少個客戶端，蜻蜓都可以非常平穩(wěn)，大概幾秒鐘就可以完成分發(fā)。

而傳統(tǒng)的分發(fā)，等到 1000 個客戶端時就已經(jīng)沒有數(shù)據(jù)了，因為它已經(jīng)被客戶端打爆了。

上圖列舉了一些場景，它在哪些地方能被用到，以及它的一些特性包括斷點續(xù)傳、智能網(wǎng)絡(luò)的 IO 和磁盤的 IO 等。

如何保證在下載過程中不影響到業(yè)務(wù)？不能把磁盤和網(wǎng)絡(luò)全部打掉，那么傳統(tǒng)的模式就是設(shè)定一個閾值。

我就占用 20m 或 50m，但很多業(yè)務(wù)可能在晚上，并沒有那么大的流量。你可以用更多帶寬，但用不起來；如果是業(yè)務(wù)特別忙的話，還是 20m 就影響到業(yè)務(wù)了。

我們做了一個智能化的點，如何在不影響業(yè)務(wù)的情況下，充分地利用帶寬和磁盤的 IO，跟鏡像相關(guān)的我們也做了很多的工作。這是去年 10 月份的一些數(shù)據(jù)，每個月有超過 20 億次的訪問。

它最初是在我們的發(fā)布系統(tǒng)里被用到，是一個基礎(chǔ)設(shè)施，后來我們推廣到了整個集團，現(xiàn)在訪問量非常之大。

這個系統(tǒng)目前已經(jīng)開源了，上圖有我們的協(xié)議地址，也有企業(yè)版的，商業(yè)化的版本里會有更多智能化功能。這個社區(qū)現(xiàn)在還比較小，希望大家能夠支持一下。

應(yīng)用運維平臺

前面講的基礎(chǔ)設(shè)施并不是所有公司都會用到，當(dāng)你的體量特別大時反而會成為一種累贅，相比之下，應(yīng)用運維平臺與大家的相關(guān)度可能會更密切一些。

我們的應(yīng)用運維平臺叫 Normandy，上面有很多業(yè)務(wù)線，我們至少 50% 以上的平臺都用這個來做運維。

它的一個主要功能是資源編排，應(yīng)用要用到的所有資源都可以用描述文件的形式做編排，并一次性生產(chǎn)出來，你的任何變化都會被系統(tǒng)感知到并去做一些變更。

有了資源以后，要做代碼的發(fā)布，這也是這個平臺非常大的一個功能。之前有人提到的藍綠部署，發(fā)布的模式我們都是支持的，并且有非常多的發(fā)布模式。

當(dāng)業(yè)務(wù)的代碼發(fā)布上去時，這個業(yè)務(wù)就在線了，后面的工作就是日常性的運維，比如說磁盤的清理等日常工作，也是在這個平臺上去做。

關(guān)于發(fā)布，我們也在做一些思考，因為運維的本質(zhì)就是為了線上的穩(wěn)定性。我們對所有故障做了分析，發(fā)現(xiàn) 60% 的故障都是由變更引起的。

而且行業(yè)內(nèi)也有一種說法是，80% 的故障可能都是由變更引起的。這也說明你不做變更，基本上是不太會發(fā)生故障的。

畢竟像之前發(fā)生的支付寶電纜被挖斷，以及騰訊的天津機房發(fā)生爆炸這類事情是比較少的，大多數(shù)情況下是因為變更造成的故障。

然而變更又是發(fā)布的一個重要環(huán)節(jié)，所以我們會發(fā)現(xiàn)，要讓系統(tǒng)穩(wěn)定、持續(xù)不斷地運行，只要能卡住變更這個口子，基本上就能降低非常多的故障。

我們?nèi)ツ觊_始做了一個無人值守的發(fā)布。因為不同的人看到的情況不一樣，可能經(jīng)驗老道的人會看出問題并做出維護。

但新同學(xué)怎么辦呢，又或者是老司機太老練了，以為不會有事結(jié)果卻出了問題。

所以我們希望整個過程沒有人力介入，通過各種參數(shù)的檢查來幫助我們發(fā)現(xiàn)變更過程中出現(xiàn)的問題。

關(guān)于這個發(fā)布，我們也做了很多工作，其中就有對監(jiān)控指標(biāo)進行分類，包括系統(tǒng)、日志、業(yè)務(wù)等，對各種指標(biāo)做檢查。

我們會檢查發(fā)布和沒發(fā)布的機器，以及發(fā)布的機器與前一天在各方面的一些對比，最后做出一個診斷。當(dāng)有問題時，就能及時通過手機、釘釘把消息推送出來。

可能現(xiàn)在你的系統(tǒng)發(fā)現(xiàn)了一些問題，要做一些人工判斷，因為這也是一種輸入，相當(dāng)于數(shù)據(jù)的標(biāo)注，判斷我這次的系統(tǒng)判斷到底準不準。如上圖所示，各種指標(biāo)會告訴你可能會有異常的，需要人工進行判斷。

這個策略還是比較簡單的，比如說一些針對 Java 的應(yīng)用，在你的日志里會發(fā)現(xiàn)很多問題。

譬如說有沒有新的異常，我們的異常庫會把新的異常記錄下來，如果發(fā)現(xiàn)了就會提醒用戶，因為這個新的異常基本就是代碼引入的。

還可能有一些是非常致命的新異常，不太需要算法的介入（需要算法介入的是舊的異常）。

譬如你的指標(biāo)頻率突然飆升，那我們要發(fā)現(xiàn)這個飆升的指標(biāo)，并把它提示出來，這就可以用很多方法了，包括趨勢、同比、環(huán)比等。

提到會用到的算法，紅色標(biāo)注的部分在整個序列上的算法會比較多，主要是對這個應(yīng)用進行一些歷史數(shù)據(jù)的采集，再描繪出它的曲線。

通過這樣的數(shù)據(jù)學(xué)習(xí)，我們就能知道它未來的發(fā)展趨勢和變化，如果超出了變化，就可以認為是異常。

上圖的紅色線就是我們真實輸入的數(shù)據(jù)，藍色線是我們預(yù)測的數(shù)據(jù)，如果是好的想法，這個紅色線應(yīng)該正好穿過藍色線。

而我們的監(jiān)控報警或是異常檢測，即根據(jù)紅色線是不是超過了藍色線的正負閾值來判斷。

我們也做了測試，把線上發(fā)生的各種異常（包括用戶認為是有問題或是認為報錯了）的數(shù)據(jù)都引入線下，幫助我們?nèi)プ鲞M一步的評判，形成一個反饋機制。

這整個過程都是自動化的，最后告訴我們調(diào)整的參數(shù)是否正常。這是我們自動化系統(tǒng)模塊的展示，此處就不詳細展開了。

另外，監(jiān)控系統(tǒng)的數(shù)據(jù)采集是不是有斷圖，數(shù)據(jù)采集得對不對、準不準等等，也是非常大的挑戰(zhàn)。

還有我們的參數(shù)目前更多地還是人為去做固定的閾值，如果能使其更加動態(tài)，或是根據(jù)不同的應(yīng)用狀態(tài)去做一些動態(tài)的適配，也是有著非常大的挑戰(zhàn)。

AIOps

今年我們主要的工作就是發(fā)布，讓所有變更都能接入智能化體系，從而保證變更不受影響。

它的 AI 是基于算法的這樣一套東西，我們更多是希望它走向無人化的狀態(tài)，所以我們對它的理解可能不是一個算法，而是另外一個英文單詞 AIOps，即無人化的運維。

這需要一個過程，首先我們需要累計足夠多的數(shù)據(jù)，其次是找到場景。開頭提到的無人駕駛飛船的想法是非常美好的，但要真的做到不需要任何人介入，需要走非常長的一段路。

所以我們現(xiàn)在認為，一定要找到非常好的場景作為落腳點，再準備好所有數(shù)據(jù)，因為數(shù)據(jù)的質(zhì)量真正決定了整套系統(tǒng)的天花板，而算法是可以不斷嘗試的。

我們嘗試用比較普通的算法來做運營，真正難的是特征的提醒和算法參數(shù)的優(yōu)化，甚至是一些革命性的算法現(xiàn)在還比較少。

關(guān)于這方面我們也和清華大學(xué)有一些合作，希望通過與高校的合作來看到一些更好的算法。

上圖是對整個運維領(lǐng)域和智能化階段做了一些分類。我們會有一些服務(wù)咨詢/答疑，這也是可以做智能化運維的方向。

我們現(xiàn)在更多的采用跟阿里的一些合作，在自然語言處理方面能幫助我們減少人工答疑的過程，尤其是重復(fù)性出現(xiàn)的問題。

比如我想看一下我的應(yīng)用在某一個機房到底運行得怎么樣，可以通過自然語言的方式去做，大大降低人的介入。

第二是通過智能化算法降低故障，包括效率和優(yōu)化。我們也有很多場景，包括剛才講的資源的利用率，如何能更好地做服務(wù)調(diào)度，這上面其實我們也有很多應(yīng)用。

另外一個就是在可用性上面，自愈或者是預(yù)測。我們在做磁盤損壞的預(yù)測，在損壞前能夠把業(yè)務(wù)都調(diào)走，讓整個過程變得更加可預(yù)期一些。

還有一個方面，我們也在做整個機房在能耗方面的工作，能夠通過智能化的算法來降低能耗。

谷歌在 2016 年就已經(jīng)做到了，通過深度學(xué)習(xí)的方法讓整個能耗降低了差不多 30%。不過真正要達到第五級的自動駕駛的話，還是有挺長的路要走。

上圖是我們在智能化運維上主要做的兩個方面。第一個就是我們對運維的理解，穩(wěn)定性是最核心要做的事情。

在此基礎(chǔ)上，我們希望整個系統(tǒng)達到非常優(yōu)化的狀態(tài)，包括前面講的我們的自動化的調(diào)整，讓性能更加高效。

上圖是我們整個智能化運維平臺的產(chǎn)品圖，包括了前面說的應(yīng)用運維上的能力，以及整個端上的一些東西，還有我們的一些規(guī)范、運維的一些紅線等等。

這個平臺我們叫 StarOps，有一個私有云版本，也會在今年六七月份推出公有云版本。

最后是我們的一些思考：

• 度量是非常關(guān)鍵的，不僅僅是運維，所有的系統(tǒng)都應(yīng)該有度量，沒有度量就不會有提高。
• 從中臺的概念來講，希望不要重復(fù)去造低水平的輪子，一定要有突破。
• 對于智能化運維這一塊，還是可以從點入手，找到一個真實的場景，然后去做一些突破。

[[232766]]

如柏(毛茂德)，阿里巴巴高級技術(shù)專家，Apache 頂級項目 CXF 初創(chuàng)成員之一，阿里集團基礎(chǔ)架構(gòu)事業(yè)群運維中臺負責(zé)人、親歷者。