回顾国内企业级运维管理发展历程，随着ITIL在2005年国内的引入和实践，CMDB的价值逐步成为业界共识，CMDB也成为运维重点建设目标。

| CMDB的发展回顾和问题挑战

CMDB从最早侧重基础设施资产管理，逐步延伸到软硬件结合的配置管理建设，并逐步从业务视角进行资源梳理提升，结合云计算模型进行匹配改进。然而，CMDB的建设之路也是充满艰辛，投产后往往无法发挥应有效益，很多金融、政企数据中心级的用户也历经多轮CMDB迭代甚至推倒重建，仍然不能发挥其应有效益，成为IT运维人员挥之不去的心魔。

随着数字化时代的来临，DevOps、SRE、ITOA、AIOps等理念快速发展，运维管理也进入了自动化驱动、智能化提升的运营阶段，CMDB在新的数字化运维时代，该如何发展定位，该如何生产实践，是一个需要急待探讨的课题。要探讨新一代的CMDB建设，就需要去审视传统CMDB建设和运营中存在的问题，我们认为可从以下两个方面进行总结：

一、管理问题：过往尝试建立集中化的配置管理机制，但是容易遇到技术部门之间配合的瓶颈；各个技术部门也纷纷希望解决专业需求，导致颗粒度过细，从而维护失控；维护角度偏向于按技术分类，缺少服务视角的关系梳理；没有梳理好CMDB的服务场景，最终导致数据只进不出，没有发挥数据核心价值。

二、技术问题：软件围绕集中化思路设计，没有形成分工协同能力；配置模型越来越复杂，数据交错繁杂难以维护；比较依赖人工维护和同步，发现能力不足，且配置可信度不足；场景分享和服务能力匮乏，没有融合其他运维工具，弱化为配置台帐统计系统。总体来说：传统的CMDB管理，主要采用集中化管理的机制，缺乏协同和自动化能力，场景化和服务化的能力不足，导致CMDB无法成为生产实践的核心数据标准参照。

| CMDB的内涵与外延探讨

随着自动化、大数据、智能化在运维领域的应用，我们进入到数字化运维阶段，运维PaaS平台的中台理念逐步被企业级用户所接受和应用，CMDB在这种环境下，需要摆脱传统定位，重塑价值，所以先对CMDB内涵和外延做一下分析。

CMDB的内涵在ITIL的定义是包含IT服务中所使用的硬件和软件组件，以及组件之间关系相关信息。数字化时代业务和IT已经趋于融为一体，所以CMDB应该站在业务服务角度，建立各类IT资源的对象和关系的数据集合。

CMDB的外延在新时代也有了新诠释，新一代运维需要建立运维的中台能力，而中台的核心价值就是数据，CMDB定位于运维数据中台的核心主数据，在其上进行数据延展和叠加，围绕CMDB展开监、管、控、服、营的治理和提升。

所以，新一代的CMDB应该首先关注IT业务服务角度的资源和关系梳理，尤其是跨技术专业提供的服务化资源，而不是首要关注专业资源内部细节和逻辑关系的梳理，这部分往往颗粒度过细，属于各个技术专业口，不是CMDB的核心层，应该结合运维人力和技术能力来平衡，避免造成指数级的维护增长代价，可以加强CMDB自动发现能力，也可以采用专业的工具系统来实现外围映射，实现配置细化，如：数据库管理工具Quest、软件配置中心Apollo等。

新一代的CMDB建设要发挥效益，就需要进行有效的治理和消费，保持技术和管理的平衡，集权和分权的平衡，治理和消费的相互促进。与此同时，必须控制好CMDB功能边界，促进消费的服务化，而不是大包大揽的建设，应该注重生态建设，只有消费场景多了，才能反过来促进数据维护治理。比如说云管是CMDB的重要数据源，但对于数据中心来说，云管本身的数据融合度是不够的，需要借助CMDB打通硬件、应用、业务层，才能让容量、容灾等场景有更完整的数据支撑。

| 新一代CMDB的建设方法思考

结合多年在项目中客户CMDB的建设经验和问题教训，我们也和许多业内同仁及专家就CMDB话题不断深入探讨总结，一致认为CMDB要实现运维数据中台主数据这个价值诉求，应遵循分层、共创的建设方法，并落实于工程实践，才能实现围绕业务、融合性、多维度、服务化的新一代CMDB。CMDB的分层设计思路

首先是分层设计，我们知道分层是解构复杂性事务的科学方法，计算领域的问题几乎都通过分层来降低复杂度，如：TCP/IP分层，云计算分层，软件架构分层等，要解决CMDB这个复杂性工程，首先就要具备分层思维，分层落地设计主要包含两个方面：

第一个分层：从CMDB数据维护和价值角度来整体分层，如下图所示，配置管理的数据从内到外应该包含资源目录（基础资源目录）、资源明细（细节部件组件等）、资源关系（部署依赖连接等）、资源图谱（各类拓扑视图）四个层次。 

1、资源目录是配置管理的内核层，是和服务有关的最基础台帐对象，这些台帐设计到各类硬软件基础对象及其信息，但是不过度关注细节。这就类似于人这个对象，我们一般来说只要关注姓名、性别、身份证、是否结婚、籍贯等基本信息，而不太会关注人的四肢器官细节，这些信息一般只有在医院特定场景才去关注。资源目录的模型需要集中管控，数据主要依靠自动发现和可信源同步，人工辅助进行信息完善。

2、资源明细是围绕内核的外围层，是资源主对象的专业化延伸，涉及到资源目录主对象的明细部件、运行组件以及逻辑相关资源对象，这个时候就会关注细节。依然用人做比喻，这时就需要关注四肢等器官组件，穿着的衣服配饰，甚至关心到人的结婚证房产证等信息。对于IT世界来说，资源明细的模型管理既可以集中管控也可以授权分区管控，资源明细的数据主要依靠自动发现，但是细颗粒度维护是一个技术难度挑战，当然也可以利用专业工具负责维护，不做数据统一管理，而是采用基于主资源映射集成。

3、资源关系是前两层的关系海洋，CMDB的核心价值不仅仅是台帐和细节，更关注相互影响，关系海洋中既包含发现的资源明细对象复杂原始关系，也包含经过计算梳理出来的资源目录主对象的关键关系，同时对于技术受限或代价太高的地方，也需要人工维护的关系。同样以人举例： 人与人的同事关系是关键关系，但这个关键关系包含两种方式产生，一种是通过人工相互承认录入，一种是自动通过扫描工作合同明细对象来自动建立。

4、资源图谱是配置管理的用户层，也是真正和运维人员进行交互的层次，资源图谱是通过人所熟悉擅长的方式，对资源进行分门别类按场景组合，进行灵活维护和消费的能力，图谱的体现方式主要包括可视化视图、维护列表视图两类，每个视图都是按照某种场景需求或规则，来维护资源和关系海洋中的某个湖泊，形成各种各样的业务架构、流程架构、部署架构图等，让人可以面向特定场景解决问题，而不是面向海量集合晕头转向，好比我们要去某个目的地旅游，我们只需要拎出旅程的导航地图，而不需要去看全国各地地图。

经过的数据整体分层管理，可以解决传统CMDB管理的分解降维，资源目录是必需保障的核心、资源明细根据成熟度量力而行，关系海洋根据前两层进行计算和维护，资源图谱实现可视化配置场景维护。从管理角度看，资源目录及关系适宜于集中管控，资源明细及关系适宜于分专业考虑，资源图谱适合按场景（跨专业+专业内小组）不断丰富。

第二个分层：从CMDB模型管理治理的角度进行设计分层，如借鉴ITSS的下图所示，配置管理模型可以参考云计算的服务体系来构建，从下到上可以包含管理辅助资源（人员、机构等）、物理设施资源（机房和风火水电）、物理硬件资源（网络系统存储设备）、虚拟资源（各类虚拟资源和容器）、平台资源（操作系统数据库中间件）、应用资源（业务、应用系统、微服务等）等层次。

1、首先，需要从服务化角度来梳理资源目录，如物理设施和硬件的托管服务、IaaS服务、PaaS服务、SaaS服务，需要关注能提供服务的主资源类别，适当简化不直接提供服务的资源类别，这样就能很好的衔接各个专业及其关系，实现业务视角的钻取。

2、其次，围绕资源目录的主对象，建立资源明细部件和对象，这里是需要根据各个技术专业的管理成熟度来定，但对于跨专业的资源服务关系价值不大，比如说：Oracle会关心到表空间、数据文件、ASM、DataGuard等，WebSphere会关注到Cell、Node、Server、Profile等，F5会关心到VS、Pool、PoolMember、iRules等。

3、总的来说，CMDB模型分层是IT架构服务分层的天然映射，从服务角度考虑模型分层，关注提供服务的各层主资源，可以标准化资源目录，实现核心层的先行统一，外围资源明细根据实际情况持续扩展和逐步覆盖。通过数据架构的分层设计，实现从外到内的场景维护，从内到外的治理管控，从上到下的服务化模型设计，可以有效的解耦CMDB建设错综复杂的问题。

CMDB的共创建设方法

共创是解决CMDB的责任和共享的创新机制，传统CMDB是大锅饭，是大家的CMDB，不是个人的CMDB，没有维护的意愿和责任，牵头CMDB的部门往往是流程部门（如调度处），没有办法驱动各个技术专业来有效建设和维护CMDB，而共创是将CMDB的主动权交给各个团队和个人，让大家借助擅长的方式来维护和分享，并最终服务化消费。

回顾现状，运维人员往往都有自己的Excel和Visio来维护自己的小CMDB图谱，而不太愿意受约束去使用交互很差的传统CMDB，所以回归到CMDB的本质就是IT资源对象+关系，在大多数使用场景中，非常适合用图的方式表达，所以第一步需要吸引运维人员的使用，提供良好的图形化、可视化的资源图谱，贴近运维人员的使用习惯，逐步取代个人习惯的工具，替代团队的私库。

我们也会发现CMDB本身的复杂性，所有资源和关系海洋的信息量非常大，我们不可能用一张海量大图来表达，这将过于复杂导致人无法理解，所以资源图谱的高效维护方式是建立各种场景子图，从海量大图中，按照一定的规则或人工来抽取数据，形成各种场景子图，来支撑各种运维场景，如下图所示：

场景子图的外在表现形式就是配置可视化拓扑图，使用者可以定义一个资源，按照关系深度和资源类型约束来自动建图；也可以定义资源范围，在范围内的配置项自动建图；也可以定义某种关系路径，指定路径两端的资源类型和节点，自动按照路劲建图；也可以从第三方模板导入建图，系统自动匹配资源对象和关系建图；也可以人工直接拖拽资源和关系，手工逐步建图。在建图的基础上，可以人工进一步的丰富和编辑，按照配置库的模型约束，完善信息和关系，也可以增加容器分组、标注连线、子图引用，丰富图形的表达能力，贴近人的理解模式。

场景子图的另外一个特点是需要根据图形规则进行自动的提醒更新，其可根据CMDB资源和关系的变化，自动调整图形中的原则，包括删除、添加、修改的可视提醒和自动更新，从而让场景子图鲜活起来，显著降低维护工作量，能够真实的映射生产环境，增强运维人员对图形的可信度。

资源图谱就是由各种各样的场景子图汇总，形成易于理解和消费的图形集合，这些图形既包含应用架构图、应用部署图、业务流程图、网络拓扑图、存储关系图等，也可以包括Oracle架构图、WebSphere集群组件图、F5组件关系图等面向特定专业的图形，每个子图都有所属者，可以设定维护人员和分享范围，并增加评分评论，甚至可进行可信认证，实现资源图谱的共创，让每个部门和人员都有意愿进行维护和分享。

CMDB的消费服务化也是一个需要考虑的问题，传统CMDB提供了资源对象和海洋的接口消费，但是结果往往过于复杂，不易理解和难以集成。关于如何让CMDB更加容易被消费，我们建议放弃大而全的资源和关系海洋消费接口，让资源图谱作为唯一入口，来访问各种场景子图，提供基于Rest的API和基于H5的图形Web接口，以支撑各种消费场景，一旦有新的消费场景需要，也可以反向促进场景子图的快速建立和维护。

通过建立资源图谱为服务入口的CMDB，会让CMDB和第三方工具的消费场景变得更加明确和清晰，比如说告警关联分析，其实背后消费的就是应用的架构拓扑图。另外一个好处，非常适合运维大数据的主题化分析，通过将场景子图作为计算依赖的血缘输入，使得数据计算主题边界可控清晰，分析输出易于检查校验。

| CMDB建设总结

总结CMDB分层、共创的建设思路，其将CMDB的目标重新定义，定位于新一代运维数据中台主数据，通过分层分区、共创维护、场景服务的设计，将治理、维护、服务有机融合，可以有效降低CMDB的建设维护难度，提高主数据质量，提升消费的频率，最终让CMDB名副其实，更好地支撑自动化、智能化的数字化运维发展趋势。