当我们在谈“云管”，我们在谈些什么?
我们先来看看权威机构对云管是怎样定义的。
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资源运营效率
- 提升用户云服务使用效率
- 云管平台融入运维体系
