如何通過雲平台充分發揮私有雲的價值？

編輯｜江柳

隨著雲計算技術和產品的逐步成熟，以及對安全性和可控性的要求，不少大中型企業已經建成或者正在建設私有雲。私有雲對企業帶來的效益包括提高 IT 資源利用率、提高 IT 運維效率、降低信息化 TCO、提升 IT 服務質量、加快業務系統的 TTM 等等很多方面。但實際情況是公司花了大把資金建設了一個甚至多個高大上的雲平台，但感覺資源發放還是慢，資源利用率依然低，運維起來反而更複雜，完全沒有收穫當初廠商承諾的效益。

資源的發放不僅僅是通過鏡像克隆一台虛擬機實例那麼簡單，還需要做很多配置拉通工作，例如配置 VLAN、安全策略、路由等等，這些網路配置環節如果沒有自動化，就會拖慢整個資源發放的速度，這樣的雲平台就不算是一個完整功能的雲平台。

影響資源發放速度的原因之一是沒有做端到端的自動化，大多數情況下是沒有引入網路自動化功能，這個可以通過啟用 SDN、VXLAN 等技術來實現，本文不做進一步討論；二是在資源發放流程中引入了人工審批環節，這個問題和資源利用率低、運維效率低等問題都是因為沒有用好雲平台而導致的，不是雲平台本身的問題。本文主要介紹怎麼用雲平台才能充分發揮私有雲的價值。

任何一種新技術或新系統都需要在流程和組織結構上進行適配，十幾年前很多企業實施 ERP 系統，效益好的都是哪些在流程和組織上進行適配的企業，這幾年熱推的 DevOps，也是需要做好流程和組織適配才能充分發揮 DevOps 的價值，私有雲也是一樣。

在傳統 IT 環境下，業務系統的建設流程通常如下圖所示。

私有雲平台建成投產後，業務系統建設的基本流程沒有變化，但要求在某些環節的具體操作上作出改變，以適配雲計算的特點，進而發揮出雲計算的價值。我把需要作出調整的環節加亮顯示了。

首先，由於雲平台為企業搭建了統一的資源池，並提供了業務系統所需要的 IaaS 和 PaaS 層雲服務，所以單個業務系統的建設過程中不再需要獨立採購硬體設備和基礎軟體（操作系統、虛擬化軟體、中間件），而是在私有雲初始建設過程中或未來的資源池擴展過程中對硬體設備和基礎軟體進行集中採購並集中部署。單個業務系統的建設過程中僅需要採購雲服務未包含的專有軟體，並通過申請雲服務的形式來使用底層 IT 基礎設施資源和基礎軟體。

第二，由於雲平台通過自動化技術完成了硬體設備和基礎軟體的部署和配置，業務系統的實施過程中不再需要部署和配置硬體設備和基礎軟體了，只需要在申請的雲服務（虛擬機服務、存儲服務、中間間雲服務等）基礎上部署和配置業務系統的專有軟體。所以上述的「硬體安裝及配置」和「基礎軟體部署及配置」兩個環節可以省掉。

第三，由於雲平台提供了豐富的 PaaS 服務，包括各種雲中間件、各種 API、微服務框架等，完全可以基於這些 PaaS 服務進行應用軟體的架構設計、開發及測試，並將通過驗收測試的應用軟體直接部署在雲平台上。這樣的應用軟體從架構設計到部署運行都是在雲平台之上進行，也就是我們常說的 Cloud Native 應用，通過這種方式才充分發揮了雲平台的價值。

經過改造適配后的業務系統建設流程如下圖所示：

不同於公有雲，在私有雲中雲服務是不收費的，如果我們不做任何審批或限制，租戶都傾向於申請比實際需求多得多的資源，人為導致了資源的浪費。所以我們需要去評審雲服務申請的合理性，不合理的雲服務申請統統拒絕。但問題又來了，如果在每一次租戶申請雲服務的過程中都去人為審批該次服務申請的合理性，帶來的工作量足以讓人崩潰，而且加入人為審批環節也將拖慢資源發放的速度，顯然這不是好的方式。

我們改進一下流程，引入資源配額機制。業務系統是雲平台上的租戶，在業務系統申請雲服務之前，讓業務系統管理員（也就是租戶管理員）先根據業務系統的需求申請一定數量的資源配額，雲平台管理員或上級租戶管理員對其資源配額申請的業務合理性進行評估，如果沒有問題，就在雲平台上給該租戶分配資源配額。後面租戶管理員申請具體的雲服務時，雲平台檢查該租戶名下的可用配額是否足夠，足夠的話就不再進行人工審批，自動進行資源的發放；如果不足夠再提醒租戶管理員對配額進行擴展。

資源配額機制能夠避免雲服務的濫用，但是否能保證資源利用率的提升呢，答案是未必，因為資源配額評審時是沒法評估到資源利用率的。那為了提升雲平台整體資源池的利用率，我們還需要以租戶為單位引入資源考核機制，按照一定周期（月度、季度、年度）對租戶的資源利用率進行晾曬排名，針對資源利用率高的租戶在業績上給予獎勵，針對資源利用率低的租戶，在業績上進行懲罰，並在其下一次擴展資源配額時進行更為嚴格的審批。另外也需要考核配額的使用率，針對申請大量配額而不申請實際資源的租戶進行懲罰。

業務系統建成投產後即進入系統運維階段。傳統 IT 環境下，業務系統獨自佔用網路、存儲、伺服器、操作系統、中間件和資料庫等 IT 資源，IT 資源沒有在企業範圍內進行共享。這就導致在系統運維方面，各業務系統會組建專門的團隊負責運維該業務系統獨自佔用的 IT 基礎設施資源、基礎軟體和應用軟體，一個業務系統的運維團隊和另一個業務系統的運維團隊是相互隔離的，沒有實現運維人員、運維技術和運維工具的共享；另外，同一個運維團隊中的人往往同時負責運維存儲、網路、伺服器甚至操作系統等，沒有實現運維人員的專業化分工，整體運維效率低下。如下圖左半部分所示。

私有雲平台建成后，由於網路、存儲、伺服器、操作系統、中間件和資料庫等由雲平台統一部署和配置，故這些 IT 資源也由雲平台運維團隊負責統一運維，而不再是由原來分散在不同業務系統的小型運維團隊負責，具體做法可以是將這些小型運維團隊合併精簡成一個大型的雲平台運維團隊，實現運維人員、運維技術、運維工具的共享和最大化利用。另外，雲平台運維團隊負責管理的資源規模比較龐大，由一個人同時負責網路運維和存儲運維的做法已經不切實際，所以需要針對每一種資源設立獨立的專業小組進行運維，達成運維工作的專業化分工，這種專業分工結合運維自動化技術將大幅提高運維效率。如圖右半部分所示。

需要注意的是，由於雲平台不負責業務系統應用軟體的部署和配置，所以應用軟體的運維工作還是會落在業務系統項目組這邊，而且由於各個業務系統的應用軟體有各自的特點，所以還是採取單獨運維的方式。

業務系統的建設模式和運維模式調整之後，還需要對 IT 組織結構進行調整，這樣才能確保這些調整后的模式能夠正常運作。

傳統 IT 環境下的 IT 組織結構大致如下圖所示，IT 部門在 IT 管理領導下主要按照業務系統劃分成不同的項目組，每個業務系統項目組負責該系統的建設，同時也負責該系統的 IT 基礎設施資源、基礎軟體和應用軟體的運維。除了業務系統項目組之外，針對跨系統的支撐型工作成立專項項目組，例如信息安全、數據中心和整體 IT 規劃等。

而私有雲建成后，雲平台作為一個統一管理 IT 基礎設施資源和基礎軟體的平台，也需要同信息安全和數據中心一樣，成立專門的項目組。雲平台項目組負責雲平台的建設及運維、IT 基礎設施資源池的建設和運維、基礎軟體的部署和運維，因此，業務系統項目組不再需要負責 IT 基礎設施資源池和基礎軟體的運維，僅需負責應用軟體的運維。另外，由於雲平台項目組統一建設和運維網路資源池，則數據中心項目組也無需再負責網路環境的建設和運維，僅需負責數據中心風火水電的建設及運維。為了更好地發揮出雲計算的價值，還需要成立專門的軟體研發團隊，專門致力於設計、開發及測試 Cloud Native 的應用。

私有雲模式下的 IT 組織結構大致如下圖所示。

私有云為企業搭建統一的 IT 基礎設施資源池，並將底層 IT 基礎設施資源和基礎軟體封裝為雲服務，這些資源池和雲服務由企業獨佔使用，並由該企業完全控制和管理。為了充分發揮私有雲的價值，要求業務系統建設時通過申請雲服務的方式進行業務系統的搭建，也要求在業務系統運維時將 IT 基礎設施資源和基礎軟體進行統一運維，還要求引入資源配額機制和資源考核機制來提高資源的利用率，同時要求成立專門的雲平台項目組負責雲平台和資源池的建設及運維。

雲計算時代，運維將會面臨哪些新的挑戰？推薦一場 InfoQ 主辦的 CNUTCon 全球運維技術大會，大會將以 DevOps 為落腳點，向你闡述關於運維的方方面面，7折倒計時5天，點擊「閱讀原文「了解更多精彩！

細說雲計算

「細說雲計算」是InfoQ旗下關注云計算技術的垂直社群，投稿請發郵件到[email protected]，註明「細說雲計算投稿」即可。