本文缘起
每篇文章都有缘分,本篇也不例外,源于和运维圈内好友,讨论为什么CMDB永远是“不败”的热门话题,每隔几年就会被提及,而且为什么经常看到CMDB失败分析的各类文章。我会在下面内容中解答。
CMDB基础知识
CMDB(Configuration Management Database)配置管理数据库,它包含了一个组织的IT服务使用的信息系统组件的所有相关信息以及这些组件之间的关系。CMDB源自于《ITIL V3》服务转换过程域中的“服务资产与配置管理”。
CMDB是配置管理的核心,更是自动化运维的基石,它为所有运维工具提供基础数据支持,支撑不同的运维场景,CMDB建设直接影响到其他运维工具系统的连通性和数据一致性。
名词解释:
配置项CI(Configuration Item):例如物理机、交换机、路由器、虚拟机、MySQL、Redis、Tomcat这些资源都可以称之为一个CI。
CI模型:每一个CI都需要有自己的模型,可以理解为一个关系型数据库中的表。CI模型由CI属性组成。
CI属性:CI属性可以理解为表中的字段,例如虚拟机这个CI,有以下属性:IP地址、主机名、CPU、内存、创建时间、操作系统等。
CI属性类型:每个CI属性都有其数据类型,可以理解为表中的字段类型。例如MySQL中的字段类型有VARCHAR、INT、TIME、DATE,CI属性类型可以有字符串、整数、下拉菜单、浮点数等等。
CI实例:一个具体的资源对象,称之为CI实例,例如mysql-node1这个MySQL数据库。
为什么CMDB不长久?
有一些文章写的是为什么CMDB总是失败,注意,我这里将“失败”替换为“不长久”,因为其实很多企业的CMDB建设都是成功的,在交付的1~2年可能都是成功的,但是时间长了,感情淡了,相爱的两个人也就远了,貌似跑题了,是因为你建设的可能是一个“静态”的CMDB。
静态CMDB:仅仅是资产、资源的一个集中管理的数据库,依赖于人工维护,即便有自动采集和自动比对,也无法解决数据不准确的问题。这样的CMDB是静态的,是死的,是没有灵魂的...。
动态CMDB:在静态CMDB的基础上,CMDB可以和其它运维系统如监控、作业进行紧密的结合,CMDB可以与具体的运维流程进行配合,可以由具体的场景驱动CMDB的数据CRUD。这样的CMDB是动态的,是活的,是具有生命力的...。
动态的CMDB为什么也不长久?
有很多的企业的CMDB是有生命力的动态的CMDB,但是为什么依然还是不长久,原因也有很多。而且都是多方面的原因,我只能列举一个单独的例子,例如如果设计的CMDB中CI之间的关系存在下面这些:运行在、放置在、依赖于、连接在、从属于。这可能就会不长久,有人会问为什么?传统的CMDB不都是这么设计的吗?
现在你眼睛离开手机,想一下,虚拟机和物理机是什么关系,从以上关系中选择一个作为你自己的答案。
你的答案是:__________________
然后你也可以问问周边的同事,你会发现,上面的所有关系,貌似都能说的通。我在400多人的微信群里做过调研,有近100多选择了从属于、还有100多选择了运行在,而且还有很多人选择了放置在、依赖于和连接在,而且他们选择的理由我竟然无法100%反驳,例如我个人就认为“放置在”不合适,但是虚拟机放置在物理机上,也不能算就一定是错的。我相信你自己也找到了答案,就算是你的CMDB供应商为此专门进行培训,输入产品设计时的关系定义,但是只要有人员变动,或者有新的CI加入,没有经过培训的人就无法正确的使用CMDB。所以你会看到这种说法:CMDB本身并没有错,错的是使用者?至少我不这么认为!
多年来不同的企业都在尝试解决这些问题(上面只是一个例子),但是如果是建立在现有的解决方案上面的改进,还是不能有效的解决这些问题,也许【第一性原理】可以帮到我们,我带着大家一起来尝试一下。
什么是第一性原理?
用最通俗的话来解释什么是第一性原理,就是在当前事物设计和创新中,我们会习惯于站在前人的肩膀上,通过比较思维去思考问题,在别人已经做过的基础上进行迭代发展。而第一性原理告诉我们,需要用物理学的角度看待事物,透过表象看到本质,然后在从本质一层一层往上走。
针对第一性原理在CMDB中的实践,通俗的理解就是,我们不需要关心之前互联网前辈们的CMDB是如何设计的,别人的解决方案是什么,也不要参考或者在已有的解决方案之上的修改或者创新,而是从CMDB的本质上进行思考如何解决这些问题,这样就有可能会有新的,真正“正确”的解决方案。注意只是有可能,尝试总会遇到各种失败,但是不尝试,永远不可能有创新。
由于篇幅问题,我下面通过两个CMDB设计中两个具体的案例来阐述第一性原理的使用。
1.如何设计CMDB中关系
毋庸置疑,在CMDB中,CI和CI的关系可能会像下面这样,是一个非常复杂的关系,有的企业在尝试使用图数据库来存储CI和CI之间的关系,因为本质上CI和CI之间的关系就是一个图,但是这并不能说明解决了CI之间的关系问题,因为如果呈现给用户是下面这样一个CMDB关系,我相信用户除了赞叹一声:「我靠,真牛掰」之外,会接着打开他的EXCEL表进行资源的管理维护。
从CMDB的CI与CI的本质上讲,他们是连接在一起的,属于那种剪不断理还乱的关系。可以从人类世界来考虑关系,例如人有父母,有朋友。我就在想是不是所有的CI都应该有一个父亲,例如虚拟机,它的父亲是物理机,物理机的父亲是机柜,机柜的父亲是机房。那么这就组成一个树,树形关系应该是存在于所有工程师的认知里,例如DNS就是一个树,我们的Linux文件系统也是一个树形结构,甚至每天常用的Xshell工具,我也习惯使用树视图。
我把CMDB的关系分为两种关系,父子关系和连接关系,如何区分呢?
父子关系:当两个CI在逻辑上有强依赖关系的都称之为父子关系。例如虚拟机的父亲是物理机,因为虚拟机不可能凭空创造出来。父子关系大概可以表达CMDB中80%的关系。
连接关系:除了父子之外其它的所有关系都称之为连接关系,例如物理机和交换机,他们之间没有强依赖,这就是连接关系。例如交换机和工程师张三,也是连接关系,张三可能是交换机的负责人。这就像你把所有除了父母之外的关系都称之为朋友。
关系标签:通过上面的拆分之后,CI和CI之间的关系就只有两种了,但是你会发现很多CI之间的关系都是连接,如何快速的寻找到某种类型或者某种意义上的关系呢,答案是通过给关系打标签。例如微信通讯录上就有标签的功能,通过标签你可以给你的朋友进行分类,例如我的微信通讯录会有(同事、好朋友、铁哥们、能喝酒的、合作伙伴、老领导、战友)等非常多的标签,那么通过标签你就可以给CI之间的连接关系进行标记,例如物理机和交换机的连接关系叫做网络连接,物理机和员工之间的联系关系叫做管理连接,A服务和B服务之间的连接关系叫做服务调用等等。
虚拟CI:当然这里面还有非常多设计的小细节,例如MySQL可以运行在容器、虚拟机、物理机、云主机等CI上,也就是说MySQL可能会有了多个父亲,但是MySQL和虚拟机之间的关系确实是父子,因为有强依赖,连接关系不合适这种非常特殊的情况。这里我引入了“虚拟CI”的概念。例如【主机】就是一个虚拟的CI,在实际的模型之间的关系设计中,MySQL的父CI是【主机】,这样在数据录入的时候,你可以从虚拟CI【主机】的物理CI(物理机、虚拟机、云主机、容器)中选择一个实例作为MySQL的运行主机。
2.如何设计CMDB中的CI属性
CMDB中CI的属性可以理解为表中的字段,就像一个人,他有姓名、身份证号、性别、身高、体重。我把CI的属性总体分为三个类别。
普通属性:就是手工录入或者自动采集的CI属性,不需要动态修改的CI的基本信息。例如姓名、身份证号等,普通属性的修改可能就会涉及到走变更流程,就像如果想修改身份证上的姓名,也需要有一个非常复杂的流程。
关系属性:父子关系、连接关系、无关系。关系也使用CI属性来进行表达。其中这里的无关系是指两个CI模型之间进行一个引用,但是并没有具体的关系。
动态属性:动态变化的,需要依赖于其它系统进行更新,而不是手工维护的。例如一个主机有一个字段叫做【运行状态】,这个属性就应该是动态的,不需要人工维护,而且通过监控平台实时的进行状态的更新。
3.如何构建可以持久的CMDB?
这是一个比较大的话题,从实践中我总结了一个CMDB的3C建设方法:
Core:核心,首先需要建立一个以CMDB为核心的一个完整的,可以自动采集和定期做数据校验的一个静态的CMDB。
Connection:连接,把CMDB的数据消费起来,要使用它,不仅仅是简单的搜索和查询,而且要通过CMDB把自动化运维的不同工具链打通,连接起来。通过不同的场景来消费CMDB。
Closed-Loop:闭环,在连接的基础上,还需要形成数据闭环,保证CMDB中的一个资源对象完整的生命周期的管理,同时也可以反推其它系统进行流程化的完善。
CMDB的话题太大,所以即便写了3000多字,依然觉得有点少,今天先到这里,夜深了,回头再续。
提醒:
近期有两个技术分享,9月29日20:00(今天)的线上分享和10月24日,深圳腾讯滨海大厦由腾讯蓝鲸主办的线下沙龙。可以关注公众号后,查看推送的报名方法,免费报名。
世间多少纷扰事,浮华落尽总随风。关注我们,一起默默成长。