本文缘起
每篇文章都有缘分，本篇也不例外，源于和运维圈内好友，讨论为什么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本身并没有错，错的是使用者？至少我不这么认为！
多年来不同的企业都在尝试解决这些问题（上面只是一个例子），但是如果是建立在现有的解决方案上面的改进，还是不能有效的解决这些问题，也许【第一性原理】可以帮到我们，我带着大家一起来尝试一下。
什么是第一性原理？
请注意，前三个字需要连起来读。第一性原理是一个哲学上的概念，它的首创者是亚里士多德，之所以被大众所熟悉是因为SpaceX、特斯拉公司CEO埃隆·马斯克（Elon Musk）在参加一次TED演讲时，主持人问他，为什么你在不同的领域都能够取得成功？他说可能是我掌握了第一性原理吧。
用最通俗的话来解释什么是第一性原理，就是在当前事物设计和创新中，我们会习惯于站在前人的肩膀上，通过比较思维去思考问题，在别人已经做过的基础上进行迭代发展。而第一性原理告诉我们，需要用物理学的角度看待事物，透过表象看到本质，然后在从本质一层一层往上走。
针对第一性原理在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多字，依然觉得有点少，今天先到这里，夜深了，回头再续。
世间多少纷扰事，浮华落尽总随风。
