阿裏巴巴運維中台的演進與建設
作者簡介：
前言毛茂德
阿裏巴巴 基礎架構事業群運維中台負責人
花名如柏，現任阿裏巴巴集團基礎架構事業群－運維中台負責人， 主導架構設計高可靠、高並發、大規模的基礎運維平台和應用運維平台, 致力於打造行業級的基礎運維無人值守解決方案以及數據化、智能化運維解決方案，推動 DevOps 生態。
本文來自於 GOPS 2017 深圳站的演講“阿裏巴巴運維中台的演進與建設”。
一、運維基礎平台——StarAgent我所在的部門是阿裏基礎架構事業群，負責阿裏巴巴的 IDC 建設、網絡建設、基礎數據庫的運維，大數據運維，研發協同，應用運維等等都在我們這個部門裏面。
我的團隊主要負責運維平台和工具的建設，旨在提升業務交付的效率和運維的自動化、智能化。在去年我們團隊名字改成了“運維中台”，名字的改變很重要，他讓我們的定位更加清晰，做事更聚焦和專注。
運維平台建設已經很多年，產品比較多，下面我將介紹幾個比較重要的產品來呈現阿裏運維中台建設的過程。
StarAgent 在阿裏已經有五六年，甚至更早的時間。阿裏所有的物理機、虛擬機以及容器都會裝這個 agent，StarAgent 是管理所有 agent 的系統，基本上要和機器交互都需要通過這個平台。
StarAgent 是一個生態平台，實際上不會做具體的業務，具體的業務還是通過各個業務平台去實現的。它們要和服務器進行交互必須通過我們這個平台。
例如，應用運維平台——諾曼底也是通過 StarAgent 在機器上進行部署發布的。我們希望將 StarAgent 建設成一個平台，而不是所有的業務都是我們來做的。
平台化的項目是2015年底啟動的，在此之前機器上運行的 agent 所有的功能整個打包成一個可執行的程序，這導致了研發迭代速度非常緩慢，問題非常多。
我們曾經有一個功能花了一個多月時間開發了一個功能，開始上線，全網做灰度，將近一個時間等快灰度結束的時候，突然發現某些環境下這個功能有 bug，結果又用了一個月的時間回滾。
這個對我們士氣是非常傷的，叁個月過去了什麼業務結果都沒拿到。
平台化的改造中，我們把各個業務的功能都變成一個個插件，可以插到這個平台上來。平台只負責最基本的插件維護的功能，以及命令執行的功能，僅此而已。監控、日志采集等功能都變成插件，而不需要都打包在一起。
目前我們平台上已經有了將近90個插件，比如說監控、日志、安全、調度、采集、P2P 文件分發、配置管理類似 puppet， saltstack 等等插件。
而且平台化之前我們必須全網發布，插件化之後，我們可以選擇插件的發布范圍，開發迭代的速度也有了大幅度提升。
平台化之前整個 agent 都需要放到裝機鏡像裏，裝機鏡像測試也需要一個月時間，所以更新鏡像也非常繁瑣.
平台化之後裝機鏡像裏也只要裝基本的 agent core 就可以了，核心插件都可以裝機後第一次啟動時自動更新即可，這樣也不需要頻繁的更新裝機鏡像，core 的功能因為非常純粹簡單，core 穩定之後，更新的頻率自然就低到了極致。
StarAgent 平台化之後的架構比較簡單，整個 agent 最核心的東西就是管理和運行這些插件，基於一個非常簡單的交互協議與插件通訊。只要實現這些接口就可以作為一個插件讓 agent 幫你去運維。
所以除了之前 StarAgent 的功能插件化外，我們收斂了機器上眾多的 agent，在這之前插件都是自己做一個運維系統，要管理自己的狀態，要進行版本的更新和迭代。
現在在統一的平台上統一的進行管理、統一做變更的升級。除了節省運維資源外，同時也能收斂重複功能的 agent，從另外一個角度保證了服務器運維的安全。
1.1 StarAgent核心功能
StarAgent 核心功能就是一個命令的通道，它既可以同步執行任務又可以異步執行任務，還可以查詢任務狀態和插件管理。插件分為兩種，一種是靜態的，靜態的實際上就是腳本、命令之類的。
另一種動態的是一個常駐進程，必須常駐在系統裏面。我們會守護這個進程，如果它掛了會重新拉起來，如果其占用內存、CPU 超過設定的范圍會刪掉它。整個協議是比較簡單的，使用起來耦合度也是比較低的。
1.2 StarAgent特性
StarAgent 系統從功能上來講是比較簡單的，我們其實是花了大量時間在做一些非功能上的東西。
例如，高可用、高並發、安全，還有自運維能力，即使是百萬級服務器的場景下，我們的運維人力投入可能幾乎為0，我們追求的就是無人值守的運維。
目前這套系統的執行成功率差不多有 99.995% 左右，由於執行量非常大，0.005% 失敗率的運維成本還是挺高的。我們花了大量的時間做容災和自恢複的工作。
前兩年支付寶官網癱瘓，經過這個事件我們開始做容災的演練。把網線拔了，看所有系統的反應，過兩個小時再把網線插上去，看這個系統是不是能自動恢複。
以前我們都是半夜叁點起來去重啟服務器，經過自動化的運維，所有的系統斷網都可以自動恢複、服務器可以自動進行擴容，保證系統持續的可用性。
1.3 StarAgent 場景
現在的場景會貫穿整個物理機的生命周期，阿裏巴巴在物理機裝機的過程中就會用到 StarAgent，從生產到下線整個過程都離不開。
應用運維方面，我們在做重啟、發布恢複等等，同時還有監控、數據采集及數據庫等方面。
StarAgent 是叁層的架構，中央的一層，第二層是每個機房都有管控服務器，最下面一層就是每台服務器安裝的 agent 及其插件。
agent 會先注冊到管控服務器然後上報自己的信息並且每隔一段時間上報自己的心跳。命令是從上往下的，是通過 API 去下發的。
例如，下發一萬台服務器執行命令，所有的命令都是同樣的中央服務器，所以它是中央式的架構。
阿裏現在有很多走國際化，在俄羅斯、美國、印尼等地收購很多公司，它們的機房也需要我們做運維。目前我們在做的就是去單中心走向多中心的架構。
比如說，在印度尼西亞的一個機房還需要回到中央服務器來再下發，這個路徑會非常曲折，我們需要做個多組型。
1.4 StarAgent 指標 目前內部訪問量每天在一億多次，但是阿裏的服務器還在不斷增長，而且隨著阿裏雲的業務逐步擴大，以及阿裏本身業務的不斷壯大，我們不得不提前考慮未來叁年的發展會不會成為瓶頸。 所以去年我們花了半年的時間在架構上做了比較大的升級，目前集群的 QPS 已經達到55萬次/分鍾，這個量實際上已經差不多可以支撐未來3年服務器的發展和業務的發展。在國外的我們會多布一個中心，這樣的話在單元內可以自制，不需要跑到杭州或上海來再下發到國外機房。
以前這些數據都沒有，我覺得做運維系統需要把度量這個事情做起來。
在架構裏面有句話叫沒有度量就沒有改善，度量是非常重要的。如果產品的核心指標（穩定性、性能、內存占用等）沒有定出來，或者無法度量，怎樣去架構和優化系統就比較困難，無從下手。
產品的亮點、競爭力、差異性也無從談起。
實際上系統穩定性以前根本就沒有。一個系統指令發過去了就告訴你失敗了，不知道什麼原因，根本沒有錯誤的分類。然後一堆人開始查問題，查半天發現這台機器磁盤滿了。
對於這種方式，我們覺得是不可持續的。我們需要從日志和標准化等方面一定要說清楚系統本身到底有沒有問題。
對於第叁方依賴，可能是數據庫、也可能是一個配置等等，一定要搞清楚第叁方依賴的穩定性到底怎麼樣。對於環境的問題，網絡是不是斷了，磁盤是不是滿了。
這些也都需要在錯誤碼日志裏面體現出來，這樣才能從各個方面逐步完善系統的指標，否則是沒有辦法完成的。系統的穩定性非常重要，有了這些數據，系統就可以進行數據化運維。
1.5 StarAgent 插件系統
StarAgent 插件系統，協議很簡單。可實現啟動、停止，配置如何重新加載等。我們對 CPU 會做一些守護，同時會做一些一鍵部署的事情。
原來我們升級插件是非常多的，服務器數據很大，再加上插件數量和插件各種版本，這個量是非常巨大的。
以前全網升級插件差不多要六個小時，經過優化之後現在大約10分鍾就可以了。
二、文件分發系統——蜻蜓
對於全網都需要用到的，這些就不是一個個性化的需求，這些這插件是我們自己來開發。比如蜻蜓（P2P文件分發系統）就是我們自己開發的。
文件分發其實是我們做部署系統的優化時候去做的，當時比較糾結，是自己開發還是用現成的系統。我們對比了業界很多類似的技術。
比如 Facebook 的 wdt (https://github.com/facebook/wdt)，Twitter 的 ( https://github.com/lg/murder )，百度的 Ginko 等等，還有包括亞馬遜 Apollo 裏面的文件分發系統，它們那個和我們的有點不太一樣，他們的是基於 S3 做的。
我們發現他們各自或多或少的都有些問題，無法滿足我們多種場景下應用需求。這個產品可以不誇張的說已經做到行業第一。
蜻蜓系統是純碎的 P2P 的文件分發系統。在做 Docker 過程中，如果沒有系統解決這些問題，整個 Docker 化的進程就會受到影響。當到了一定量以後根本就支撐不了，所以直接把鏡像倉庫的協議全部都實現了一遍。
2.1 蜻蜓核心功能
P2P 的文件分發我們做了很多特性，包括多線程下載、一致性校驗以及白名單控制等。
有些業務對磁盤是非常敏感的，例如搜索類的業務，所以會要求在寫這個智能 IO 的時候會有些控制，我們會把這個參數調出來通過這個參數對磁盤進行管理。
一個 200M 的文件在傳輸的時候會變得比較小，網絡和傳輸速度都會得到優化。
2.2 蜻蜓業務指標
蜻蜓系統目前是一萬個客戶端同時下載 500M 的文件平均耗時 5s。阿裏集團大部分的文件分發都統一用了這套系統。下載次數是 12萬/月到 3億/月。系統穩定性達6個9。也是自運維的系統。
使用蜻蜓系統和不用該系統進行對比可知，這個模式下載速度會快很多而且不會隨著並發數量上升而嚴重延時。
叁、應用運維平台——Normandy
Normandy 是運維整個阿裏巴巴業務的 PaaS 平台。這個平台實際上提供叁大功能，分別是基礎設施即代碼（Infrastructure as Code）、部署和應用運維支撐。
我們希望能夠通過代碼描述文件的形式把一個應用需要用到的所有資源，包括機載資源、服務器、網絡還有數據庫等都描述出來，這樣就可以能夠快速構建一個應用。
應用已經有了，如何把代碼部署到線上，讓其能夠對外提供服務，這就需要部署發布了。在發布部署方面我們做了無人監守的發布，我們和中間件等部分做了整合，只要代碼沒有出現線上的故障就可以自動發完。
如果出現故障發布就會停下來，此時需要人介入去判斷要不要作維穩。亞馬遜的發布系統阿波羅，一年的發布量差不多是五千萬，據說現在一天的發布量已經能達到50萬。
去年在這方面我們也做了很多工作，至少說這個發布系統不會因為業務發布次數比較大導致發布系統掛掉。
另外，現在整套系統已經將阿裏巴巴的測試環境和線上環境全部打通，解決了線上系統和測試不統一的情況。
目前業務方有很多的平台使用應用運維平台和運維基礎平台 StarAgent。從應用數量上來講，實際上也是最多的，大概 80% 的應用都基本集中在交易。
阿裏雲稍微有點特殊，有一半對 ECS 的運維，ECS 也是要做發布與運維，ECS 今年努力的方向要盡量做到不影響用戶。
以上的產品都是服務於整個阿裏巴巴集團的，這些服務都是最基礎的，我們的核心能力基本都是通用的，不帶業務的特殊性，特殊性的功能可以在我們的平台化上進行擴展。
這就是中台的原義，中台的好處就是讓業務能根據自己的特性在中台上快速的發展，而不需要一杆子桶到最底層，同時中台也沒有能力去幫助每個業務去實現所有的特性功能。
這個是整個做事方式的轉變，每層都想清楚自己的核心能力，做什麼，不做什麼同樣重要。
在滿足了集團業務運維的同時，我們這些產品也真正的在打磨極致產品特性，極致的穩定性、極致的性能、極致的體驗。
這樣能提升產品的競爭力，拉高進入門檻，光是一堆運維功能堆砌的產品是咩有靈魂的，也非常容易被複制。
我們的產品在今年就會完成單元化，國際化，雲化，希望能成為雲上有競爭力的運維產品。
