本文作者：吳君印，阿里雲智能彈性計算ECS資深技術專家，負責部分ECS新產品、可信計算實例的架構，並全面負責阿里雲智能OnECS、OnAliyun產品的技術研發和運維架構工作；擁有豐富的雲計算行業的經驗，致力於打造以ECS爲中心的自動化和DevOps一體化的管理和運維體驗。
序言
雲計算行業已經有十多年的發展了，話題早已從“要不要上雲”轉向“如何用好雲”。“要不要”其實是一個決策性的話題，直到決策出來一個結果了，話題就算結束了。而“如何用好雲”卻是一個持續性的話題。
一般來說，在規劃階段開始，企業就會開始思考“如何用好雲”，這個話題會伴隨用雲的整個過程。如果簡單地從工作類型劃分，除了業務代碼的研發（Dev），其他的部分都可以稱爲運維（Ops），包含資源創建（環境部署）、應用部署、資源管理、資源監控、報警、故障排查等工作。
筆者從事雲計算工作超過五年時間，參與開發過多款雲產品，可以說既是雲計算產品的消費者，也是雲計算產品的生產者。在這裏，筆者談一談對雲上DevOps能力體系的多年思考和總結，希望對準備上雲或是已經上雲的運維人員有所幫助。
1 自動化運維等級金字塔
從運維自動化等級和程度來看，DevOps其實是一種非常高級的自動化，不僅自動化程度比較高，而且對於自動化的完成方式有着非常嚴格的定義。關於運維自動化與DevOps的關係，其實可以非常好地參考汽車自動駕駛技術分級標準，筆者做了個對比圖，如圖1。
圖1:自動化運維等級金字塔
如圖1，自動化運維可分爲5個等級，分別是手動運維、半手工/半自動化運維、高度自動化、標準化運維和AIOps，分別對應自動化駕駛的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運維開發人員則偏向於“按需分配，彈性伸縮”。
所以，筆者最後想呼籲各位財務專家多考慮下，給予技術架構上在預算上一定的靈活性，可以非常有效地幫助並促進業務高速發展。
本文爲阿里雲原創內容，未經允許不得轉載。