从身份证管理系统思考企业CMDB的建设

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

对大部分中大型的企业来说,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才发挥价值!

​​​​

上一篇:java – Lucene – 检索文档中多值字段的所有值


下一篇:不可思议的纯 CSS 滚动进度条效果