分享大纲：

CMDB大家并不陌生，在运维的工作中几乎都会用到CMDB，在聚美内部我们也称它为资产系统，管理整个服务器的资产，当然也包括一些配置上的变更。

这个截图可能算是聚美优品第一版的CMDB，这是刚进公司，我们在做第一版监控系统时（那时用的是Nagios），通过这个去管理资产信息，再通过用脚本去读取这个文件，最后生成报警配置，这样我们管理监控时只需要修改这个文件，最后再执行脚本就可以达到监控变更的目的。

上面的图是Ansible的CMDB模块，这是官网上的截图，大概的原理就是基于hosts文件里面的主机信息，生成相应的资产信息，大家可以看到，这里的信息已经比较丰富了，包括硬件及系统相关的一些信息，而且颗粒度已更细致。

CMDB的表现形式非常多，上面只是举了两个例子。很多时候大家可能都没有意识到我们在使用它，我再举个例子，早期的时候，大家或许有过这样的经历，我们用excel去管理服务器信息，这其实也可算做是CMDB的表现形式之一，只是这种方式的对象是人，而非某个系统。

这类的方式都有一个比较大的问题。大家可以从上面的例子看到，监控系统和自动化系统的CMDB其实是隔离的，CMDB是没有办法去做到统一修改的，所以在变更了监控系统相应配置之后，自动化系统是不会生效的，我们又要单独的去变更自动化系统的信息，导致额外的维护成本，所以很多时候我们面临的都是这样一个现状——有多套CMDB并存。

在开始做CMDB之前，理想是美好的，希望CMDB是中心化的，就像这张图所表达的一样，如果说整个远维平台是一个大树的话， 那么CMDB就相当于这颗树的树干和树根，有着非常重要的作用，而其它子系统，像是监控系统，自动化系统，还有业务相关的一些系统等就像树的树枝和树叶，大家互相依存，在CMDB上面做任何的变更之后，其它周边的一些系统能够立马知道，而且同时能将这些变更应用到具体的场景上。

在设计CMDB之前， 我首先会从运维的角度去考虑，怎么去管理这个系统，让系统更易于维护和管理，所以在设计之前必须先问一个问题：怎么去管理？那首先就要知道需要去管理哪些信息，也就是说哪些信息应该放到CMDB里面，这些信息的我们对它怎样进行分类 。另外一个就是这些信息对我们后续的一些系统的建设能够提供什么样的一个价值。

第二个就是怎样去保障这个数据的准确性。要保证数据准确性有两种：一个是我们在线上跟线下数据的同步，线下数据跟线上数据保持一致，前期要不停地盘点，到做CMDB的时候，这些数据才能用起来。第二个一定要避免人工干预，这个可以通过一些自动化的手段和中心化CMDB相结合达到这个目的 。

前面提到了在CMDB的信息管理里面需要管理哪些信息。信息的分类，我的理解，大致可分为两种，一种是可变信息，另外一种是固定信息。固定信息的，很多数据都可以通过一些程序，或者是自动化的手段进行自动的录入，几乎是不会变的，但需要有一个比较好的规范，比如像机房或者交换机这样一些信息，自动化工具是抽取不出来的，所以我们采用了一个变通的方法，统一交换机的命名规范，统一采用机房+机柜的命名规范，然后通过脚本抓包的方式把网络结构还原出来。如果主机也是基于这样的规范命名的话，甚至还可以把机柜还原出来。

可变信息是构成CMDB生命最重要的信息，有了这些信息才让资源真正有了相应的归属。人员的信息，包括像联系方式的等信息，主要是为监控系统提供相应的数据，状态信息包括资源上线状况、下线状况，主要是为自动化上线提供相应的信息，环境信息包括生产环境还是测试的环境，主要是为监控系统及自动化系统提供相应的信息，项目信息在跟一些业务系统做一对接时时非常重要的，比如说业务系统需要知道某一个项目有哪一些IP都需要从这里面取数据，同时也是自动化系统的支撑，有了项目归属，服务器才知道应该去做哪些部署。

CMDB在设计的过程中，我觉得是比较重要的是自动化的系统跟CMDB系统的结合。首先，在一个资源交付之后，可以通过一些装机和初始化的脚本去调用CMDB的接口，这样机器的IP信息就会同步到资产系统的资源池里面去，后续在领用这些资源时，可变信息就发生了变化，这时候就有项目的属性，在我们的CMDB系统里面就知道了这个机器到底是属于哪一个项目，知道了属于哪个项目，然后才能明确后续需要进行哪些操作。

但是这个时候，我们的自动化系统是不知道项目信息的，所以需要通过CMDB API去拿到项目等相关的信息，我们使用的是Saltstack，简单的说，就是将从CMDB获取到的项目等信息来更新我们的grains，这样自动化系统在后面进行业务部署的时候，才知道应该做什么操作。同时这个时候，自动化系统还会将自己读取到的固定信息，通过调用CMDB API，将这些信息刷入资产系统，完成整个信息的完善， 这样就实现自动化系统和CMDB系统的联动。

之前提到，很多时候我们其实都是面对的多套CMDB并存的情况，在我们运维平台开始设计时，由于像自动化系统、监控系统这些系统本身就是基于CMDB开发的，所以直接读取相应的一些存储数据就好，或者也可以通过CMDB的API进行联动，但是由于其它系统的CMDB是独立的，比如发代码时要改发布系统的CMDB信息，这样话可能在操作上面难免会有一些失误。所以为了解决这样的问题，我觉得一个比较好的办法的话就是把CMDB的一些信息同步到配置服务里面去，比如说像ZooKeeper，etcd里面，同步进去之后，如果是其它系统要用的时候，再把的信息拿出来，对它进行处理。这样的话基本就可以达到一次变更，所有生效的目的，实现了中心化CMDB，集中化信息管理的目标。

前面讲的更多的是偏实现的一些东西，下面主要想聊下关于展示相关的一些东西，前面提到在做CMDB之前要首先考虑CMDB的价值在哪里？一是支撑我们整个运维平台的建设，尽量做到自动化，中心化的管理，这个是接口层的价值。展示层的价值在哪里呢，上面的这个截图是我们一个子功能的截图，通过这样一个展示就很方便地知道我现在的物理服务器，虚拟机等的比例是多少，亦或者可以知道我们每个机柜的容量是多少，只要数据是准确的，有价值的，基于这些数据，我们就可以做出非常多的组合。

关于CMDB的一些构想，在很多时候，大家可能都会面临过这样的情况，就是一个同事可能有多个的账号，比如说公司的电脑登录账号，公司邮箱账号等，这些信息如果按CMDB的定义去看理解的话，可能不能称它为CMDB，但是我认为也可按CMDB中心化方式去管理，将存储层打通起来。比如代码仓库，邮箱账号，服务器登录等都可以通过openldap去做统一的数据存储，这样在发生人员变更的时候，就可以做到一处变更多处生效的目的，而不需要过多的人工干预。

但这个方案也有一个缺点，会存在一定安全隐患，因为如果数据层都打通的话，如果发生密码泄漏，其它的项目自然会面临同样的风险，因为各个系统的密码都一样了，所以最好是能再加一层双因子验证，保证信息的安全性。

• CMDB的价值

从我自己的理解，运维的工作很多时候都涵盖在这三个领域里面，稳定是最重要的，第二个是效率，然后是成本。CMDB在哪个地方可以体现它的价值呢？我个人认为在成本这一块能力体现非常大的价值，上面提到的固定信息里面，包括了硬件，系统等信息。而成本，我理解也是一个固定信息，比如说我们可以根据CPU和内存去推算我的这个月这台服务器支出是多少，有了这些数据就可以得到每个月的机房支出 。

有了这些信息后，比如说我们的服务器资源通过监控系统查看这个月已经跑得非常满了，下个月找老板我要买服务器，但没有数据支撑的话，直接给老板说买50台机器是没有任何说服力的，实际上用CMDB也可以做这个事情 。服务器价都是可以推算的，甚至还可以通过爬虫去爬取网上的一些报价信息，在当月资源不够用时，需要增加时，可以提取出来告诉老板，就知道需要多少成本预算了。

第二的话是效率，如果是在开始设计CMDB之前，我们就按照之前中心化的思路去做CMDB话，有很多信息就不需要多处去变更了，从这个维度来说，也就提高了我们的效率，提高效率的同时也就保证整个系统的稳定，因为人工操作难免都会出现一些问题的。

最后引用小米提出来的这个概念，NOOPS，我们可以通过把所有的系统打通起来，去帮助研发提高他们的效率，比如说他们涉及资源使用时可以通过工单系统去申请资源，经过审批之后，自动交付资源，发布代码，上线后可以通过业务监控获知业务的状态，达到一个自主上线的状态，当然这中间还是需要人工做干预，不过这个干预更多的就是流程上的审批，目前这也是我们努力的方向。

PPT链接：https://pan.baidu.com/s/1jIHqqDw#list/path=%2F