一文讀懂雲上DevOps能力體系

序言

雲端計算行業已經有十多年的發展了，話題早已從“要不要上雲”轉向“如何用好雲”。“要不要”其實是一個決策性的話題，直到決策出來一個結果了，話題就算結束了。而“如何用好雲”卻是一個持續性的話題。

一般來說，在規劃階段開始，企業就會開始思考“如何用好雲”，這個話題會伴隨用雲的整個過程。如果簡單地從工作型別劃分，除了業務程式碼的研發（Dev），其他的部分都可以稱為運維（Ops），包含資源建立（環境部署）、應用部署、資源管理、資源監控、報警、故障排查等工作。

筆者從事雲端計算工作超過五年時間，參與開發過多款雲產品，可以說既是雲端計算產品的消費者，也是雲端計算產品的生產者。在這裡，筆者談一談對雲上DevOps能力體系的多年思考和總結，希望對準備上雲或是已經上雲的運維人員有所幫助。

1 自動化運維等級金字塔

從運維自動化等級和程度來看，DevOps其實是一種非常高階的自動化，不僅自動化程度比較高，而且對於自動化的完成方式有著非常嚴格的定義。關於運維自動化與DevOps的關係，其實可以非常好地參考汽車自動駕駛技術分級標準，筆者做了個對比圖，如圖1。 圖1:自動化運維等級金字塔

如圖1，自動化運維可分為5個等級， 分別是手動運維、半手工/半自動化運維、高度自動化、標準化運維和AIOp s，分別對應自動化駕駛的6個Level，其中運維自動化L2對應了自動駕駛的Level 1和2。為了方便說明和對比這5個自動化運維等級，請參考如下的表格。 表1:自動化駕駛等級與自動化運維等級對比參考

• Level 1：手動運維。一些技術能力一般的企業，在上雲初期運維工作主要是純手動，只能依賴雲服務商提供的控制檯進行操作。

• Level 2：半手工/半自動化運維，運維自動化工作比例還不超過30%。運維人員可以透過命令列（CLI）完成部分運維工作。

• Level 3：高度自動化，運維自動化程度可達到50%。企業運維人員會使用雲平臺的SDK呼叫API進行日常運維工作，同時自行開發運維繫統，但運維繫統通常無定製化和平臺能力，和內部系統緊耦合。

• Level 4：標準化自動化，運維自動化程度超過90%。企業的運維繫統已具備平臺化、模版化和程式碼化的能力，可根據自身的運維需求定製化開發系統。與此同時，運維人員已具備使用具備模板化的產品來實現運維工作的標準化和自動化。

• Level 5：AIOps，即智慧運維，運維自動化程度達100%。不再需要值班人員，生產力完全解放。這是當前很多大型網際網路企業的運維目標，也是頭部企業重點投入的方向。

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

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

這裡，筆者想著重談一下 Level 3-高度自動化運維與Level 4-標準化自動化運維 的區別。大多數自研的運維繫統是在Level3 型別，例如在內部運維繫統上開發了一個功能，可以立即建立10臺雲伺服器，下次需要建立其他資源時，如建立3個訊息佇列，還是需要額外再開發建立訊息佇列功能。所以， Level 3-高度自動化運維可以理解為是一個聚焦具體場景的單一“系統”。

而Level 4-標準化自動化運維更具備普遍性，完成了更高一級的抽象。當前，大多數的雲平臺都提供了自動化部署相關產品，如AWS CloudFormation、阿里雲的資源編排工具ROS等，所以Level 4標準化自動化運維繫統其實是一個平臺型的產品。

使用Level 4階段的產品建立資源只需要建立一個模板，當需要建立新資源時，只需要套用模板即可，無需額外開發。多提一句，這裡說的模板通常是YAML或是JSON檔案，最近業界又開始將這類YAML和JSON程式碼化，面對資源的程式碼方式，思路和模板還是一致的，對於DevOps先鋒者建議可以關注下AWS CDK和Pulumi類的產品。 實現模板化後，即可以將模板的管理方式和程式碼一致，使用Git等版本控制軟體管理起來，使得模板的修改和釋出過程可以享受類似程式碼一樣的福利——評審、構建和持續釋出，這就是最DevOps的自動化方式。

2.2 模板化或程式碼化是AIOps基礎

AIOps（智慧運維）可能是我們所有人的目標，不過理想和現實的差距還是存在的。現階段的AIOps 只在少數的特定場景下才有，比如彈性擴容場景下，可以對歷史擴容資料進行學習後進行預擴容，或用AI的方式來檢測某個指標是否異常等，所以AIOps還遠沒有達到完全自動化的程度。建議在特定場景裡可進行AIOps的調研，在方向上對AIOps保持關注即可。

即便如此，筆者還是願意表達自己的觀點， 模板化或程式碼化自動化運維（即Level 4），應該會是AIOps的基礎，因為只有所有運維工作都可以被自動化、所有自動化工作都非常規範和標準時，AI才有機會進行學習，AIOps 才可能成為現實。

3 DevOps基礎核心：CI/CD，基礎設施即程式碼

通常，雲上自動化運維繫統的第一步是環境部署，這是基礎同時非常重要的一步。一旦部署完成，後續想要再去修改代價會非常大。尤其是上線以後，會是一個環境遷移的工程量了，所以環境部署是最先需要開始設計的。

圖2 ：CI/CD流水線的系統執行環境

3.1 CI/CD 流水線的系統執行環境

以實際專案中運用DevOps模式的例子——CI/CD流水線應用“基礎設施即程式碼”的實踐為例，看一下自動化部署的整個流程。 圖3：CI/CD流水線

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

相信大家對CI/CD流水線都很熟悉了，如圖3，這裡的流水線不僅包括了業務程式碼Repo，還包括了DevOps Repo，那麼DevOps Repo應該用來存什麼內容的呢？這裡重點強調的是系統所依賴的執行環境的配置，這裡的執行環境通常也叫“基礎設施”，即包括了雲伺服器、網路、資料庫、負載均衡和中介軟體等業務應用所依賴的系統環境，目錄可參考圖4。

圖4：系統環境目錄

在圖4中，environment.yml是一個環境所需要的完整模板，modules裡是各個資源模組，分別是雲伺服器、資料庫、負載均衡和VPC網路，這裡只包含了最最基本的雲資源，對於有經驗的DevOps工程師還可以增加更多的資源，如訊息佇列、kafka等中介軟體，NoSQL型別的資料庫以及監控和報警規則。

環境的配置資訊可以儲存在流水線上，這樣在部署時可以先部署環境、後部署業務。那部署環境時，可以根據實際情況選擇建立一個新環境或是更新環境。一個環境配置通常包含以下資訊：

• 環境型別：如日常測試環境、預發環境和生產環境。

• 環境地域：如杭州、北京和上海等。

• 環境其他引數：如賬號、AccessKey/Token和角色等。

• 資源相關配置：如伺服器數量、域名等。

3.2 雲上標準化部署三大能力

雲上環境與傳統資料中心的環境最大的區別是，雲上的一切服務是以API為核心，資源的建立、修改和刪除等所有操作都可以透過API來完成，因此雲上部署是天然的規範化，從而提高了雲上的部署效率，即實現了高效而統一的標準化部署。其中，典型的需重複部署的場景有以下四類：

• 環境部署，如日常測試環境、預發環境和生產環境，只需要構建一個部署，即可以透過新增stage的方式達到重複部署。通常由日常環境開始，然後重複到預發和生產環境。

• 多地域部署，如先部署在杭州、後需部署到北京和上海等其他地域，可以快速地重複部署。一般只需要在流水線上新增一個新地域stage，新增配置引數即可實現一鍵部署。

• 叢集部署，如先部署了幾個叢集，再重複部署多個叢集，同樣也可以快速地重複部署。可以透過在流水線上新增一個新叢集stage，新增配置引數即可實現一鍵部署。

• 容災環境部署，如先部署了一個主要的生產環境，後需要部署一個容災環境時，採取叢集部署的同樣方式來實現。

通常，雲上高效而標準化部署具備三大能力——消除環境差異、環境的快速複製能力和環境的重建能力。 • 消除環境差異，實現環境一致性。 環境的微小差異即可帶來業務上非常大的差異，而且排查起來非常困難，比起程式碼的Debug要費時費力許多，畢竟大部分的程式碼邏輯可以在本地復現和Debug，但是環境造成的差異則非常繁瑣，需要進行非常細緻的排查才能找到問題的癥結所在。而云上標準化部署能夠消除環境差異，實現環境的一致性，大大地簡化了運維工作。

• 一鍵部署，快速複製能力。 從日常環境到生產環境，從A地域到B地域，從單叢集到多個叢集，無一不需要高效的複製能力，而環境的複製能力是其中的第一步，且是最為關鍵的一步。標準化部署能將原來的數天工作量縮短為幾個小時，甚至一鍵部署的能力，可以說極大地提升了運維效率。

• 重建的能力。 很多環境問題是問題歷史悠久造成的，各種不規範、不標準的操作日積月累最終導致環境混亂。因此，對於日常測試環境來說，定期地推倒重建是非常有必要的，理由類似自動化測試，越乾淨的環境越能驗證、復現和Debug業務問題。因此，當一個測試環境有問題時，應該可以做到隨時釋放並能夠一鍵重建。

所以，如果在專案規劃階段就考慮到自動化部署能力，那麼後續的部署無疑會平滑許多。然而，對於已經存在的專案是否也可以使用這個模式呢？答案是肯定的，這要求對應的服務有能力將已有的雲資源轉化成部署模板的能力，然後再根據修改這個模板以便可以重複使用。

4 完整DevOps體系應具備哪些能力？

如果說，100% 自動化是DevOps理想中的形態，那麼任何環節的缺失都可能成為實踐DevOps的障礙。通常，按照運維工作的流程來看，DevOps 往往會包括八個環節：計劃、編碼、構建、測試、釋出、運維、監控， 然後重新回到計劃，開始新一輪迭代。 圖5：DevOps流程圖

值得重點強調的是，利用上述部署模板的方式，也是可以包括監控、報警等設定。因為一切皆是雲產品、一切雲產品都提供API緣故，因此才成就了部署模板是可以做到統一集中的。

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

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

圖6:雲資源生命週期四環圖

一環： 最核心的雲資源，有伺服器類資源，虛擬機器伺服器和裸金屬，也可以包括容器例項。 二環： 雲伺服器的生命週期的六個階段：建立、映象、補丁升級、診斷修復、監控和運維和例項配置。 三環：雲伺服器全生命週期的六個階段，可以利用不同的工具可以提升效率。 如例項的監控和運維，除了有云廠商提供的監控產品外，還有很多第三方的監控產品。運維方面，建議使用自動化運維類產品，如運維編排OOS，可以把最常用的運維任務模板化，從而提供運維的規範性，減少因為人肉執行的失誤，避免讓運維背鍋。 最近，我們已經將三環的這一整套“ECS自動化運維套件”正式對外發布，幫助企業實現從IT架構的規劃、遷移、部署、彈性擴縮容，到日常管理全生命週期的自動化運維。利用這套工具，每一家雲上的企業都可以低成本構建屬於自己的自動化運維體系。

四環：除了使用雲平臺工具之外，還可以利用第三方的工具 ，如Terraform、Ansible等。另外，很多工具都不約而同地選擇了模版的方式， 如YAML、JSON、Hashicorp自定義的HCL等。基於模板，可以構建一個生態，方便外部的參與者共同貢獻內容，不僅豐富了DevOps的世界，最終達到了更高的DevOps效率。

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

這裡，筆者還想簡單提一下容器DevOps和雲伺服器DevOps的區別。當前，K8S已經是容器編排（管控）領域的事實標準了，幾乎所有的雲服務商也都實現了各類託管K8S產品，甚至區域性的Serverless K8S。

很多雲伺服器的使用者對於K8S是心嚮往之，卻又因為各種原因需要繼續使用雲伺服器。筆者曾經這樣評價過K8S， “K8S本身並不是什麼技術上的重大創新，更多的是把DevOps裡面的很多最佳實踐產品化了” ——這一說法也得到了部分容器專家的認同。

5 DevOps落地的阻礙：如何和財務流程實現平衡

事實上，DevOps並不是一個新鮮的概念，但是真正做到DevOps的企業少之又少，背後的原因是多種多樣的。以筆者多年的經驗看來，其中最大的兩個因素：一個是財務，二是運維開發人員的習慣。 財務人員是典型的計劃式模式，需先預估、再採購，這裡最大的挑戰在於沒人能夠精準地預測明天的事情，所以最終的結果要麼是預估多了，要麼就是預估少了，預估多了下一次的預估必定要收緊，預估少了再放鬆，然後迴圈重複這個過程。

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

所以，筆者最後想呼籲各位財務專家多考慮下，給予技術架構上在預算上一定的靈活性，可以非常有效地幫助並促進業務高速發展。