當我們在談「雲管」，我們在談些什麼?
我們先來看看權威機構對雲管是怎樣定義的。
Gartner對雲管的定義如下：
CMP （Cloud management platforms，雲管理平臺）是一種管理公有雲、私有雲和混合雲環境的整合性產品，讓企業組織能夠統一管理多雲服務及資源。
主要能力包含混合雲、多雲環境的統一管理和調度、提供系統映像、計量計費以及通過既定策略優化工作負載。更先進的產品還可以與外部企業管理系統集成，包括服務目錄，支持存儲和網絡資源的配置，允許通過服務治理加強資源管理，並提供高級監控，提高性能和可用性。
在Gartner2019發布的報告《Critical Capabilities for Cloud Management Platforms》中指出，CMP具備以下7個關鍵能力：
CSCC對雲管定義如下，總結下也包括這麼幾個能力：
· 資源管理
· 用戶服務管理
· 成本管理
· 合規與策略
· 安全
大的方面來說，對於企業雲管是ITOM中的一個運維管理領域。因此在建設雲管的同時，我們可能不得不考慮雲管在ITOM中應該處於怎樣的地位和位置，跟ITOM中其他運維領域如何交互和相互發生作用。說到這裡，我們順帶也翻閱了下Gartner 2020對於ITOM的定義：
從上圖中，可以看到ITOM的定義中是有CMP的。那到底CMP和ITOM是啥關係呢，兩者之間關係該如何考慮呢？這兩者與周邊的例如CMDB、ITSM、自動化工具、各類監控工具之間又該如何統籌呢？
我們知道Gartner是全球最具權威的IT研究與顧問諮詢公司之一，它在IT領域中研究和定義非常多的東西，它出具的報告也都非常有權威性，除了這麼幾點：
· Gartner我只管定義哈~
· 你自己要統籌考慮哈~
· 建設錯了可別賴我~
上面的問題就被留給了每個企業用戶、每個產品廠商、每個服務商自己來考慮了。有鑑於此，我們在著手建設雲管平臺之前，從技術層面來看，最好問下自己下面這三個問題：
雲管定位及功能擴大化帶來哪些問題？
對上述前2個問題，部分甲方用戶和部分廠商的回答是下面這樣的：
然後，實事求是的講，這種對於雲管功能、雲管和ITOM關係以及雲管建設方法的理解，是會帶來很多問題的，這些問題可能直接導致項目的失敗。
我們先來隨便看兩張源自網絡搜索的部分廠商的雲管建設方案架構圖：
結合前面Gartner和CSCC對於雲管平臺、ITOM的定義，從這兩張架構圖中，你發現了什麼？
最為直接的發現就是：這兩張圖，如果不言明，你肯定不會認為是一個雲管的架構圖，很可能會認為是一個ITOM運維體系的功能架構圖。
第一張圖除了雲管功能外，CMDB、服務流程、倉庫管理、作業平臺、自動化運維場景、監控告警等ITOM能力也被一股腦塞入了雲管建設方案；第二張圖也不遑多讓，把CMDB、服務流程管理、自動化運維、多種專業化的監控管理工具等也被塞進了網管的功能架構圖中。
按照Gartner的對於雲管和ITOM的定義，這兩個產品已經遠遠不是雲管的解決方案了，而是一個龐大的ITOM的產品體系。
像這種，在一個原本定位為雲管的項目中塞入大量ITOM功能的建設方法，看起來似乎項目功能齊全、產品功能強大、豐富，什麼都可以幫助用戶實現，但是，卻會帶來很多問題。我們把這些問題總結為四個點：
這些問題對於項目建設可能是致命的，讓我們來逐一剖析給大家。
首先是定位問題：這種功能包羅萬象的雲管項目和雲管產品已經脫離了雲管的內涵，在大的運維體系中難以定位。
這個問題是最麻煩的，在IT資源規模越大、IT管理工具越多的企業中，這個問題越麻煩。由於這些企業現存運維工具眾多，相互之間各有交互，未來可能還要上新的運維工具，就顯得更加麻煩。我們把這個問題說的明白一點，表現為下面這三個點：
其次是建設問題：這類包羅萬象的雲管項目和雲管產品建設的技術風險和項目風險都很高。
這一點很容易理解，功能越多，產品越重，自身功能的建設以及與周邊系統的集成交互建設也就越難、工作量越大、技術風險也就越高；項目周期和費用都是有限的，在有限項目周期內完成這麼複雜的建設，項目風險自然不低。
使用問題：一個豎井式項目產品，功能越多、集成越多，越不好用，這是一定的。
你媽喊你去買口鍋回來炒菜，你要是膽敢買下圖中上面那口，就等著回家跪搓衣板吧~
擴展問題：在這麼一個擁有複雜功能的單一產品（即便是分布式或者微服務化開發架構，本質上依然是一個功能緊耦合的單一產品）上做擴展，難度非常大，而且牽一髮動全身往往帶來新的問題。
可以看到，建設雲管平臺如果不牢牢抓住雲管需要解決的本質問題，而將原本屬於ITOM建設範疇的功能一股腦塞到雲管項目和產品中，是會帶來相當大問題的。輕則項目成果不好用，不願意用，重則項目失敗和爛尾，這樣的項目事故我們都見過不少。既然如此，為什麼這種雲管的建設模式依然局部存在呢？
一碗水要端平，板子也不能光打在一方身上。我們將原因總結為以下三個方面：
解決方法和出路在哪裡？
要避免此類雲管建設問題的出現，真正實現：功能架構合理、敏捷可落地、能持續發展的雲管平臺建設，可能需要從以下4個方面著手：
追本溯源，回歸雲管本質
雲管要解決的就是混合雲管理的問題，儘量不要把雲管建設拔高到ITOM運維體系的維度，否則出現問題在所難免。雲管產品的原本定位，究竟需要解決什麼問題呢？其實很簡單，如下所示：
一旦回歸到雲管的本源，再去思考雲管功能的建設，就不容易超出必要的邊界；原則上，在上述4點之外的功能，比如CMDB、應用自動化運維等等，都是不建議放到雲管項目中去一股腦實現的，可以放到ITOM管理平臺中去建設，並與雲管產品建立必要的數據和運維流程的交互。
清晰定義雲管項目或者產品與ITOM整體運維體系間關係
在建設雲管項目時，除了雲管自身功能，還需要將雲管放到運維管理體系中統籌考慮，明確雲管在運維系統中的位置，以及與ITOM中其他運維領域如何交互，如下所示：
「大」平臺+「小」雲管：運維體系平臺化+雲管場景工具化構建方式
雲管項目的建設本身建議採用運維體系平臺化+雲管場景工具化構建方式進行構建。這樣有多個好處：
運維平臺為雲管提供通用運維能力：
通用的運維管理能力統一沉澱到運維管理PaaS平臺，為雲管功能提供能力輸出。例如通過平臺的統一管控模塊和API網關模塊，能夠實現各種混合雲資源和雲原生運維工具的統一接入和集成；利用平臺的監控告警及接入能力，在雲管工具中實現告警、展示和通知等功能……復用這些通用平臺能力，長出單獨的、個性化的雲管工具。
基於平臺，ITOM多種場景工具間有機集成：
基於運維平臺這樣同一個底座，能夠實現CMDB、自動化運維、一體化監控、ITSM等其他ITOM場景的單獨管理工具；這些工具和雲管工具紮根於同一個平臺，多方之間的交互更加自然、流暢和緊密，同時又彼此相對獨立。
利用平臺的PaaS集成及運維開發屬性，實現雲管平臺的不斷迭代
我們做過一個統計，往往在雲管項目實施工作中，定製化功能開發和客戶化集成的工作量比例至少佔到50%。這意味著希望一個雲管產品或者方案，開箱即用，就能滿足自己的所有需求是不現實的。即便當前滿足了，未來需求發生了變化，同樣需要定製開發。
這樣的話，在選型產品的時候，就需要特別注意產品或者方案實打實的擴展能力如何。這種擴展能力包括兩個方面：外部系統的集成擴展能力和雲管功能的迭代擴展能力。
綜上，我們簡單總結下：要建設一個架構功能合理、技術可落地、能夠持續發展的雲管平臺，可以考慮從以下5個點考慮和發力：
某大型集團雲管平臺項目建設案例分享
某大型集團為了統籌混合雲資源管理，面向用戶提供更加高效、安全、穩定的雲服務，啟動了雲管平臺項目建設工作。我司中標該項目後，基於用戶業務現狀，從客戶的ITOM管理全局出發，統籌考慮雲管的定位以及雲管的功能，經過多輪梳理，輸出了如下的雲管需求：
在明確需求的基礎上，繼續清晰的定義了雲管工具與ITOM運維體系的各自業務範疇和邊界，基於運維體系平臺化+雲管場景工具化進行項目建設，形成了清晰的全局架構：
接下來，雲管具體功能的定義就水到渠成，自然而然了：
最終，整個雲管項目建設大獲成功，實現了集團項目啟動初期的如下建設目標，進一步推動和加快了集團的數位化轉型的步伐和IT運維管理的直接業務效能：
· 雲資源集中標準化管控
· 資源自助化、服務化
· 提升IT資源運營效率
· 提升用戶雲服務使用效率
· 雲管平臺融入運維體系
其他優質文章
這裡有一份關於系統架構知識的匯總 ，請查收...
AD FS是什麼，用在什麼場景，原理是什麼？
【並發操作】協程，線程，進程是什麼，在python中怎麼應用？
恭喜！藍鯨DevOps平臺助中國人保財險通過DevOps持續交付3級！
【愛嬰島】千店千面多元母嬰零售，雲化系統支持業務發展！