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

序言

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

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

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

1 自動化運(yùn)維等級金字塔

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

圖1:自動化運(yùn)維等級金字塔

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

表1:自動化駕駛等級與自動化運(yùn)維等級對比參考

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

2 DevOps 是自動化運(yùn)維的進(jìn)階模式

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

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

而Level 4-標(biāo)準(zhǔn)化自動化運(yùn)維更具備普遍性，完成了更高一級的抽象。當(dāng)前，大多數(shù)的云平臺都提供了自動化部署相關(guān)產(chǎn)品，如AWS CloudFormation、阿里云的資源編排工具ROS等，所以Level 4標(biāo)準(zhǔn)化自動化運(yùn)維系統(tǒng)其實(shí)是一個平臺型的產(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)品。
實(shí)現(xiàn)模板化后，即可以將模板的管理方式和代碼一致，使用Git等版本控制軟件管理起來，使得模板的修改和發(fā)布過程可以享受類似代碼一樣的福利——評審、構(gòu)建和持續(xù)發(fā)布，這就是最DevOps的自動化方式。

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

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

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

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

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

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

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

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

圖3：CI/CD流水線

通常流水線的源頭是從Git開始的，所以也有人將這種模式稱之為GitOps，顯然這里的Git也可以替換成其他的版本控制系統(tǒng)，如SVN等，因?yàn)樗悸肥且粯拥模员疚囊琅f稱之為DevOps。

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

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

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

環(huán)境的配置信息可以存儲在流水線上，這樣在部署時可以先部署環(huán)境、后部署業(yè)務(wù)。那部署環(huán)境時，可以根據(jù)實(shí)際情況選擇創(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ī)范化，從而提高了云上的部署效率，即實(shí)現(xiàn)了高效而統(tǒng)一的標(biāo)準(zhǔn)化部署。其中，典型的需重復(fù)部署的場景有以下四類：

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

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

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

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

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

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

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

圖5：DevOps流程圖

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

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

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

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

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

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

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

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

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

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

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

財(cái)務(wù)上的限制對于DevOps的發(fā)展有時是致命的，這種“計(jì)劃式”的模式直接影響到了云上資源的創(chuàng)建和釋放模式，財(cái)務(wù)上喜歡“包年包月”，因?yàn)榭雌饋肀容^劃算，而DevOps運(yùn)維開發(fā)人員則偏向于“按需分配，彈性伸縮”。

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

作者：吳君印

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