上云后需要運維嗎？答案是：其實是必須的。

上云確實簡化了部分運維工作。比如傳統IT中服務器的日常運維，都是由云服務商完成的。但隨著云產品類型的不斷豐富和規模的不斷擴大，如何高效運維云資源正逐漸成為運維人員面臨的挑戰。

在剛剛結束的QCon全球軟件開發大會（北京站）2020“彈性工程與運維”專題中，阿里云中級技術專家趙宇（巴厘島）分享了阿里經濟云運維的話題。本文整理了整體上云后，如何在云上實現數十萬臺ECS實例手動運維的實踐和經驗。

阿里巴巴云中級技術專家趙宇

云運維的四大挑戰

隨著云測算的普及和發展，越來越多的企業選擇上云。近年來，阿里巴巴的經濟已經全面融入云端，云上運維與大多數企業遇到的問題類似。總結起來主要來自以下四個方面：

首先，存在規模問題。傳統的 和腳本管理方法在資源少的情況下運行良好，但在規模較大時就失敗了。幾十臺機器和幾萬臺機器的人肉管理是完全不同的概念。此外，云上資源的種類不斷豐富，云上資源管理和運維的復雜度呈指數級增長。

第二，安全問題。阿里巴巴經濟云遷移涉及數百個業務方，涉及眾多運維人員。如何更好地控制權限、審核和批準既復雜又極其重要。數據和資源是公司的資產。過多的運維權限會增加出錯的風險，而過少的權限會增加管理成本。如何安全地使用云賬號和資源給管理者帶來了極大的挑戰。

第三，效率問題。隨著資源規模的縮小，如何高效地管理運維，提高開發者的效率，也是云運維必須考慮的問題。

第四，成本問題。業務方對成本優化的需求很大，包括資源用戶和財務人員。希望也能提供不同維度的資源使用賬單，為成本優化措施提供依據。

我們知道，在傳統方式下，專門的資源運營團隊負責資源的配置，項目開發團隊只負責資源的使用。而隨著業務規模的不斷擴大，這些管理方式基本不可行。這時候，基本的配置管理權限就必須通過去中心化的方式交給業務項目組，而這些運維模式的改造會影響到企業云。資源管理也帶來了挑戰。

實際上，阿里經濟云運維也經歷了人肉運維到標準化、數據化、流程化運維的過程。直到2016年，內部云資源管理平臺“宙斯運維系統”原型基本制作完成，實現運維能力和體驗的標準化、流程化、系統化。隨著資源管理規模的不斷擴大和需求的多樣化，宙斯運維系統立即接管了云上資源的管控。

如何高效運維數十萬臺云服務器？

目前，宙斯運維系統管理著阿里巴巴集團內數百個業務方的20多種云產品和資源，包括數十萬個ECS實例。除了為各業務方提供資源管理和運維能力外，還提供成本剖析和補救能力。

圖：宙斯運維平臺整體架構

一般來說，宙斯運維平臺包括五個模塊：資源管理、系統運維、應用運維、監控管理和成本分析。向下通過控制臺為業務方提供服務，向上依托阿里云平臺的云監控、資源編排、運維編排、標簽系統、彈性伸縮、運維通道、財務系統管理日志服務和云服務器，網絡、對象存儲和許多其他云資源。

賬戶管理

由于歷史原因，宙斯運維平臺支持獨立大賬戶和托管賬戶兩種賬戶模式并存。獨立大賬號是阿里云平臺宙斯系統運維平臺的服務賬號。賬戶管理著業務方的大量資源。業務方將所有運維功能托管給 Zeus。由于它可以減少很多后期工作，所以它是獨立的。大客戶是我們推薦商務聚會的方式。另外，由于是服務賬號，不允許業務方直接登錄，業務方只能通過崩潰入口進行操作，降低了操作出錯的風險。

對于托管賬戶，是宙斯運維平臺之前的存量運維賬戶。為了幫助業務方更好地管理這個股票賬戶，宙斯運維平臺提供賬戶托管服務。該股票賬戶被授予宙斯服務賬戶的管理員權限，由于托管賬戶的主子賬戶與集團的登錄系統相連，運維人員可以直接登錄管理。

權限管理

權限管理的主要思想是對應用程序進行分組。應用分組用于按角色區分權限，并將角色分配給相應應用中的人。

我們賦予應用Owner、開發、運維、安全等角色，對不同的角色賦予不同的權限。 Owner角色擁有應用下資源管理的神圣權限，同時負責審批工作；開發者負責日常的CI工作，以及日常和發布前的環境測試工作；運維人員具備在線發布和審批能力；安全人員主要負責系統運行維護工作，包括安全掃描、掃碼等安全工作。

這里所有的云資源都通過標簽附加到相應的應用程序上。通過這樣的權限管理，管理員不僅可以在人的維度上看到有權限的應用，還可以在應用的維度上看到。授權人。

資源分組

Zeus運維系統基于阿里云的標注系統，支持按部門、環境等多維度對資源進行分類，Zeus運維系統對創建的資源進行相應的標注，方便業務各方進行資源搜索、管理和運維，通過標簽管理模式，可以很好地對無序資源進行運維和監控，甚至可以進行資源核算。

對于托管賬戶，可以通過API進行操作，系統可以解析離線云監控消息通知，從而按照一定的規范設置業務方的標簽，竊聽數據變化后, 會同步到 Zeus 和 CMDB。

資源交付

對于資源交付來說，最大的挑戰是云資源部署在多個區域和類型。阿里云平臺目前擁有數百種資源類型。如果每個資源都通過寫代碼和API來操作，會很復雜，效率低下。而且，大部分業務場景都不是單字符下發，如果一個一個組合起來，時間會很長。業務端通常需要基于場景的交付。大多數業務場景都有一個規范化的通用范式，通過場景化交付可以極大地改進資源交付形式。

對于這種基于場景的交付需求，雖然一開始是用腳本來操作的，但是耗費了大量的精力和人力，效率也比較低。 Zeus運維系統為了應對各種類型的資源分配場景，引入了機制進行資源調度，開源也是同樣的思路。

這里宙斯運維系統使用阿里云提供的ROS資源編排工具，引入群審批流程來規范和處理資源部署。 Zeus運維系統為常見場景下的具象成本資源安排模板，通過模板實現一鍵一鍵場景下發資源，極大的提升了我們的資源下發效率，降低了新資源的訪問門檻。

運維管理

從運維工作的類型來看，運維也是分層的。系統級的補丁管理、安全掃描、安全防護等能力是平臺的能力，業務方不需要關心。 Zeus運維系統將這個能力可視化，提供統一的管理機制。

在應用層面，主要涉及資源運維和CI/CD。 Zeus運維系統應用資源運維，將常用運維動作可視化為運維編排模板，使用阿里云運維編排服務進行工作流編排，定義常用運維場景，支持業務側自定義運維操作。這樣，運維過程就可以積累和復制。此外，借助底層能力，支持定時、告警、事件觸發運維操作，進一步提升運維操作效率。

在CI/CD部分，宙斯運維系統主要采用阿里巴巴集團的Aone（云效）系統，支持基于軟件包和鏡像的批量發布服務器運維，并允許自定義操作。

監控警報

從信息源的角度來看，告警和監控可以分為資源監控、應用監控、業務監控。級別越高，監測報警的準確率越高，但普遍性越低。 Zeus運維系統實現了多種告警處理方式。通過與監控系統的集成，通過郵件、釘釘等信息分組聯系人進行告警分發；對于手動場景，通過連接彈性伸縮和運維編排觸發手動操作，實現手動運維工作，完成手動閉環。

診斷與修復

隨著越來越多的資源和服務被使用，內部業務方就ECS實例和網絡等問題進行咨詢的次數與日俱增。為了提高解決問題的效率，運維平臺也必須具備證明自己清白的能力。 因此，通過與阿里云內部ECS、網絡、操作系統等團隊共建，借助歷史數據生成案例庫和知識庫，再加上專家經驗，積累了診斷和修復能力，一鍵診斷。幫助業務方快速定位具體問題。針對一些常見問題，將常用的打補丁腳本可視化，提供一鍵打補丁能力。

以ECS實例為例，通過對實例的監控，我們可以診斷和定位問題的根源。同時服務器運維，我們提供自動補丁解決方案。同時，我們還提供使用運維編排的一鍵手動打補丁能力。此過程支持快照回滾。 通過這部分的建設，我們日常值班的服務量大幅增加。

成本管理

成本管理的主要目標是成本優化。很多業務方申請了很多云服務器資源，發現雖然有些機器用處不大或者CPU使用率比較低，但是這樣就造成了資源的浪費。 Zeus運維系統通過成本管理的建設，將成本管理意識傳遞給業務方，推動業務方完成成本優化。

在成本管理的思路上，我們主要通過事前的卡點和活動期間的分賬能力來實現。首先，在申請資源時做一個審批卡點。如果申請的資源量很大，會提示詢問資源申請是否合理；然后，在資源使用過程中，借助標簽和應用分組能力，對資源進行分組。使用費用平均分配給相應的部門和項目組，并定期向業務方提供賬單。財務部門根據部門對賬單進行分析，確定哪些項目是入不敷出的，同時也提示業務方優化資源使用。 比如是否切換到彈性伸縮來優化成本，調整資源分配大小進行優化等，從成本的角度推動業務方進行優化。

總結

本文主要介紹在阿里巴巴經濟上云的過程中，宙斯運維系統如何高效管理云上資源的經驗。供在云運維中遇到同樣問題的運維人員參考。