摘要：DevOps 的概念提出接近10年了芋绸，提升協(xié)作效率，降低開發(fā)成本担敌，更穩(wěn)健可持續(xù)的業(yè)務(wù)運營是DevOps的主旋律摔敛。阿里巴巴是如何開展DevOps的？ 阿里集團基礎(chǔ)架構(gòu)事業(yè)群運維中臺負(fù)責(zé)人如柏全封，在2017杭州云棲大會上马昙，詳細(xì)介紹了阿里運維體系的演進和在智能化運維方面的工作，希望能給大家?guī)硪恍﹩l(fā)和借鑒刹悴。

DevOps 的概念提出接近10年了行楞，提升協(xié)作效率，降低開發(fā)成本土匀，更穩(wěn)健可持續(xù)的業(yè)務(wù)運營是DevOps的主旋律子房。阿里巴巴是如何開展DevOps的？ 阿里集團基礎(chǔ)架構(gòu)事業(yè)群運維中臺負(fù)責(zé)人如柏，在2017杭州云棲大會上池颈，詳細(xì)介紹了阿里運維體系的演進和在智能化運維方面的工作尾序，希望能給大家?guī)硪恍﹩l(fā)和借鑒。

阿里巴巴是怎么看運維的躯砰？

阿里大致也是經(jīng)歷了這么幾個階段：從最開始的人肉運維每币， 到簡單的工具、自動化琢歇， 到系統(tǒng)化和平臺的過程兰怠， 自動化到一定程度后，開始探索智能化李茫，無人化運維這些領(lǐng)域揭保， 并在阿里的多個運維系統(tǒng)里有所沉淀。

在這個演進過程中魄宏，我們始終秉承一種原則秸侣， 能用機器去做的就不要讓人去做，自動化一切可以自動化的宠互。很多簡單重復(fù)的日常運維操作味榛，開始由研發(fā)通過運維平臺來完成。

上圖是阿里對運維領(lǐng)域的大致分層予跌。每個層都會有不同平臺/系統(tǒng)來承載搏色，運維團隊整體上會幫助業(yè)務(wù)團隊搞定資源，實現(xiàn)高可用的架構(gòu)券册，資源成本優(yōu)化等問題频轿。有了資源，業(yè)務(wù)就可以部署代碼烁焙，對外提供服務(wù)航邢， 代碼上線后會有各種運行時的變更操作， 當(dāng)然也會有橫向的運維操作骄蝇， 比如操作系統(tǒng)更新翠忠，網(wǎng)絡(luò)升級，DNS乞榨，IP等等變更操作秽之。監(jiān)控也是分層的，橫向的有服務(wù)器的監(jiān)控吃既，網(wǎng)絡(luò)監(jiān)控考榨， IDC監(jiān)控， 縱向來看鹦倚， 有面向業(yè)務(wù)的監(jiān)控河质，確保系統(tǒng)的各種異常能被檢測到，并及時提供多種途徑的報警。當(dāng)業(yè)務(wù)真的發(fā)生故障時掀鹅，我們也有系統(tǒng)需要能及時的恢復(fù)故障散休，定位故障，甚至能故障自愈乐尊，故障預(yù)測等戚丸。

針對雙11這樣的大型活動，我們會做大規(guī)模全鏈路的壓測模擬扔嵌，來發(fā)現(xiàn)各種系統(tǒng)異常限府，為大促做好充分準(zhǔn)備。我們也有定期的故障演練系統(tǒng)痢缎，來不斷提升故障恢復(fù)速度胁勺。橫向，縱向之外独旷，我們還有規(guī)氖鹚耄化的運維，這個在大促和業(yè)務(wù)快速擴張時非常有用嵌洼。

運維是很大的一個概念案疲，里面有很多專業(yè)，這5個能力層次每一層就有很多產(chǎn)品組成咱台。從云效2.0-智能化運維平臺（以下簡稱：StarOps）產(chǎn)品的角度來看络拌， 我們可以劃分為兩個平臺俭驮，基礎(chǔ)運維平臺和應(yīng)用運維平臺回溺。基礎(chǔ)運維平臺是統(tǒng)一的混萝，在阿里有且只有一個遗遵，內(nèi)部叫StarAgent。但是應(yīng)用類型比較多逸嘀，每個業(yè)務(wù)都有特殊性车要，所以允許除了通用的“應(yīng)用運維平臺”外，有多個面向業(yè)務(wù)的特色的“應(yīng)用運維平臺”崭倘，但也都是構(gòu)建在通用的“應(yīng)用運維平臺”之上翼岁，內(nèi)部叫Normandy。

StarOps當(dāng)然不會包含所有的運維能力司光。但對于互聯(lián)網(wǎng)企業(yè)或者傳統(tǒng)企業(yè)+互聯(lián)網(wǎng)的場景琅坡，大部分公司需要的是運維能力，StarOps會全部包含残家，主要集中在基礎(chǔ)運維能力(服務(wù)器管理)到應(yīng)用運維能力(PaaS平臺)上榆俺。而且可以根據(jù)用戶自身的需求來自定義選擇。兩個平臺本身也具備擴展能力，可以根據(jù)我們的SDK來擴展企業(yè)自身的業(yè)務(wù)特色茴晋。

除了運維平臺本身外陪捷，還包含軟性的一些運維規(guī)范，故障治理的原則等诺擅。另外市袖，我們在智能化運維方面已經(jīng)有了實踐， 通過算法平臺融入到了兩個平臺的能力上掀虎。在界面上凌盯，我們提供Web， API烹玉，命令行工具驰怎，手機客戶端，甚至提供大屏產(chǎn)品二打。

基礎(chǔ)運維平臺

基礎(chǔ)運維平臺可以說是IT運維的基礎(chǔ)設(shè)施县忌， 阿里非常重視運維基礎(chǔ)設(shè)施的建設(shè)，這個系統(tǒng)是對眾多運維系統(tǒng)共性部分的抽象继效，對上層的運維業(yè)務(wù)建設(shè)至關(guān)重要症杏。 在前面提到的5個運維能力層次中的所有系統(tǒng)都要依賴他， 所以重要性也尤其突出瑞信±鞑基礎(chǔ)運維平臺主要功能是服務(wù)器訪問的通道（命令通道、文件通道凡简、數(shù)據(jù)通道）逼友，職責(zé)是維護企業(yè)所有服務(wù)器訪問的安全，這里的服務(wù)器包括物理機秤涩、虛擬機和容器帜乞。

StarOps產(chǎn)品里主要包含有三大系統(tǒng)：1.堡壘機 2.StarAgent 3. 蜻蜓

堡壘機

堡壘機，也可以叫跳板機筐眷， 是服務(wù)器訪問的一道屏障黎烈。阿里的堡壘機是全球部署的，具備統(tǒng)一的賬號/權(quán)限/密鑰等管理匀谣，訪問控制照棋，高危攔截，操作錄屏等功能武翎， 最高可以承載5000人同時在線烈炭， 并通過了ISO27001等認(rèn)證。

StarAgent

StarOps套件中的基礎(chǔ)運維平臺后频，就是在阿里巴巴運維多年實踐上沉淀的結(jié)果梳庆。這個產(chǎn)品的名字叫StarAgnet暖途，它可以當(dāng)之無愧的說是阿里巴巴IT運維的基礎(chǔ)設(shè)施。

從1萬服務(wù)器發(fā)展到10萬臺膏执，又逐步達到百萬級服務(wù)器驻售，基礎(chǔ)設(shè)施重要性并不是一開始就被意識到的，是逐漸被發(fā)現(xiàn)的過程更米。無論是運維系統(tǒng)穩(wěn)定性欺栗、性能、容量顯然已經(jīng)無法滿足服務(wù)器數(shù)量和業(yè)務(wù)的快速增長征峦。在2015年我們做了架構(gòu)升級迟几，StarAgent日均的訪問量從1000萬提升到了1億多，系統(tǒng)穩(wěn)定性從90%提升到了99.995%栏笆。

穩(wěn)定性另外體現(xiàn)在高可用上类腮，我們內(nèi)部有定期的斷網(wǎng)演練，任何一個機房網(wǎng)絡(luò)斷掉蛉加，自身服務(wù)終止影響面都控制在一定范圍蚜枢，都不會對整體的穩(wěn)定性產(chǎn)生影響， 只要網(wǎng)絡(luò)针饥、服務(wù)恢復(fù)厂抽，受影響的集群就自動恢復(fù)。這種演練在內(nèi)部是常態(tài)進行的丁眼，保證我們每個版本的代碼都保持健壯筷凤。

StarAgent 是安全的，我們有非常多的安全策略苞七，比如命令執(zhí)行的范圍控制藐守，賬號控制，白名單莽鸭、黑名單控制吗伤，高危命令審計/攔截吃靠，全鏈路加密簽名等硫眨，在阿里內(nèi)部安全部有定期的攻防演練，StarAgent無疑就是演練重點巢块。

在阿里內(nèi)部如果說運維效率比較高礁阁，原因之一就是我們的StarAgent基本上統(tǒng)一了運維的通道，任何BU任何系統(tǒng)都不會擅自也不允許去建設(shè)自己的通道族奢，統(tǒng)一的好處就是可以統(tǒng)一監(jiān)管姥闭，同時也減少了不必要的重復(fù)建設(shè)。每個業(yè)務(wù)運維系統(tǒng)只要建設(shè)自己的業(yè)務(wù)即可越走。

剛才提到了基礎(chǔ)設(shè)施影響面比較大棚品，所以在建設(shè)的時候必須有預(yù)見性靠欢，在性能方面我也對未來5年服務(wù)器和業(yè)務(wù)的增長作出了預(yù)估，使我們的這次架構(gòu)升級至少5年內(nèi)不需要再次重構(gòu)铜跑， 我們可以在此架構(gòu)之上構(gòu)建更多的業(yè)務(wù)门怪，不會讓穩(wěn)定性和性能羈絆運維業(yè)務(wù)的發(fā)展。目前StarAgent可以滿足每分鐘55萬次調(diào)用锅纺，幾乎對外部系統(tǒng)沒有強依賴掷空，數(shù)據(jù)庫、緩存即使失敗也不會對系統(tǒng)造成非常重大的影響囤锉。

StarAgent的架構(gòu)是靈活的坦弟，新的架構(gòu)是基于插件的模式，插件可以是靜態(tài)的(腳本官地、命令)酿傍，也可以是動態(tài)的(后臺服務(wù))，Agent Core 會保證這些插件執(zhí)行的安全驱入，同時又保證在一定的資源消耗之內(nèi)拧粪， 否則就會殺掉(重啟)這個插件進程，插件的開發(fā)者當(dāng)然會收到消息沧侥。插件的使用者可以決定在自己的機器上(業(yè)務(wù)范圍內(nèi))運行哪些插件可霎，或者停用哪些插件，以及插件需要的版本宴杀，默認(rèn)情況下插件的版本會自動更新癣朗。默認(rèn)的插件當(dāng)然是平臺來維護的， 目前在阿里內(nèi)部我們已經(jīng)有了150多個插件旺罢，其中包括監(jiān)控旷余、日志服務(wù)、調(diào)度扁达、文件分發(fā)等正卧。每個插件都可以看作是一個運維系統(tǒng)，而StarAgent的職責(zé)就是守護這些運維系統(tǒng)的執(zhí)行跪解，保證全集團服務(wù)器和業(yè)務(wù)的安全運行炉旷。

插件的模式同時也簡化了Agent本身的運維，Agent Core 是沒有任何業(yè)務(wù)屬性的叉讥， 職責(zé)清晰簡單窘行，只做插件的維護和必要的自運維， 所以在版本穩(wěn)定后图仓，基本上不需要太頻繁的更新罐盔， 這也符合裝機鏡像3個月更新一次的頻率。

對于一個運維百萬級服務(wù)器的基礎(chǔ)平臺救崔，本身的運維負(fù)擔(dān)也是比較重的惶看，以前至少需要3個專職的運維捏顺，尤其是阿里的網(wǎng)絡(luò)、服務(wù)器環(huán)境比較復(fù)雜纬黎，每天答疑工作也不少草丧。但很多工作其實可以總結(jié)出規(guī)律，提煉抽象莹桅，讓機器去做昌执， 所以目前新版的StarAgent自運維能力已經(jīng)達到95%，不再需要專職的運維了诈泼。

蜻蜓

蜻蜓是基于P2P的文件分發(fā)系統(tǒng)懂拾，不管是什么類型的業(yè)務(wù)運維都需要文件分發(fā)，所以也是基礎(chǔ)設(shè)施之一铐达。它的好處是保護數(shù)據(jù)源岖赋，加速分發(fā)速度，節(jié)約跨IDC和跨國的帶寬瓮孙。

下圖是一個500MB文件分發(fā)的對比測試唐断，X軸是客戶端數(shù)量，Y軸是分發(fā)時長杭抠，可以看出傳統(tǒng)的文件分發(fā)系統(tǒng)隨著客戶端數(shù)量的增加脸甘，時長就會增加，而且到1200客戶端后就沒有數(shù)據(jù)了偏灿， 因為數(shù)據(jù)源已經(jīng)被打爆丹诀， 在該測試中蜻蜓可以完美的支持到7000客戶端，分發(fā)時長基本保持在10秒左右翁垂。

在阿里內(nèi)部铆遭，典型的應(yīng)用場景包括：軟件安裝包、配置文件沿猜、數(shù)據(jù)文件枚荣、靜態(tài)文件、鏡像等啼肩。鏡像包括了物理機鏡像橄妆、虛擬機鏡像、容器鏡像疟游。對于容器可以支持Docker呼畸，Pouch(阿里自研的容器技術(shù))痕支，Hyper等颁虐。架構(gòu)上非常靈活，沒有侵入性卧须，不需要對容器技術(shù)做任何改造另绩。

高級的功能特性還包括斷點續(xù)傳儒陨、智能網(wǎng)絡(luò)流控、智能磁盤流控笋籽、動態(tài)壓縮蹦漠、鏡像預(yù)熱等。

在阿里內(nèi)部這個系統(tǒng)的業(yè)務(wù)覆蓋率在95%以上车海，月均分發(fā)量達到了15億次笛园，容量達到3000TB以上。蜻蜓同時也是雙11背后的支撐技術(shù)侍芝，在雙11前研铆，需要完成15GB的數(shù)據(jù)文件分發(fā)到超過1萬臺服務(wù)器上。

應(yīng)用運維平臺

StarOps套件中另一個是應(yīng)用運維平臺州叠，是架構(gòu)在基礎(chǔ)平臺之上的混合云PaaS平臺棵红，在內(nèi)部我們叫Normandy。

應(yīng)用運維平臺總體上來說是有三大組成部分： 資源管理咧栗、發(fā)布部署逆甜、日常運維。

一個應(yīng)用要正常運行致板，需要資源交煞，資源不僅僅是服務(wù)器（物理機、虛擬機斟或、容器）错敢， 還包括網(wǎng)絡(luò)（VIP、SLB缕粹、DNS等）稚茅，存儲，數(shù)據(jù)庫平斩，中間件等亚享，凡是一個應(yīng)用正常運行需要的所有的物理資源和服務(wù)資源都包括。

Normandy是通過資源編排實現(xiàn)資源的provision(生產(chǎn))的绘面，通常也被叫做Infrastructure as Code欺税。通過代碼的形式將一個應(yīng)用需要的所有的物理資源和服務(wù)資源，以及他們之間的關(guān)系都編寫在一段類JSON的代碼里揭璃， 并保存在CMDB中晚凿，而且是版本化的， 也就是說資源的任何一次變更改動都會被記錄在案瘦馍。 這也就形成了用戶(通常就是應(yīng)用的研發(fā))對應(yīng)用部署的基礎(chǔ)架構(gòu)(infrastrucure)的基本需求或者定義歼秽。

Normandy對于資源的需求和資源實際情況(通常稱為資源實例Instance)會做對比(difference)，如果資源實例和資源的用戶的定義不同情组，則會觸發(fā)資源的生產(chǎn)(provision)直到資源的需求被滿足燥筷。這也可以被稱為自動化的資源生產(chǎn)箩祥，也可以被稱為資源管理的自愈。如果僅僅就服務(wù)器來說肆氓，它的功能和Kubernates的ReplicaController是一致的袍祖。

既然是混合云PaaS平臺當(dāng)然是支持企業(yè)內(nèi)部IDC的同時也支持阿里云，所以應(yīng)用可以是部署在自有IDC也可以部署在阿里云谢揪，也可以一部分在自有IDC蕉陋，一部分在阿里云上。

混合的模式適合那種初步嘗試公有云的企業(yè)拨扶， 也適合那種在個別時間段(比如大促場景寺滚，或者壓力測試)下需要額外資源的企業(yè)，需要的時候在公有云上“彈”(scale out)屈雄，用完了再縮回來(scale in)村视。

發(fā)布(Release)和部署(Deploy)其實是兩個不太一樣的概念， 發(fā)布是用戶可見的酒奶，部署則未必蚁孔。Normandy當(dāng)然可以同時滿足客戶兩種不同的選擇。默認(rèn)情況下部署就等同于發(fā)布惋嚎，當(dāng)然用戶可以自己定制部署而不發(fā)布應(yīng)用(這種需求比較小眾)杠氢。

Normandy支持的發(fā)布模式比較多樣，發(fā)布策略也很多另伍，這跟阿里內(nèi)部需求的多樣性有關(guān)鼻百。同時也支持容器發(fā)布和非容器的發(fā)布(我們叫基線模式)。此外摆尝，還支持動態(tài)配置或者開關(guān)類型的發(fā)布(需要中間件支持)温艇。在能力上則支持2萬臺服務(wù)器同時發(fā)布，日均可以支持50萬次發(fā)布堕汞。

在發(fā)布上我們有運維算法平臺的支持勺爱，可以做到“無人值守”發(fā)布， 所謂的“無人值守”發(fā)布意味著用戶不再需要盯著發(fā)布了讯检， 發(fā)布系統(tǒng)如果發(fā)現(xiàn)系統(tǒng)有故障就會自動停止發(fā)布并通知用戶琐鲁， 如果一切正常則自動發(fā)布完成，無需人的干預(yù)人灼。

運維越來越需要得到算法平臺的幫助围段，將人的經(jīng)驗“沉淀”到系統(tǒng)里，不斷的累積和完善數(shù)據(jù)投放，并依靠算法的幫助來提高運維系統(tǒng)的自動化程度奈泪，讓人少犯錯，尤其是低級的錯誤。而發(fā)布部署是很多故障造成的根源段磨，這種故障給很多企業(yè)造成了巨大損失取逾。如果能在這個地方堵住故障耗绿，將極大地提升企業(yè)運維穩(wěn)定性苹支。

監(jiān)控

StarOps套件還提供了不同維度的監(jiān)控系統(tǒng)，我們有基礎(chǔ)監(jiān)控(IDC層面)误阻、系統(tǒng)監(jiān)控和業(yè)務(wù)監(jiān)控债蜜，可以分別部署。監(jiān)控系統(tǒng)我們也在做智能化運維探索究反，比如智能基線寻定，可以讓我們徹底結(jié)束一個業(yè)務(wù)監(jiān)控數(shù)十個監(jiān)控配置的困擾，可以預(yù)測下一個時間點的業(yè)務(wù)走向精耐，監(jiān)控配置只要根據(jù)這個“智能基線”來配置閾值即可狼速。同時我們的監(jiān)控系統(tǒng)還具備智能故障定位的功能。

歷經(jīng)阿里紛繁復(fù)雜的業(yè)務(wù)和雙11的各種考驗卦停，監(jiān)控除了豐富的功能和穩(wěn)定健壯的內(nèi)核向胡，還提供了非常炫目的視覺產(chǎn)品，除了傳統(tǒng)的PC屏外惊完，我們還有大屏產(chǎn)品可以獨立部署僵芹。

除了前面提到的基礎(chǔ)運維平臺、應(yīng)用運維平臺小槐、監(jiān)控拇派、算法平臺外， StarOps套件還包括了諸如掌上運維(支持IOS凿跳， Android)件豌，ChatOps等功能。

智能運維 AIOps

簡單的講運維本質(zhì)是幫助業(yè)務(wù)持續(xù)穩(wěn)定的運行所要做的所有維護性的工作控嗜。 在保持業(yè)務(wù)穩(wěn)定性的基礎(chǔ)上能降低運維成本苟径，提升運維效率，是運維系統(tǒng)的核心本質(zhì)躬审。

智能運維(AIOps)是需要融入在平臺方方面面的棘街。智能運維是從手工運維到自動化運維一步步走過來的一個自然的結(jié)果， 需要場景承边、數(shù)據(jù)和算法遭殉。

我個人對智能運維的理解是：利用運維算法實現(xiàn)運維的自動化，最終走向無人化運維博助。所以Gartner對AIOps的解釋是Algorithm IT Operations险污，并不是一開始以為的人工智能(Artificial Intelligence)運維。

我個人認(rèn)為AIOps可以在兩方面來幫助運維：

一、穩(wěn)定性：運維的本質(zhì)就是維護系統(tǒng)的穩(wěn)定性蛔糯，如何能讓系統(tǒng)平穩(wěn)的運行拯腮，變更更加穩(wěn)定，故障全面治理是首要考量的蚁飒，所以穩(wěn)定性方面的智能運維技術(shù)演進大致是：

異常檢測(Reactive)-> 根因分析(Root Cause Analysis)->根源定位(real time) -> 故障自愈(auto-healing)-> 故障預(yù)測(proactive)

無人值守發(fā)布中應(yīng)用的是異常檢測的算法动壤，而智能故障定位需要用到的就是后兩種技術(shù)。

二淮逻、效率：在穩(wěn)定的基礎(chǔ)上我們希望能看到極致的運維的效率琼懊，極低的運維成本。

智能運維的場景很多爬早，在運維的每層都有用武之地哼丈。每個點的微創(chuàng)新的累積最終會給智能運維帶來顛覆性的變化。真正實現(xiàn)這種專家經(jīng)驗和”拍腦袋“運維模式轉(zhuǎn)變?yōu)榛谒惴ê腿斯ぶ悄艿淖詣踊\維筛严，最終走向無人化運維醉旦。

“無人化”當(dāng)然短期內(nèi)只是一個“自動化程度非常高的”的代名詞，在可以看到的未來桨啃，“無人化”還是由人來干預(yù)或者參與的车胡，尤其是故障處理。

其實自動化被叫做“自働化”更為合理优幸， 人和機器更多是職能上的區(qū)別吨拍，需要優(yōu)勢互補，人不再做具體的操作了网杆，由機器替代羹饰，但人依然是運維的靈魂，是運維的制定者和修改者碳却，機器只是執(zhí)行者队秩，機器只是幫助人或者提醒人來完成運維操作。

總結(jié)

運維對企業(yè)很重要昼浦，可以說是核心競爭力馍资，不能讓運維拖了業(yè)務(wù)的后腿。

基礎(chǔ)運維平臺是運維體系建設(shè)的基礎(chǔ)設(shè)施关噪， 是運維成敗的關(guān)鍵鸟蟹。

穩(wěn)定是運維的本質(zhì)， 在穩(wěn)定性的基礎(chǔ)上追求極致的運維效率和極低的運維成本使兔。

智能運維不能一蹴而就建钥，必須按部就班，重在場景和數(shù)據(jù)的建設(shè)虐沥。

很多公司業(yè)務(wù)發(fā)展的非常好熊经，但就是運維做的不好泽艘，導(dǎo)致業(yè)務(wù)非常不穩(wěn)定，三天兩頭出故障镐依，一出故障半天才能恢復(fù)匹涮，一做發(fā)布變更就交易跌0造成資損。如果長期這樣槐壳，再好的業(yè)務(wù)也會做黃宅此。這種例子我們看到的比較多中姜。

隨著阿里巴巴越來越重視技術(shù)址貌，也越來越開放骂因，運維的幾個產(chǎn)品會逐步開源灼卢，同時也會有商業(yè)化的產(chǎn)品孵化绍哎，比如最近在做的云效2.0-智能化運維產(chǎn)品StarOps，我們希望阿里在運維領(lǐng)域多年來沉淀的經(jīng)驗鞋真、走過的彎路崇堰，能給大家?guī)硇﹩l(fā)，也希望StarOps產(chǎn)品能真正為企業(yè)的業(yè)務(wù)保駕護航涩咖。

原文發(fā)布時間為：2017-10-27

本文來自云棲社區(qū)合作伙伴“阿里技術(shù)”海诲，了解相關(guān)信息可以關(guān)注“阿里技術(shù)”微信公眾號