差不多在兩年前，阿里內部出現了很多運維中臺、研發中臺等等，那有沒有后臺呢？不好意思，我們只有中臺，沒有后臺，會在中臺上構建與業務相關的各個前臺。

[[232760]]

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

我們需要去構建整個集團、或是阿里巴巴經濟體所需要的統一的平臺，避免重復性的建設。

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

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

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

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

這和我們現在做的運維系統是一樣的。我認為運維的本質就是在線，即如何讓這種在線的業務能持續不斷地運行，滿足客戶的需求。

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

而隨著業務復雜度越來越高，已經沒有辦法靠人來運維整個平臺和業務了?？梢栽囅?，如果要靠人，那需要投入多少人力？

當發生問題時，我們人為地去感知問題后排查問題、定位問題，這時業務可能已經掛了很長時間。

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

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

• 阿里運維歷程
• 基礎運維平臺
• 應用運維平臺
• AIOps

阿里運維歷程

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

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

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

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

而在近幾年，阿里云發展起來了，等到更加成熟了就會把這個業務往云上搬。

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

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

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

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

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

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

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

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

網絡則是另一個專業領域的東西，我們需要去監控整個網絡、交換機，讓網絡處于一個健康的狀況。

再次，還需要有服務器層面的監控，應用、業務層面的監控等，所有的這些都是不一樣的，屬于不同領域，因此我們的監控系統也比較多。

再往上就是運維最核心的本質——穩定性了，我認為這是怎么強調都不為過的。

我們的很多業務部門都有一個專門做穩定性的團隊，覆蓋從業務到技術的環境。

而像阿里這種體量的公司，規?；潜夭豢缮俚?，我們現在正在收購很多公司，那怎么讓這些公司的運維體系能一次性快速便捷地搬遷進來，利用到我們中臺的能力？

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

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

基礎運維平臺

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

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

運維通道：StarAgent

StarAgent 就是阿里運維的基礎設施，它是一個運維通道，是基礎設施中最核心的功能，主要是做命令的下發與執行。

所有阿里的運維進程都在這上面，包括監控系統、調度所需的所有東西、數據采集等。信息的采集都在這個平臺上，以插件的形式運行。

這個系統一天差不多有一個多億的訪問量且還在不斷增長，因為我們的服務器數量在不斷增長，業務的數量也在不斷增長，但它的穩定性還是達到了 99.995%

場景

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

核心功能

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

系統架構

這個系統是由三層架構搭建而成的，第一層就是我們中央的一層東西，用戶如何訪問這個？

我們會通過用戶的 API 做調用，如果權限足夠大，可以給全網所有的機器下發指令。

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

還有末端的，就是一個插件的結構，大概如上圖所示，會把信息全部都上報上來等等，這個也是能夠支持網絡結構的。

穩定性

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

當監控系統掛掉之后，監控錄像或其他都有可能出現問題，會出現循環依賴。

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

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

安全

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

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

自動化運維

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

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

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

插件平臺

[[232762]]

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

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

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

這個系統本質上是保障服務器的穩定性，所以不管發生什么情況，我們要把服務器上的所有命令都管控起來，只要有問題就采取一定措施。

智能文件分發系統：蜻蜓

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

我們經常在此過程中碰到這樣的問題：原本只需要傳一個包，現在要傳一個鏡像，但如果研發不太好，一出來就是一個多 G 的鏡像在分發，會導致網絡的堵塞。

在這樣的挑戰下，我們當時就做了一個 P2P 的文件分發系統，非常好地解決了這樣的問題。

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

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

而傳統的分發，等到 1000 個客戶端時就已經沒有數據了，因為它已經被客戶端打爆了。

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

如何保證在下載過程中不影響到業務？不能把磁盤和網絡全部打掉，那么傳統的模式就是設定一個閾值。

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

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

它最初是在我們的發布系統里被用到，是一個基礎設施，后來我們推廣到了整個集團，現在訪問量非常之大。

這個系統目前已經開源了，上圖有我們的協議地址，也有企業版的，商業化的版本里會有更多智能化功能。這個社區現在還比較小，希望大家能夠支持一下。

應用運維平臺

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

我們的應用運維平臺叫 Normandy，上面有很多業務線，我們至少 50% 以上的平臺都用這個來做運維。

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

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

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

關于發布，我們也在做一些思考，因為運維的本質就是為了線上的穩定性。我們對所有故障做了分析，發現 60% 的故障都是由變更引起的。

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

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

然而變更又是發布的一個重要環節，所以我們會發現，要讓系統穩定、持續不斷地運行，只要能卡住變更這個口子，基本上就能降低非常多的故障。

我們去年開始做了一個無人值守的發布。因為不同的人看到的情況不一樣，可能經驗老道的人會看出問題并做出維護。

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

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

關于這個發布，我們也做了很多工作，其中就有對監控指標進行分類，包括系統、日志、業務等，對各種指標做檢查。

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

可能現在你的系統發現了一些問題，要做一些人工判斷，因為這也是一種輸入，相當于數據的標注，判斷我這次的系統判斷到底準不準。如上圖所示，各種指標會告訴你可能會有異常的，需要人工進行判斷。

這個策略還是比較簡單的，比如說一些針對 Java 的應用，在你的日志里會發現很多問題。

譬如說有沒有新的異常，我們的異常庫會把新的異常記錄下來，如果發現了就會提醒用戶，因為這個新的異?；揪褪谴a引入的。

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

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

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

通過這樣的數據學習，我們就能知道它未來的發展趨勢和變化，如果超出了變化，就可以認為是異常。

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

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

我們也做了測試，把線上發生的各種異常（包括用戶認為是有問題或是認為報錯了）的數據都引入線下，幫助我們去做進一步的評判，形成一個反饋機制。

這整個過程都是自動化的，最后告訴我們調整的參數是否正常。這是我們自動化系統模塊的展示，此處就不詳細展開了。

另外，監控系統的數據采集是不是有斷圖，數據采集得對不對、準不準等等，也是非常大的挑戰。

還有我們的參數目前更多地還是人為去做固定的閾值，如果能使其更加動態，或是根據不同的應用狀態去做一些動態的適配，也是有著非常大的挑戰。

AIOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在此基礎上，我們希望整個系統達到非常優化的狀態，包括前面講的我們的自動化的調整，讓性能更加高效。

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

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

最后是我們的一些思考：

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

[[232766]]

如柏(毛茂德)，阿里巴巴高級技術專家，Apache 頂級項目 CXF 初創成員之一，阿里集團基礎架構事業群運維中臺負責人、親歷者。