再談云計算

一方面，從技術能力看，當前的公有云技術遠遠難以取代我們的傳統架構；另一方面，各類管理規章劃定了公有云短期內進犯的護城河。雖然如此，不可否認的是，以效用而非技術為度量的業務用戶正在以越來越互聯網化的思維要求我們——“云計算”或許已經不再是一道可選題。

對技術管理人員來說，“云計算”在媒體渲染和公眾傳播過程中，其含義或許太含混不清了，大部分時候，向我們的客戶——業務團隊——解說其真實含義或許是不得不做的事情。而在評估云計算建設并進行規劃時，回顧云計算原本的含義，可正本清源。“云計算”最為基本和最被業界接受的定義來自美國國家標準和技術研究院（NIST）：

云計算是一種計算模式：支持用戶以網絡方式便捷、隨需的獲取共享資源池中的可配置計算資源（如網絡、服務器、存儲、應用及服務等）；這些計算資源能夠被快速的部署和回收，無需或僅需服務供應者少量的管理和干預。

“Cloud computing is a model for enabling convenient,on-demand network access to a shared pool of configurable computing resources(e.g.,networks,servers,storage,applications,and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

我們傾向于這么解讀：云計算是一種模式，包含對服務消費者和服務提供者兩個視角的行為方式。

對服務消費者而言：第一核心特征是便捷，強調體驗；第二核心特征是隨需，強調靈活和彈性；第三核心特征是可配置，強調廣泛、細粒度和靈活的服務選擇。

對服務提供者而言：第一核心特征是快速，強調服務響應和服務交付的效率；第二核心特征是同時包括資源部署和回收，強調資源的復用、自循環機制；第三核心特征是最少干預，強調流程管控層面和操作部署配置層面的自動化。

即使計算模式的革新，站在私有云建設的角度看，其本質仍然是“高效資源利用—降低運維成本—提高敏捷性以應對新業務挑戰”，和傳統的業務服務管理（BSM）理念完全一致。

在建設云計算時，設定怎樣的使用場景來實現上述目標并產生業務價值，是每個建設者在思考的問題。就目前的云計算實踐場景來看，開發-測試云是最普遍的形態。開發測試云最容易體現價值，技術上的實現起點也相對低門檻——其主要場景為資源的快速部署/回收。

如果將該場景置于生產環境，那投入產出比或許就不足夠吸引人——生產環境資源的標準化部署和回收很少發生。那么，對于更為重要和核心的生產環境，云計算的場景如何設定呢？是否就不需要云計算呢？其實，從更大的管理上下文來看，這是“云計算平臺如何建設才能持續產生價值”以及“云計算如何從簡單資源交付邁向更多服務并持續發揮作用”的議題；可以理解為Cloud 1.0如何走向Cloud 2.0。表1羅列了大中型金融企業IT組織的部分典型需求在云計算1.0和2.0時代的演化。

資源服務生命周期：云計算1.0時代以資源交付為服務的終點；云計算2.0時代則繼而支持操作類的服務（如自助備份、日志同步、軟件疊加部署等），并且在整個資源生命周期內提供面向業務規則的智能化彈性伸縮服務。

表1 Cloud 1.0和2.0的區別

服務交付粒度：云計算1.0時代以標準化OS交付為代表，提供IaaS/PaaS類資源的首次交付；云計算2.0時代則提供復雜資源組合及業務應用粒度的服務交付（如以數據庫+中間件+應用的形態獲取服務、自助化的指定所需數據庫的實例名或應用中間件的配置參數等等），同時對交付后的應用更新發布提供支持，融合DevOps。

度量與監控深度：云計算1.0時代對分配的資源進行度量和監控，通常以CPU、內存、存儲配合時長為基準；云計算2.0時代的跟蹤則擴大為面向業務應用（如交易級別、數據庫/中間件級別等），并從容量角度分析資源消費趨勢以及對業務支撐的裕量，為主動資源池擴展提供前瞻性的定性分析。

技術開放性：1.0時代的云平臺通常基于單一技術（如 VMWare、Hyper-V、OpenStack）實現；云計算2.0時代則強調混合云架構的實現和支持——不論從存量設備類型支持看，被單一技術/廠商鎖定的被動性風險看，還是未來新技術發展的不可預見性看，乃至公有云廉價化和可用程度提高等因素看，未來的企業云平臺一定由多種資源池構成，因而云平臺本身對底層技術架構的兼收并蓄的支持尤其關鍵。

自服務廣泛性：云計算的本質是后端IT能力工業化對接前端的服務化和消費化；1.0時代的自服務僅完成“云服務”的自服務，如“自助申請開發環境”；2.0時代的云計算則將云服務和傳統服務融合起來，實現用戶對各類IT服務的單一接入和交付整合，對用戶屏蔽后端服務交付的復雜性和差異性，如在單一自服務環節中完成“開發代碼庫權限開通—開發桌面虛擬化環境交付—開發環境部署交付等系列化服務組合”，即使上述服務片段的交付由傳統方式甚至全人工方式完成。

服務管控一體化：1.0時代的云計算往往是整個IT環境的特區，使用特有平臺，遵循特有流程，甚至需要特定的管理團隊……其管理方式和既有的非云環境存在較大的割裂；在云計算2.0時代，則將服務管控體系向云和非云環境統一貫徹，或者說將云平臺置于IT組織的統一管控體系下，其中典型的場景包括“對云和非云環境使用單一的CMDB進行配置跟蹤和管理”，“將云和非云環境相關的活動置于統一的ITIL流程管控下”，“將云和非云環境的對象進行統一的補丁管控”，“對云和非云環境進行一致化的合規和審計管理”……

1.0時代的云計算管理消費場景從“資源部署/回收”得以有效擴展，如：

業務應用發布自動化

應用資源環境彈性伸縮

一體化的細粒度運維

資源環境切換（如災備演練）

……

從整體云計算建設臺階看，這一進程也符合如圖1所示的進化模式：

綜合來看，1.0時代的云計算關注“交付態”，2.0時代的云計算則同時關注“交付態”、“運營態”及兩態融合。前者實現資源交付服務，體現了平臺的初期存在價值；后者強調服務的有機循環，致力于不斷交付新的有價值的云服務，體現了平臺的可持續性。這也與某第三方IT評估組織對已實踐云計算的IT組織的調研結果相契合：

圖1 整體云計算建設進化模式

——“考慮當前的云環境，您最希望回到規劃階段去重新考慮的方面？”

百分比排名最高的3項受訪者反饋為：

60%：我們低估了將云計算整合進既有管理體系（變更、配置、事件、問題等）的難度……

43%：我們應更充分的考慮用量統計和計費功能……

41%：我們忽視了對運維需求（容量、性能……）進行規劃

再回頭看大中型金融企業私有云建設的三大動因：

1)高效資源利用。

2)降低IT運維成本。

3)提高敏捷性以應對新業務挑戰。

第一點，“高效資源利用”對應基礎架構的資金成本（CapEx）。云計算的池化資源構建實現可以有效的帶來該維度收益。資源池構建（選址、選型、池化設計等）帶來直接貢獻；資源池管控（動態部署能力、容量跟蹤能力、計費&回收策略、多成本層次的異構技術整合能力）帶來間接貢獻。

第二點，“降低IT運維成本”對應基礎架構的運營成本（OpEx）。更高程度的運維標準化、自動化和智能化，更廣泛的貼合業務需求的自服務化可以有效的帶來該維度收益；自動化是其中最為關鍵的能力。

第三點，“提高敏捷性”對應業務交付敏捷性和可用性。業務交付敏捷性由于應用迭代頻 率（Release Frequency）和更新交付時間（Lead Time for Release）度量；業務可用性由應用發布更新成功率（Release Success Rate）和運行環節的平均故障修復時間（MTTR—Mean Time To Repair）度量。

可以看到，上述核心管理需求與2.0時代的云計算特性有著相當的吻合度，也體現了IT管理的最新方向。

從業界技術和建設需求的演化進程來看，可以預見，后發（相對已經完成構建云計算的組織而言）的云計算建設的決策者將越來越多的關注“運營態”并關注“交付態”和“運營態”的兩態融合，并構建一個真正可持續運營的云計算平臺。