关注嘉为科技，获取运维新知

对大部分中大型的企业来说，CMDB建设对于整个IT服务和IT运维管理的重要性不言而喻，但是目前仍然有非常多的企业无法建设好CMDB。

我最近刚好接触了一个*系统的朋友，他和我聊了关于身份证管理系统。聊完，我恍然大悟，这套思想和我们企业CMDB建设的思想几乎一摸一样。

1
CMDB中管理的CI属性不是越多越好

 

只有被大量系统消费的数据才需要放到CMDB中。

在生命周期内不容易变化的数据，我们可以理解为“静态”配置数据。

对比身份证管理系统：身份证上不会把我们个人的所有属性放上去，比如年龄就是一个状态数据，而出生年月是一个静态数据。

2
保障CMDB数据准确性的核心要依靠消费和流程

 

配置自动发现功能对于CMDB的确重要，能有助于我们配置数据的初始化和配置数据的审计，但是我们不能依赖自动发现保障数据的准确性，更不能期望所有的属性、关联关系都通过自动发现来实现。

配置数据的准确性需要靠消费场景，只有通过消费场景，我们才能够及时发现配置数据的错误；发现了配置数据的错误，我们才能够及时对配置数据进行修正；这样就会形成一个正循环。

人员手工操作永远是不可靠的，配置数据的准确性需要靠流程。只有靠流程和工具，才能保障配置数据的准确性。比如资源申请需要经过流程审批，资源完成交付后，工具可以将配置数据自动化注册到CMDB中。

对比身份证管理系统：身份证管理系统目前并没有线上自动化采集的功能，完全是依靠消费和流程保障数据的准确性。如你的身份不准确，你的驾照、社保系统都是无法使用的，甚至你入住酒店、乘坐高铁都是不可以的；另外我们的国家制定了一套完整的身份证管理流程，包括身份证的创建、更新、过期等一整套生命周期管理流程，并且有*局这个机构负责管理。

3
以资源为中心的CMDB演变为
以应用为中心的CMDB

 

无论是以资源为中心的CMDB，或是以应用为中心的CMDB，都是从业务需求的角度出发，对CI对象以不同的形式进行组织，对CI和CI的关联关系进行管理，CI的本质并没有变。

过去，企业的应用架构大多是单体应用架构和分层应用架构，资源和应用之间的关联关系并不复杂，一台物理服务器可能就承载了一个或多个应用。此时，我们采用以资源为中心的CMDB并不会给企业的运维管理带来什么影响。

但是，现在企业的应用架构发生了非常大的变化，分布式和微服务架构在企业中开始普及，应用和资源之间的关系变得复杂，目前更多的是一个应用对应多个虚拟机和容器的情形，并且应用关联的虚拟机和容器经常是变化的。此时，以应用为中心的CMDB建设就变得比较迫切。

对比身份证管理系统：在70年代，各省的身份证管理系统是以省为单位构建的，而且没有实现全国联网，*局在追踪人员信息的时候经常只能获取到人员的家庭信息，很难获取到人员准确的公司信息。

到90年代后，身份证实行全国联网，公司通过身份证为员工缴纳社保和税收。*局通过身份证就可以追踪到人员的公司信息，实现更多的犯罪分析的场景。

因此，企业在建设CMDB的过程中，重心不是选择什么样的CMDB工具，也不是规划CMDB的模型及属性。

重心是像我们的身份证管理系统一样，先定义清CMDB在IT运维管理和IT流程管理中的角色和作用，定义清楚CMDB数据管理的负责人和流程，设计的其他运营工具要能够消费CMDB数据，这样CMDB就容易建设成功，并且很容易发挥价值。

CMDB本身不具备价值，只有产生消费，CMDB才发挥价值！

​​​​