共计 2471 个字符，预计需要花费 7 分钟才能阅读完成。
作为多云治理 CMP 畛域的实践者，博云的云治理平台产品（一体化云管平台 BeyondCMP）曾经倒退多年。近两年咱们发现很多企业客户对于云治理平台在企业数据中心管理体系中的定位是很含糊的，尤其是以下一些问题，在行业内也始终没有达成共识：
- 云治理平台与数据中心中已有或筹备建设的各类治理类平台零碎的关系是什么？比方 ITSM、CMDB、自动化平台、容器治理平台、监控平台等。
- 云治理平台中有个很重要的概念叫做“纳管”，那 云治理平台的纳管对象应该包含哪些？
- 服务目录是云治理平台中十分重要的概念，通过服务目录，云治理平台实现各类资源的自助化、自动化申请，对外扮演着数据中心对外服务的重要角色。那么云治理平台的服务目录与 ITSM 的服务目录又是什么关系？
本文针对以上问题，联合这些年博云的云治理平台在企业落地实际中的教训和咱们对行业的察看，提出一些本人的认识和了解，一家之言，仅供大家参考。
01
咱们先看看当初数据中心的被治理对象和治理平台都有什么。总结下数据中心中的被治理对象，如下图所示：
下面这个图大体笼罩了目前数据中心的被治理对象（没有蕴含大数据组件，大数据类组件目前在云治理平台我的项目中波及的非常少，独立性也很强，不纳入本文探讨范畴）。能够看到数据中心中的治理对象是十分多的，还存在各种异构的状况，比方计算资源就可能波及小机、X86、国产化服务器等，存储和网络波及的品牌型号类型就更多了。
为了治理如上的这些对象，各个企业可能曾经在数据中心体系下建设或者筹备建设各种各样的平台，大体包含如下图中的这些平台、零碎、工具：
分层对应各个治理对象和治理平台 / 工具和集体的一些观点意识：
基础设施层
针对各类基础设施的管理工具，目前最广泛建设的对基础设施的监控。对基础设施的各种自动化能力建设，比方基础设施网络自动化、存储提供自动化等，只有少部分企业做了建设。
IaaS 层
对各类公有云、私有云中 IaaS 虚拟化资源的纳管和监控，这部分目前是云治理平台治理能力的主战场。
容器云平台
容器云比拟非凡，能够认为是卡在 IaaS 和 PaaS 两头的一个平台。容器云的治理上，目前行业里个别都由容器云平台提供商提供容器云治理平台，同时个别容器云还提供了基于容器的利用公布治理平台。
数据库层
当初数据中心中的数据库越来越多，包含大量的开源数据库曾经应用了起来，所以业余的数据库治理平台需要也越来越多，行业里开始规模落地。
中间件层
中间件这一层，在目前数据中心中的地位是比拟含糊的。首先是大量的中间件曾经在应用，然而这些中间件的治理要由哪个部门、哪些人负责，行业里绝对还没有共识。有的企业是安顿了专人负责；有的则没人负责，间接依赖于利用提供商，但通常状况下，利用提供商通常也仅仅是中间件的应用方，而不是中间件专家，所以就带来了各种问题。集体认为中间件这一层在数据中心中应该是专人负责、对立提供和管控的。否则大量各种不同类型 / 版本的中间件在数据中心中的大规模应用，最终可能会成为一种治理劫难。
应用层
实际上企业所有的运维流动，实质指标都是心愿利用能失常、稳固的运行和提供服务，所以利用的运维治理是十分重要的。这一层波及到的平台工具包含利用主动部署公布、利用监控告警、微服务治理、日志监控等。
各类跨档次的工具平台
包含跨档次的自动化场景（典型的有容灾切换、主动巡检等）、数据中心的经营治理、对立监控平台等。还有一些跨档次的底层工具：自动化作业、配置管理 CMDB 等。
服务目录
目前企业里个别蕴含传统 ITSM 的服务目录和云治理平台的服务目录两类。
02
基于以上信息，咱们对目前行业中云治理平台定位含糊的问题的意识得出以下论断：通过长期察看，咱们发现云治理平台在行业中之所以呈现定位含糊的问题，外围起因是搞混了治理性能（对各层次资源的治理、监控等）和服务提供性能（服务目录）。
问题 1：因为云治理平台要提供某类“服务目录”，所以云管就须要把这些服务目录波及的资源“纳管”了？
具体落地来问：云治理平台要把如下这些资源全副治理起来吗？这正当吗？能实现吗？
细想并不难理解，通过云治理平台将如上资源的治理监控一起来做，是不合理的，也是不事实的。
典型状况：各种异构传统存储资源的类型是十分多的，行业内简直没有什么成熟产品能够做治理整合；数据库是一个业余畛域，有很多业余厂商专门做，做的也很好，应该由业余厂商来做更适合；各个企业都曾经有了自动化平台，自动化作业的业余能力也应该由业余厂商来提供更适合；利用治理、监控、容器云治理、中间件治理、CMDB 等都是相似的状况。
所以对云管纳管范畴这个问题，咱们认为：由云治理平台一个单平台来“纳管所有”，是不合理的，也是很难做好的。对数据中心中各层对象的治理包含业余工具提供，应该由各个业余治理平台工具来做。
当然，IaaS 层的各类异构虚拟化资源，是云治理平台人造的治理范畴，由云治理平台来做治理，是正当的。
问题 2：ITSM 的服务目录和云管的服务目录是什么关系？须要怎么解决？
传统的 ITSM 的服务目录，理论落地下来，是线下手工交付模式，存在效率低、响应慢、治理不不便、体验不好等问题。云治理平台的服务目录利用自助线上申请审批、资源整合自动化交付的形式，解决了云资源交付的效率和体验问题。然而局部 ITSM 大量的手动服务的服务目录还是要保留的，因而这两块应该是整合关系。
所以对 ITSM 服务目录和云管服务目录关系这个问题，咱们认为：云治理平台的服务目录和 ITSM 的服务目录应该做整合。
而云治理平台的纳管对象和云治理平台的服务目录，应该是拆散的。服务目录的对接对象，应该包含底层的各个独立治理平台。
3
以上是咱们目前对云治理平台在数据中心中定位的察看和观点，总结一下：
- 数据中心中各层对象的治理包含业余工具提供，应该由各个业余治理平台工具来做。
- 云治理平台的治理对象应该次要集中在 IaaS 层的各类异构虚拟化资源。
- 云治理平台的服务目录与 ITSM 的服务目录做整合，服务目录是云治理平台的外围重要模块。
综上所述，服务目录对立建设，各类资源的治理让业余的来，正是解决云管治理平台在数据中心中定位含糊问题的最优解决办法。
