---

2023年3月21日春分时节，优维结合在CMDB技术领域的经验沉淀与洞察能力，梳理金融客户在数据运营中面临的问题和挑战，为了帮助到广大客户建立健全有效的方法参考，全新策划了一档“CMDB数据运营精准化专场公开课”线上直播课程。该系列课程的第一节课，邀请到了优维科技创始人兼CEO王津银坐镇直播间，担任第一课主讲老师，为大家讲述了“新一代CMDB落地的困境与出路”，深受直播间观众的好评。

下面，就跟着鹿小U一起来回顾本期直播课程的主要内容吧，你将会获知到以下内容：

1. 在落地上面的困境到底有哪些问题存在？
2. 为什么取名叫新一代CMDB？
3. 新一代到底是什么？怎么去理解这个新一代？
4. 新一代CMDB的出路又在哪里？

一、当前CMDB建设面临的困境

关于当前CMDB建设面临的一些困境，将从以下几个问题方面来阐述：

01. CMDB的认知问题

直到今天我们在接触客户的时候，依然从客户那里能听到什么是CMDB？

我们把CMDB定义成台账，定义成一个资产管理或者叫配置管理平台。这些认知到底对不对？如何从管理CMDB的一些视角以及定位？我觉得这个其实是认知的问题。我希望通过今天的分享，未来在与更多客户交流时，能够把话术体系全部统一，从而解决大家对CMDB的认知，比如CMDB到底应该是什么东西？它的定位到底是什么？这里我先把问题抛出来，往下看会有答案。

02. CMDB平台自身的多角度问题

第二点就是说今天CMDB平台自身建设上面，其实存在很多角度的问题。

• 聚焦底层资源
• 我觉得聚焦在底层资源和关注laaS层资源的建设管理的视角，其核心点是由今天这个运维的角色本身它的视角关注点决定的，所以能够看到我们很多客户CMDB的建设发起的部门依然是来自于底层的基础架构部门，这其实是过去的主架构以及管理视角的核心点决定的。
• 无应用视角
• 这个我之前经常举的一个例子是说今天运维部门分配主机出去之后，接下来整个主机的业务运行状态上线了，整个生命周期的管理在业务侧，那基本上就认为可以，因为基本上就不管了，那我认为这恰恰到核心的管理控制点，应该从应用的视角去看，后面的模型建模思路上面，我把这个点也给大家去构建起来，并且给了一个非常详细的例子。
• 模型的动态性不强
• 我觉得模型动态性不强，在于我们建模是比较偏向于静态的模型。这个模型在过去也有因为技术的原因，导致这个模型的扩展难度非常大。特别是实例级的动态性更是为无的。什么叫实例级的动态性？即CMDB在管理另个核心模型时定义一个个资源对象的，那这个资源对象模型里面装载的是很多实例数据，这个数据怎么样去基于生命周期的视角来管理，我觉得这里面是一个全体系化的。
• 场景的过渡设计
• 今天在CMDB的整个模型的过渡设计时，大家过渡的纠结CMDB模型设计的细粒度，而这反而增加管理的负担。那在今天的实施方法论上，是逃过CMDB设计细节的环节。那跳过这个环节之后，如何保证CMDB模型的准确性，会有一个全新的方法论，往下看会告诉大家。过去，大家在梳理CMDB模型的时候，大家都有一个单独的STAGE去梳理，花费了大量的时间，结果发现最后也没有起到很大的作用。这就是常提到的，从简到到繁琐容易，但从繁琐到简单其实非常难，当我们把那么多的字段、数据、属性或关系塞进去之后，再去去简化，其实这个动作做起来是非常难的。
• 技术限制想象力
• 我觉得技术上其实也限制了我们本身的想象力，这里面提到了两点，就是北向和南向的问题。
• 北向指的就是整个平台的开放性，比如API能力的开放性，而API能力的开放性不仅仅是聚焦到实例级的，还要上升到关系级别。大家也知道CMDB整个资源质检的饿关联关系时错综复杂的。如何定义图API？而图API怎么不去懂平台本身，让平台自身都定制？我觉得这一点是非常重要的。
• 南向指今天这么多的数据，通过一些接口，和一定的自动采集进入平台，如何高效的去存储，选择什么样的存储方案，这一点非常重要，特别是在建模上面，做过技术的人都知道，是非常难以扩展的，那今天我们如何去突破这个技术限制，则需要我们选择一些新的技术方案。
• 欠缺IT架构思考力
• 在当下有很多典型的模型架构，从业务架构到应用架构到基础架构，它们之间的关系到底是什么？基于这三层架构，怎么去管理它们之间的逻辑关系，思考清楚这些也非常重要。技术问题还是要回归到技术本身，不能够纯粹从简单的一个CMDB问题去看待，同时要回归到业务上面去，从映射的维度对应到架构层次上去。

03. CMDB系统的建模问题

CMDB世界的实体关系如何被建模？这虽然是一个分层复杂的问题。但是，简单的理解来讲，无非是两个方面，一个是属性，一个是关系。关于属性其实很简单，对于一个实例来讲，只需不断的去扩展它的属性，定义它就可以。而它的关系怎么去被建模？这个关系建模到底应该遵循什么样的原则？比如说，主机到底跟外部的资源实例之间表现出什么样的模型关系和实例级关系，这其实需要一个全新的建模思路。

对CMDB发出的两个灵魂拷问：

第一个是必要性，即今天真的有必要建设CMDB吗？在当下复杂的IT环境下，比如存在云原生，K8平台，多云管理的情况下，还有必要去建设CMDB吗？

第二个是准确性，准确性是一个非常模糊的东西，我认为它归根结底是结果性的问题。那这个结果性需要被倒推回去，这个准确性到底是因为哪些因素决定的？因为这个准确性的要素是什么？只有把这些要素找出来之后，才能够去谈怎么去确保数据的准确性。

以上CMDB面临的三个困境，在接下来的内容中，都可以找到一些答案。

二、CMDB的术语统一（认知）

在实际的落地场景中，对CMDB的认知存在一些混淆概念，那这个混淆该怎么去解决，可以从术语统一上解决认知的问题。

01.宏观概念阐释

在前面讲了三个概念是很容易被混淆的：

第一个是台账，对日常的工作资料进行加工整理和总结，是一个偏静态管理概念，范围、管理方式和用途等不确定。

第二个是资产，与成本有关系，IT软硬件资产都可以纳管，用途：财务和运维。

第三个是配置，这是一个容易混淆的概念，ACM、SCM等。CM缺少定语，带来范围、管理方式和用途等不确定。

针对以上三个混淆的概念，需要拨乱反正，从新诠释CMDB到底是什么？就当下而言，我觉得CMDB就是IT资源管理，管理一切资源，而资源及服务、生命周期。

02.模型设计原则

以服务为中心来构建模型，不断细分和往外扩展管理边界。

从使用者和生产者两个不同的视角对业务的构成进行组织 ，并梳理与服务的关系。

对服务的资源构成进行分解，把所有关资源及资源间的管理统一进行纳管和维护。

当初在行业里面推广CMDB时，提了一个面向应用的CMDB的概念。从下面这张图，以一个银行落地的系统，从两办三中心的视角，即项目办、架构办、开发中心、测试中心及运维中心五个视角，把这条谱打开。

从架构办的角度来讲，典型的就是架构层次，细化到它的应用系统力度上面，有系统、和子系统。那对大一点的系统来讲，它会有很多的子系统，对小的系统来说，比如像OA，它其实没有太多的子系统概念。所以，直接到底层，可能就是一个个的服务单元。第二个就是说服务单元里面，我们对外提供了很多服务接口，接口本身API也是一种资源，那这个资源其实可以延伸到测试中心里面去，最终跟测试中心的测试功能等等之类的能力去对接。第三个维度就是今天的部署资源，这个实例其实是有程序包、配置、依赖库......基于这个维度，可以从项目管理的级别，把它的制品、配置包、依赖库等等可以统一的进行管理起来。

基于应用和服务单元，怎么在整个全生命周期的过程里面把所有的资源给拽出来。从整个管理的视角，一定要聚焦到上层应用，以它为中心，把相关服务环境的资源，接口的资源，部署的资源全部给它构建起来。最后从整个业务的运行形态来讲，从它的交付态到它的运行态，基本上把它所有关联资源都给清理出来。

从上图可看出，从整个立项到研发，到构建，到测试，到发布，再到运营，通过这样一个生命周期的过程，怎么把关联的一些资源全部给链接牵引出来的一个过程，由此构成了某个服务单元的全资源的视角，这其实就是今天讲的面向应用的，无论是从模型的角度，还是从全生命周期的角度，我们把这个能力体系给构造出来。

相关术语的说明，我们也做了很多的澄清，也做了一些定义。

三、CMDB实体关系如何被更好的建模

面对纷繁复杂的关系，比如模型级的关系，实例级的关系，该如何被更好的建模？

01.首先，我们需要先弄清楚新一代CMDB到底新在哪里？

新一代CMDB其核心新在思维、方法、技术、模型四个方面。

• 新思维：突破配置管理的配置认知，导致便捷不清，配置往IT资源方向转变。
• 新方法：自上而下的推动CMDB落地，而不是自下而上。
• 新技术：新的技术，使用新的技术，新的功能架构，重新定义功能边界。
• 新模型：模型重构，传统的关系模型无法满足动态关系的建模需求。

02.CMDB=IT系统平台的数据地图

今天当我们去讲IT资源管理的时候，可以把它形象的映射到IT系统的数据地图上面去。之前也跟大家讲过，与其说在建设CMDB，倒不如说在建设一个资源图谱。资源图谱的本质其实就是IT资源的数据地图。

数据地图里面有几个概念：

一个是标点数据，对应的是实例数据。比如说公司在哪个城市，哪个地方，一定在地图上是有个标点的。

第二个就是从公司到某个客户那里，就会形成一个地图路径，也可称之为叫关系，一旦有了实例数据和实例关系之后，那这个数据地图就能够去承载更多系统的应用。

03.图是复杂、动态关系最好的表达

早期我们在做CMDB的时候，意识到一个问题，就是今天在建设CMDB的过程，其实是在描述资源以及资源之间的关联关系，也就是今天讲的新技术，即图数据库。

图数据库，是一个很好的工具，它诞生的场景，就是为了解决社交化图谱的问题。直到今天我们依然在用图数据库，在很多能力构建上采用了图之后，在建模上面，在关系描述上面，其实很多问题就解决了。上面讲到的南北向的问题也能很好的解决

04.功能架构

说实话，一直觉得CMDB的功能架构其实超级简单，可以把它当成一个DB存在。整个CMDB系统里面会需要一个采集平台，上层有一个数据开放平台，中间就是一堆存储。在CMDB引擎里面可能提供实例级的存储以及提供关系，同时还要加一个数据建模。从上图可看出，CMDB系统的功能架构非常简单。

05.软件架构

从软件架构上来说，有一个核心对外的点，就是数据的整个提供上面来讲，有几种机制需要非常注意：

第一方面就是它的API的开放性，这是一种全量、非实时的同步机制，这个模式对于今天来说，做一个业务系统是很好实现的。

第二个方面就是数据的增量更新上，一定要保证有个预补通知中心。通过通知中心去做数据的订阅与发布，确保外部系统能够实时感知到CMDB的一些数据变化。这就有点像数据库的全量和增量备份机制，一定要保留，且一定要有这两个能力。

06.技术方案建议

• 系统架构：微服务架构
• 前端技术：JavaScript，HTML
• 前端框架：React.js
• 后端技术：GO，JAVA
• 后端框架：Spring MVC
• 通讯协议：HTTP，HTTPS，Protobuf
• 数据协议：JSON
• 数 据 库：EasyGraph（图数据库）
• 公共组件：Nginx
• Agent端：Go

上面说这么多，其核心就是说资源和资源之间的关系，构成了类似图谱的能力，上面用IT地图的概念和大家做了一个比喻。既然资源图谱的核心概念出来之后，再回到技术选型上，图数据库当初是为了社交化图谱应用而生的，那在解决资源图谱的问题，图数据库也很合适。有了这样最核心的技术选型之后，能很好的解决南北向一个数据入的问题和一个数据出的问题。从我们多年CMDB建设上来讲，可以很骄傲的说，今天我们做了这么多CMDB项目，其实我们的图、API的定制是为零的，而这正是图数据库带来的效益。

四、CMDB模型的标准化框架

01.两层CMDB，构建不同管理视角

CMDB架构分基础资源层架构和应用资源层架构。应用层资源架构把相关的资源以应用为中心实现资源整合，资源及其资源的关系称之为拓扑（应用拓扑、物理拓扑）。资源管理方式有人工维护和自动发现两种方式，流程是人工维护的一种复杂场景和手段。

02.应用CMDB模型层次化理解

标准化模型及关联关系，面向应用CMDB，定义行业模型规范。

提供行业标准化模型，支持基于标准模型进行调整，以适配企业内部的资源管理要求，解决数据的标准化、覆盖面问题。

03.应用层对象（服务）模型核心概念

应用整个资源对象的话，其实模型的核心概念大概分成三个层次。

从上往下看，第一层是要对外提供一个服务，这个服务包含两部分，一个是自有服务，一个是依赖服务。自有服务是由应用整个程序包在运行态的状态下面表现出来的依赖服务。第二层是应用实例，包含自有实例，应用包的整个程序的实例化，也就是它running起来之后占用了哪些IP和端口；依赖实例就是依赖组件实例化，对应第一层的依赖服务。第三层就是这个实例到底运行在哪个主机上面，在K8S里面，主机的概念被弱化了，而是说运行在哪些集群里面。

04.PaaS层对象（服务）模型核心概念

PaaS层对象模型和应用服务对象的模型，其实是没有多大区别的。

中间件服务可能对依赖的整个服务上面，其实它是非常简化的，那在自有服务的整个抽象和提取级别上来说，同样是三个层次，第一个是服务，第二个是组件实例，第三个是主机。

05.IaaS层硬件对象模型

IaaS层整个硬件对象的模型基于每个对象实例化描述就可以了，无非就是属性和关系。这个逻辑超级简单，就是今天你拿了一个交换机，你要管理它的一些基本属性，管理它一个端口属性基本上就可以了。而这个东西的提取其实是很容易的，无非就是说在这里面可能就是基于Mac地址怎么去关联到主机对象上面去，所以硬件对象它整个服务化的属性不强。

06.软件定义对象模型的三层、四层和七层

自上而下，再一次对应用资源对象的概念再具体化。

• 首先，服务这层，称呼为应用提供的一个API。那API是什么？API其实是一个IP+Port+服务的七层概念。
• 其次，是应用实例，这一层称作为服务节点。那实例是什么？就是IP+Port，是一个四层的概念。
• 最后，是主机这一层，其实就是一个IP地址，即三层的概念。

那针对这几层的概念到底今天我们应该怎么去应用？

从上图看出，

• 七层是能够帮助我们去生成整个应用架构的一些视图。应用架构图通过七层API的执行服务调用管理，特别是基于可观测的服务链路追踪，能够通过应用架构图这个技术手段动态的生成出来。
• 四层就是服务节点之间的访问视图，对应网络访问四元组。
• 三层就是组件IP地址，其实这一层解决的是应用部署视图的问题

上面讲了很多CMDB模型标准化的架构相关的内容，其本质上，是从认知的困境出发，针对CMDB整个资源层次架构的划分，应该从架构的视角上去看，不能够简单的以碎片化的从资源孤立的维度去看，否则会缺失更上层的宏观视角。关于CMDB模型的标准化架构，以例子来分享，其目的是希望大家在构建整个CMDB资源图谱的时，能够带着完整的架构视角来看，如何把资源层次以及资源之间的脉络关系给梳理清楚。

五、CMDB准确性如何被理解

从实施的角度来讲，今天在跟很多客户交流沟通过程中，达成了一个广泛的认识，我们把这个认知做了一个全面的梳理，新一代CMDB该如何落地。

01.新一代CMDB的落地实施框架

• 第一个阶段是现状评估，需要对资源状况、流程架构、技术架构、组织架构做一个全面的评估。
• 第二阶段是CMDB项目启动，一方面是不能带着不同的饿认知来看待CMDB，要做一个广泛的宣导，统一CMDB术语。另外一方面行业最佳模型的导入，看数据效果再迭代优化，调整模型。
• 第三阶段是CMDB数据实例化，因为在第二阶段已经梳理了模型的数据来源方式，搭建CMDB测试环境和成产环境，导入CI模型，编写自动发现程序生成数据，CI数据实例化人工生成。
• 第四阶段是CMDB线上运维，要做好五个方面：检查CMDB数据导入情况，Owner确认数据的准确性，导入生产环境，CMDB运营推广宣导（平台、数据、场景、制度、规范）等，CMDB建设持续迭代升级。
• 第五阶段是持续场景消费，这一阶段包含六个方面：支撑ITSM管理流程、CMDB数据可视化（包括3D）、自动化运维和DevOps、数据化运营（监控+IT运营分析+数据分析）、安全、智能化运维（事件、分析、变更、故障、容量）。

改变过去的实施模式，重新导入上面这样一个实施过程，其目的就是从实施的角度，从框架的角度，希望CMDB能够真正的落地，而不是想过去一样

02.打造CMDB场景消费地图

这是一个场景消费地图，结合组织现状，可以围绕它的场景维度不断的去细化。

03.CMDB不是DB，而是运维业务平台的底座

CMDB能够成为这么多业务平台的底座，有两个问题必须解决掉：

• 第一个是统一模型OneModel，必须在众多资源里、众多平台里面，让CMDB用一个模型去描述所有的资源对象。
• 第二个是统一实例OneInstance，每一个实例对象，需要产生一个ID，这个ID在未来会被带入到不同的应用系统、业务系统里面，比如事件平台、告警平台、数据采集平台等等，有了ID，就有模型关系，才能够真正构建一个数据地图。有了数据地图的基础，故障病因查找、故障定位等等就会简单很多。

解决好上述两个问题，CMDB才能作为运维业务平台的底座，被广泛的进行上层场景的消费。

以上，这一节课的所有分享，让小伙伴们重新构建了金融CMDB数据运营的一个完整的知识体系，同时结合了自身的实战经验去剖析了CMDB的底层逻辑，提出了新一代CMDB的时代本质，更是坚定了金融行业对CMDB的信心和贯彻的方向，这一点是尤其具备指导意义的。另外，在对新一代CMDB的落地论述中，从技术、模型、实施以及运营层层递进，为我们深入浅出的讲解了CMGB场景的驱动数据运营，也赋予了本次公开课厚重的技术价值和落地的指引。我想报名参与了这节公开课的每位朋友，应该也都在各自的知识维度上有了不同程度的启发和提升。

六、Q&A问答环节

Q1:CI生命周期流程是人工维护，还是自动维护？

老王：流程就基于ITSM的服务目录、变更去梳理就好了，不存在是人工还是自动维护的问题。当然我就在前面讲了，流程一定要跟底层的能力平台有互动性，就是说跟CMDB，跟变更，跟自动化等等这些能力平台要有互动性，只有这样才能够确保流程对一些作业以及它的变更的结果能够对配置进行修改。

Q2:怎么保证多个数据来源导致上报数据格式不统一问题？如有的上报LINUX，有的报linux导致数据的反复变更,数据质量怎么保障？可否稍微剧透下

老王：其实我觉得在这个数据来源分析上面来讲，CMDB作为一个后来者，它其实会遇到这样的一个问题，比如说我过去做了一个保险的客户，就遇到了这个话题，有些信息是来自于以前老的CMDB系统，有些信息来自于网络平台，有些信息又来自于监控平台，首先我觉得这个做法本身它其实就是不合理的。特别是在整个自动发现核心的逻辑上来说，我觉得这种数据清洗转换，保证数据统一的问题，这个本身不合理了，如果你在第一次初步数据割接的时候，你还可以初步初始化的东西，还可以这么去做，但是随着系统的常态化运行，这样的做法其实是非常错误的做法，应该是反过来，数据首先是进入到CMDB平台，然后怎么让CMDB平台把这个数据共享给其他的消费端。

Q3:人工智能对CMDB有哪些机会和挑战?

老王：对于底层CMDB平台来说，我觉得人工智能对它的影响是非常小的。那对于运维平台来说，也没有太多结论。最近跟一个客户在合作的过程中，他把自己的业务能力，平台业务的场景固化到AI里面去了，把底层复杂的系统入口全部对外屏蔽掉了，我们都知道某个系统承载了很多角色，所以那个系统设计的复杂性，它是基于功能的维度，所以大家都在诟病说To B的系统底层的用户体验怎么这么糟糕。当然其实也有一些解决方案，说实话大部分这种To B系统及解决方案是很弱的，所以最终会围绕某些角色，把这个能力固化到AI里面，以某种形式存在。

Q4:CMDB对外提供数据如何保证数据安全？有哪些比较有效的权限控制措施呢？

老王：数据安全我觉得这个话题，其实也是我们做了怎么多CMDB平台里，大家最关心一个核心点。CMDB平台本身不仅要聚焦到功能级的安全上，还需要聚焦在整个数据实例级的安全上面。一旦聚焦到数据，数据实例及安全上，其实整个系统的复杂性是在的，这个数据对外提供上面，我觉得其实这个问题相对来说还好一点，控一点就行。接口一定要加上访问的限制，就是谁来访问你的数据，什么时间访问你的数据，首先你要有授权的机制，你要给他发个token令牌，那他拿到token令牌的时候，他才能够去访问你的数据，最好这个数据在CMDB平台内部也标识一下它的整个系统来源，系统名称，申请人等等这之类的，由此你拿到它以后，在整个数据鲜活性访问分析上面，你可以基于它去做分析的，否则你可能提供了一个开放式的API给别人，最后人家把你数据拿走了，你也不知道谁拿的，你只能看IP地址，看IP地址你再去问别人说这个到底是谁，那我觉得这个方式其实也是不合适的，所以这个是接口级的一个授权，授权访问和内部访问，需要标识是谁来访问的。

第二个问题，就是说到底它能访问哪些数据。我觉得这里面你可以定义一些整个数据集的权限，比如说这个主机表你是能够被它访问的，那非主机表是不能被他访问，这个主机上，这个接口上可以做一些控制和限制，这个可能要映射到我们后台的那些能力接口上面去。其他的我觉得，其实内部的整个运维的一些数据，这类资源数据其实安全性，可能也没有那么的高，不能过度复杂化这个问题，毕竟不是一个业务的数据，它也不是公司经营的核心数据，我觉得没必要把它搞得那么复杂。

Q5：CMDB与ITSM的服务目录，知识库等的要素的关系如何界定？如何关联起来协同工作？

老王：第一个问题服务目录该怎么去梳理，在一个运维组织里面，其实角色首先第一层，要看到你的组织角色，比如说网络的角色，存储的数据库的角色，那这些角色在公司里面，他每日的活动到底是什么？你其实只要追踪一段时间之后，这个答案就出来了，比如说我给人家开网络权限，我给他扩硬盘等等之类的，其实这个东西最后就形成了一个服务表。根据这个服务表，可以把整个服务流程定义出来，然后把它格式化，对外的整个服务的标准输入定义出来，往后的整个自动化作业的工具定义出来，这个服务就出来了。

第二个你刚才讲的什么知识库，其实我觉得知识库相对来说比较孤立，听从它本身的流程来讲，今天处理了一个故障，处理了一个事件，处理了一个问题，我可以把它转换成知识库，知识库整个维护，这块代价蛮大的，我觉得知识库其实也要关联到不同的角色上去看，比如在研发类的角色上面，他应该输出什么样的知识库，对于我的整个交付类的角色，我应该输出什么样的知识库，对于开发运维来说，我们应该输出什么样的知识库等等之类的，这是蛮复杂的问题，所以在知识库应用上面，我们现在用的基本上是外部的一个产品语雀来做。

Q6：可以分享一下变更与CMDB集成的最佳时间吗？就是在变更过程中修改CMDB数据，还是变更后通过自动发现去更新CMDB呢？

老王：变更的CMDB集成的最佳时间，第一个层次，我觉得大家要知道，今天变更的过程中，已经不像过去那样出现变更单了，今天的变更要把每一步的表单的输入输出要格式化掉，不能够再像过去那样提供一个member，里面输入一堆的文字，由人去判断，因为机器没有人那么智能，我觉得这个是一个大的前提。

另外一个是CMDB集成的这个最佳实践，你在变更执行的过程中，其实你去修改CMDB一定是没有错的，自动发现在发现回来的时候更新，其实那个数据最终也是那个数据，我们唯独有一点，就是说我们今天没办法去通过这种自动更新手段去触达到的，基本上是流程去保证，那有些就留给了自动发现，比如说从CP里面分配一个主机给某个业务，这个时候让自动发现把它上报上来就完事了，毕竟主机级的很多字段，不是在流程里面去填充进去的。所以，流程那边顶多填充最终生成了一个IP地址，最终这个信息自动发现回来，还有很多额外的信息，比如这个机器上的用户运行的用户数组、用户运行的进程等等，其实都是通过自动发现回来。就是说在流程里面能够提供的信息是有限的，但自动发现可能会提供回来的信息是非常全面的。

Q7：CMDB厂商之间是平台技术区别还是建模思路以及实施的区别？

老王：有几个阶段就是区别，这几个阶段倒不是在简单的功能和技术上面的区别。第一阶段是理念的区别，第二阶段是在技术站上面的区别，第三阶段是精准运营的区别。

以上就是本节课所有的内容以及问题的解答了，这节公开课在很大程度上也消除了大家对CMDB合理性的一个质疑。本次公开课是系列课题，预告一下下次课程我们将会在四月下旬为大家带来「CMDB数据运营精准化公开课」第二场谷雨篇的分享，相信大家将会接收到不同于今天的精彩，让我们相约四月，不见不散！

---