簡介： 阿里云ECS自動化運維套件架構(gòu)師，深度拆解云上運維能力體系建設(shè)：自動化運維等級金字塔、自動化運維的進階模式、DevOps的基礎(chǔ)核心、云上標(biāo)準(zhǔn)化部署三大能力……

序言

云計算行業(yè)已經(jīng)有十多年的發(fā)展了，話題早已從“要不要上云”轉(zhuǎn)向“如何用好云”?！耙灰逼鋵嵤且粋€決策性的話題，直到?jīng)Q策出來一個結(jié)果了，話題就算結(jié)束了。而“如何用好云”卻是一個持續(xù)性的話題。

一般來說，在規(guī)劃階段開始，企業(yè)就會開始思考“如何用好云”，這個話題會伴隨用云的整個過程。如果簡單地從工作類型劃分，除了業(yè)務(wù)代碼的研發(fā)（Dev），其他的部分都可以稱為運維（Ops），包含資源創(chuàng)建（環(huán)境部署）、應(yīng)用部署、資源管理、資源監(jiān)控、報警、故障排查等工作。

筆者從事云計算工作超過五年時間，參與開發(fā)過多款云產(chǎn)品，可以說既是云計算產(chǎn)品的消費者，也是云計算產(chǎn)品的生產(chǎn)者。在這里，筆者談一談對云上DevOps能力體系的多年思考和總結(jié)，希望對準(zhǔn)備上云或是已經(jīng)上云的運維人員有所幫助。

1 自動化運維等級金字塔

從運維自動化等級和程度來看，DevOps其實是一種非常高級的自動化，不僅自動化程度比較高，而且對于自動化的完成方式有著非常嚴格的定義。關(guān)于運維自動化與DevOps的關(guān)系，其實可以非常好地參考汽車自動駕駛技術(shù)分級標(biāo)準(zhǔn)，筆者做了個對比圖，如圖1。

圖1:自動化運維等級金字塔

如圖1，自動化運維可分為5個等級，分別是手動運維、半手工/半自動化運維、高度自動化、標(biāo)準(zhǔn)化運維和AIOps，分別對應(yīng)自動化駕駛的6個Level，其中運維自動化L2對應(yīng)了自動駕駛的Level 1和2。為了方便說明和對比這5個自動化運維等級，請參考如下的表格。

表1:自動化駕駛等級與自動化運維等級對比參考

• Level 1：手動運維。一些技術(shù)能力一般的企業(yè)，在上云初期運維工作主要是純手動，只能依賴云服務(wù)商提供的控制臺進行操作。
• Level 2：半手工/半自動化運維，運維自動化工作比例還不超過30%。運維人員可以通過命令行（CLI）完成部分運維工作。
• Level 3：高度自動化，運維自動化程度可達到50%。企業(yè)運維人員會使用云平臺的SDK調(diào)用API進行日常運維工作，同時自行開發(fā)運維系統(tǒng)，但運維系統(tǒng)通常無定制化和平臺能力，和內(nèi)部系統(tǒng)緊耦合。
• Level 4：標(biāo)準(zhǔn)化自動化，運維自動化程度超過90%。企業(yè)的運維系統(tǒng)已具備平臺化、模版化和代碼化的能力，可根據(jù)自身的運維需求定制化開發(fā)系統(tǒng)。與此同時，運維人員已具備使用具備模板化的產(chǎn)品來實現(xiàn)運維工作的標(biāo)準(zhǔn)化和自動化。
• Level 5：AIOps，即智能運維，運維自動化程度達100%。不再需要值班人員，生產(chǎn)力完全解放。這是當(dāng)前很多大型互聯(lián)網(wǎng)企業(yè)的運維目標(biāo)，也是頭部企業(yè)重點投入的方向。

2 DevOps 是自動化運維的進階模式

2.1 模板化是最DevOps的自動化方式

這里，筆者想著重談一下Level 3-高度自動化運維與Level 4-標(biāo)準(zhǔn)化自動化運維的區(qū)別。大多數(shù)自研的運維系統(tǒng)是在Level3 類型，例如在內(nèi)部運維系統(tǒng)上開發(fā)了一個功能，可以立即創(chuàng)建10臺云服務(wù)器，下次需要創(chuàng)建其他資源時，如創(chuàng)建3個消息隊列，還是需要額外再開發(fā)創(chuàng)建消息隊列功能。所以，Level 3-高度自動化運維可以理解為是一個聚焦具體場景的單一“系統(tǒng)”。

而Level 4-標(biāo)準(zhǔn)化自動化運維更具備普遍性，完成了更高一級的抽象。當(dāng)前，大多數(shù)的云平臺都提供了自動化部署相關(guān)產(chǎn)品，如AWS CloudFormation、阿里云的資源編排工具ROS等，所以Level 4標(biāo)準(zhǔn)化自動化運維系統(tǒng)其實是一個平臺型的產(chǎn)品。

使用Level 4階段的產(chǎn)品創(chuàng)建資源只需要創(chuàng)建一個模板，當(dāng)需要創(chuàng)建新資源時，只需要套用模板即可，無需額外開發(fā)。多提一句，這里說的模板通常是YAML或是JSON文件，最近業(yè)界又開始將這類YAML和JSON代碼化，面對資源的代碼方式，思路和模板還是一致的，對于DevOps先鋒者建議可以關(guān)注下AWS CDK和Pulumi類的產(chǎn)品。
實現(xiàn)模板化后，即可以將模板的管理方式和代碼一致，使用Git等版本控制軟件管理起來，使得模板的修改和發(fā)布過程可以享受類似代碼一樣的福利——評審、構(gòu)建和持續(xù)發(fā)布，這就是最DevOps的自動化方式。

2.2 模板化或代碼化是AIOps基礎(chǔ)

AIOps（智能運維）可能是我們所有人的目標(biāo)，不過理想和現(xiàn)實的差距還是存在的?，F(xiàn)階段的AIOps 只在少數(shù)的特定場景下才有，比如彈性擴容場景下，可以對歷史擴容數(shù)據(jù)進行學(xué)習(xí)后進行預(yù)擴容，或用AI的方式來檢測某個指標(biāo)是否異常等，所以AIOps還遠沒有達到完全自動化的程度。建議在特定場景里可進行AIOps的調(diào)研，在方向上對AIOps保持關(guān)注即可。

即便如此，筆者還是愿意表達自己的觀點，模板化或代碼化自動化運維（即Level 4），應(yīng)該會是AIOps的基礎(chǔ)，因為只有所有運維工作都可以被自動化、所有自動化工作都非常規(guī)范和標(biāo)準(zhǔn)時，AI才有機會進行學(xué)習(xí)，AIOps 才可能成為現(xiàn)實。

3 DevOps基礎(chǔ)核心：CI/CD，基礎(chǔ)設(shè)施即代碼

通常，云上自動化運維系統(tǒng)的第一步是環(huán)境部署，這是基礎(chǔ)同時非常重要的一步。一旦部署完成，后續(xù)想要再去修改代價會非常大。尤其是上線以后，會是一個環(huán)境遷移的工程量了，所以環(huán)境部署是最先需要開始設(shè)計的。

圖2 ：CI/CD流水線的系統(tǒng)運行環(huán)境

3.1 CI/CD 流水線的系統(tǒng)運行環(huán)境

以實際項目中運用DevOps模式的例子——CI/CD流水線應(yīng)用“基礎(chǔ)設(shè)施即代碼”的實踐為例，看一下自動化部署的整個流程。

圖3：CI/CD流水線

通常流水線的源頭是從Git開始的，所以也有人將這種模式稱之為GitOps，顯然這里的Git也可以替換成其他的版本控制系統(tǒng)，如SVN等，因為思路是一樣的，所以本文依舊稱之為DevOps。

相信大家對CI/CD流水線都很熟悉了，如圖3，這里的流水線不僅包括了業(yè)務(wù)代碼Repo，還包括了DevOps Repo，那么DevOps Repo應(yīng)該用來存什么內(nèi)容的呢？這里重點強調(diào)的是系統(tǒng)所依賴的運行環(huán)境的配置，這里的運行環(huán)境通常也叫“基礎(chǔ)設(shè)施”，即包括了云服務(wù)器、網(wǎng)絡(luò)、數(shù)據(jù)庫、負載均衡和中間件等業(yè)務(wù)應(yīng)用所依賴的系統(tǒng)環(huán)境，目錄可參考圖4。

圖4：系統(tǒng)環(huán)境目錄

在圖4中，environment.yml是一個環(huán)境所需要的完整模板，modules里是各個資源模塊，分別是云服務(wù)器、數(shù)據(jù)庫、負載均衡和VPC網(wǎng)絡(luò)，這里只包含了最最基本的云資源，對于有經(jīng)驗的DevOps工程師還可以增加更多的資源，如消息隊列、kafka等中間件，NoSQL類型的數(shù)據(jù)庫以及監(jiān)控和報警規(guī)則。

環(huán)境的配置信息可以存儲在流水線上，這樣在部署時可以先部署環(huán)境、后部署業(yè)務(wù)。那部署環(huán)境時，可以根據(jù)實際情況選擇創(chuàng)建一個新環(huán)境或是更新環(huán)境。一個環(huán)境配置通常包含以下信息：

• 環(huán)境類型：如日常測試環(huán)境、預(yù)發(fā)環(huán)境和生產(chǎn)環(huán)境。
• 環(huán)境地域：如杭州、北京和上海等。
• 環(huán)境其他參數(shù)：如賬號、AccessKey/Token和角色等。
• 資源相關(guān)配置：如服務(wù)器數(shù)量、域名等。

3.2 云上標(biāo)準(zhǔn)化部署三大能力

云上環(huán)境與傳統(tǒng)數(shù)據(jù)中心的環(huán)境最大的區(qū)別是，云上的一切服務(wù)是以API為核心，資源的創(chuàng)建、修改和刪除等所有操作都可以通過API來完成，因此云上部署是天然的規(guī)范化，從而提高了云上的部署效率，即實現(xiàn)了高效而統(tǒng)一的標(biāo)準(zhǔn)化部署。其中，典型的需重復(fù)部署的場景有以下四類：

• 環(huán)境部署，如日常測試環(huán)境、預(yù)發(fā)環(huán)境和生產(chǎn)環(huán)境，只需要構(gòu)建一個部署，即可以通過新增stage的方式達到重復(fù)部署。通常由日常環(huán)境開始，然后重復(fù)到預(yù)發(fā)和生產(chǎn)環(huán)境。
• 多地域部署，如先部署在杭州、后需部署到北京和上海等其他地域，可以快速地重復(fù)部署。一般只需要在流水線上新增一個新地域stage，添加配置參數(shù)即可實現(xiàn)一鍵部署。
• 集群部署，如先部署了幾個集群，再重復(fù)部署多個集群，同樣也可以快速地重復(fù)部署?？梢酝ㄟ^在流水線上新增一個新集群stage，添加配置參數(shù)即可實現(xiàn)一鍵部署。
• 容災(zāi)環(huán)境部署，如先部署了一個主要的生產(chǎn)環(huán)境，后需要部署一個容災(zāi)環(huán)境時，采取集群部署的同樣方式來實現(xiàn)。

通常，云上高效而標(biāo)準(zhǔn)化部署具備三大能力——消除環(huán)境差異、環(huán)境的快速復(fù)制能力和環(huán)境的重建能力。
? 消除環(huán)境差異，實現(xiàn)環(huán)境一致性。環(huán)境的微小差異即可帶來業(yè)務(wù)上非常大的差異，而且排查起來非常困難，比起代碼的Debug要費時費力許多，畢竟大部分的代碼邏輯可以在本地復(fù)現(xiàn)和Debug，但是環(huán)境造成的差異則非常繁瑣，需要進行非常細致的排查才能找到問題的癥結(jié)所在。而云上標(biāo)準(zhǔn)化部署能夠消除環(huán)境差異，實現(xiàn)環(huán)境的一致性，大大地簡化了運維工作。

? 一鍵部署，快速復(fù)制能力。從日常環(huán)境到生產(chǎn)環(huán)境，從A地域到B地域，從單集群到多個集群，無一不需要高效的復(fù)制能力，而環(huán)境的復(fù)制能力是其中的第一步，且是最為關(guān)鍵的一步。標(biāo)準(zhǔn)化部署能將原來的數(shù)天工作量縮短為幾個小時，甚至一鍵部署的能力，可以說極大地提升了運維效率。

? 重建的能力。很多環(huán)境問題是問題歷史悠久造成的，各種不規(guī)范、不標(biāo)準(zhǔn)的操作日積月累最終導(dǎo)致環(huán)境混亂。因此，對于日常測試環(huán)境來說，定期地推倒重建是非常有必要的，理由類似自動化測試，越干凈的環(huán)境越能驗證、復(fù)現(xiàn)和Debug業(yè)務(wù)問題。因此，當(dāng)一個測試環(huán)境有問題時，應(yīng)該可以做到隨時釋放并能夠一鍵重建。

所以，如果在項目規(guī)劃階段就考慮到自動化部署能力，那么后續(xù)的部署無疑會平滑許多。然而，對于已經(jīng)存在的項目是否也可以使用這個模式呢？答案是肯定的，這要求對應(yīng)的服務(wù)有能力將已有的云資源轉(zhuǎn)化成部署模板的能力，然后再根據(jù)修改這個模板以便可以重復(fù)使用。

4 完整DevOps體系應(yīng)具備哪些能力？

如果說，100% 自動化是DevOps理想中的形態(tài)，那么任何環(huán)節(jié)的缺失都可能成為實踐DevOps的障礙。通常，按照運維工作的流程來看，DevOps 往往會包括八個環(huán)節(jié)：計劃、編碼、構(gòu)建、測試、發(fā)布、運維、監(jiān)控，然后重新回到計劃，開始新一輪迭代。

圖5：DevOps流程圖

值得重點強調(diào)的是，利用上述部署模板的方式，也是可以包括監(jiān)控、報警等設(shè)置。因為一切皆是云產(chǎn)品、一切云產(chǎn)品都提供API緣故，因此才成就了部署模板是可以做到統(tǒng)一集中的。

筆者所在的阿里云，DevOps體系不僅環(huán)境部署實現(xiàn)了模板化，連運維編排也可以模板化的，即自動化運維（阿里云提供運維編排工具OOS），業(yè)界也把這種模式叫做Ops as Code、Automation as Code或是Runbook as Code了。因為產(chǎn)品的設(shè)計原則和思想和部署模板一致，所以不再贅述其詳細步驟。

作為云計算產(chǎn)品的生產(chǎn)者，筆者同時也從一個云資源的全生命周期梳理了一個DevOps的閉環(huán)，如圖5。這張圖筆者在今年2020云棲大會的分享中也做了闡述，熟悉北京的朋友喜歡用“四環(huán)圖”來稱呼它。

圖6:云資源生命周期四環(huán)圖

一環(huán)：最核心的云資源，有服務(wù)器類資源，虛擬機服務(wù)器和裸金屬，也可以包括容器實例。
二環(huán)：云服務(wù)器的生命周期的六個階段：創(chuàng)建、鏡像、補丁升級、診斷修復(fù)、監(jiān)控和運維和實例配置。
三環(huán)：云服務(wù)器全生命周期的六個階段，可以利用不同的工具可以提升效率。如實例的監(jiān)控和運維，除了有云廠商提供的監(jiān)控產(chǎn)品外，還有很多第三方的監(jiān)控產(chǎn)品。運維方面，建議使用自動化運維類產(chǎn)品，如運維編排OOS，可以把最常用的運維任務(wù)模板化，從而提供運維的規(guī)范性，減少因為人肉執(zhí)行的失誤，避免讓運維背鍋。
最近，我們已經(jīng)將三環(huán)的這一整套“ECS自動化運維套件”正式對外發(fā)布，幫助企業(yè)實現(xiàn)從IT架構(gòu)的規(guī)劃、遷移、部署、彈性擴縮容，到日常管理全生命周期的自動化運維。利用這套工具，每一家云上的企業(yè)都可以低成本構(gòu)建屬于自己的自動化運維體系。

四環(huán)：除了使用云平臺工具之外，還可以利用第三方的工具，如Terraform、Ansible等。另外，很多工具都不約而同地選擇了模版的方式， 如YAML、JSON、Hashicorp自定義的HCL等?；谀０澹梢詷?gòu)建一個生態(tài)，方便外部的參與者共同貢獻內(nèi)容，不僅豐富了DevOps的世界，最終達到了更高的DevOps效率。

圖6不僅包含了阿里云的DevOps工具，也包括了業(yè)界較為流行的運維工具，它們的設(shè)計思想都是類似的，因此在工具的采用上可以根據(jù)實際需要分別采用。一般來說，如果使用的是單一云平臺的云資源時，使用云平臺一方的產(chǎn)品有著最一致的體驗，集成度也最高，成本也是相對最少的。

這里，筆者還想簡單提一下容器DevOps和云服務(wù)器DevOps的區(qū)別。當(dāng)前，K8S已經(jīng)是容器編排（管控）領(lǐng)域的事實標(biāo)準(zhǔn)了，幾乎所有的云服務(wù)商也都實現(xiàn)了各類托管K8S產(chǎn)品，甚至局部的Serverless K8S。

很多云服務(wù)器的使用者對于K8S是心向往之，卻又因為各種原因需要繼續(xù)使用云服務(wù)器。筆者曾經(jīng)這樣評價過K8S，“K8S本身并不是什么技術(shù)上的重大創(chuàng)新，更多的是把DevOps里面的很多最佳實踐產(chǎn)品化了”——這一說法也得到了部分容器專家的認同。

5 DevOps落地的阻礙：如何和財務(wù)流程實現(xiàn)平衡

事實上，DevOps并不是一個新鮮的概念，但是真正做到DevOps的企業(yè)少之又少，背后的原因是多種多樣的。以筆者多年的經(jīng)驗看來，其中最大的兩個因素：一個是財務(wù)，二是運維開發(fā)人員的習(xí)慣。
財務(wù)人員是典型的計劃式模式，需先預(yù)估、再采購，這里最大的挑戰(zhàn)在于沒人能夠精準(zhǔn)地預(yù)測明天的事情，所以最終的結(jié)果要么是預(yù)估多了，要么就是預(yù)估少了，預(yù)估多了下一次的預(yù)估必定要收緊，預(yù)估少了再放松，然后循環(huán)重復(fù)這個過程。

財務(wù)上的限制對于DevOps的發(fā)展有時是致命的，這種“計劃式”的模式直接影響到了云上資源的創(chuàng)建和釋放模式，財務(wù)上喜歡“包年包月”，因為看起來比較劃算，而DevOps運維開發(fā)人員則偏向于“按需分配，彈性伸縮”。

所以，筆者最后想呼吁各位財務(wù)專家多考慮下，給予技術(shù)架構(gòu)上在預(yù)算上一定的靈活性，可以非常有效地幫助并促進業(yè)務(wù)高速發(fā)展。

作者：吳君印

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載