深度解读CMDB和运维自动化

今天分享的四个内容，一个是CMDB做什么？然后做什么样的CMDB？然后我们在做CMDB当中碰到过什么样的坑？在做完CMDB之后我们还会有什么样的一些东西？

首先我们了解一下CMDB是什么？为什么要做这个东西，CMDB这个应该外部很多公司都在做，包括现在有些商业化的软件，可能还有一些开源软件，每个公司，包括像腾讯的运维蓝鲸系统也包含CMDB这一项。为什么要做这个东西呢，讲一下我自己之前亲身经历过的一个场景。我们曾经安排一个同事去重装一台服务器，信息下去之后，然后机房工程师就开始把机器下架，重装。没过一两分钟，然后我们所有站点开始全面报警，然后又往下面去查，是不是网络不通了，讲到这里大家应该都知道是什么情况了，我们后面去查，发现曾经有一次DBA去维护机器的时候，他发现这个机器两U可能比较重，放在上面可能不太安全，他把这个机器给挪了位置，然后表格里面没有更新，给我们我们重装系统这个人，他就把机器重装了，也没有确认，就全部把数据库都格式化了，所以我们后面就花了大量的时间成本去把这个备份的数据还原回来。

整个事件当中，除了是一个流程的不规范，很多一些环节上也没有确认，最主要的还是因为信息不准确导致的。我们为这个信息不准确承担了本不应该发生的事故，然后正因为这样，所以我们才需要一个非常实时的，完整的数据库，它能帮我们管理生产环境的一切信息，分好类，做好统计。同时最好它能做自动变更，因为我相信运维很多都是处于这种快运维，然后做完之后大家都想休息了，也没时间去做一些记录，做一些调整，有时候也可能会忘了，所以说我们需要，最好是能做一些自动的变更，能做一些自动的信息的调整，这些东西就是CMDB能帮我们做到的。

讲一下我们目前在，CMDB主要是什么内容？CMDB的全称是配置管理数据库，CMDB是IT架构中设备的各种配置信息，与服务支持和交付流程紧密相连。CMDB应该是整个OPS体系中最底层的数据库，它包含服务器信息、业务信息、机房信息等，与其他的系统相关联，上层的系统变更信息反馈到CMDB中，其他的系统能够获取这份变更并对自己再进行更新。图中可以看到CMDB在最底层，其他各个系统都与CMDB互相关联，系统服务平台从CMDB获取主机信息、网络信息、存储信息、应用信息做对应的监控任务，配置管理和日志管理。架构服务平台从CMDB获取操作系统信息、集群信息、软件信息做配置的集中管理、补丁更新和软件部署。持续集成平台从CMDB获取业务信息、变更信息做发布管理等。最后所有的基础数据、变更管理都在我们的运维统一门户进行展示。所以CMDB是我们运维最底层最核心的数据库，任何运维系统和操作都依赖于它。

 为什么要花大力气去设计这样一个系统，很多小伙伴跟我说这些信息一张excel表格就可以搞定了。确实是，如果规模不大，又都是一个人去管理整个生产环境的话，靠脑袋记和烂笔头就够了，如果再多，招个文秘也可以搞定。但是请注意到这一点，这些都是靠人去维护管理，人是有惰性和忘性的，无数事故证明，人才是整个运维过程中最不稳定的因素。让我们看看实际运维过程当中，会产生什么样的和CMDB相关连的问题。

相信有很多人应该刚做完年终资产盘点。为什么每年都要做年终盘点这件事情，最主要是平时对资源信息不够了解，不完全清楚我有哪些资源，资源在哪里，资源是怎么用的，还要不要申请资源。来的同学应该都是做运维或和运维相关的吧，我想问问大家，你知道你管的业务一共有多少台机器吗？这个比较简单啊，大家应该都知道，那我再问问，你知道你管的每个业务的每个模块的每台数据库的每台备份主机在哪个机柜哪个机位吗？跟资源相关的还有很多内容：比如机柜里有哪些机器，还能不能上，各个操作系统有多少机器，Mysql有多少台，某虚拟机在哪个宿主机下面。

还有很多跟业务信息有关联的，每个运维都应该是对自己的业务信息、拓扑结构非常清晰，出了问题知道该去哪里定位，业务做迁移需要通知哪些相关联的应用。但是，这些东西应该都是在你的脑子里吧？虽然有不少人写文档记录，但是业务变更时做更新了吗？原来我们做完了之后大家就吃吃喝喝，一顿烧烤，第二天大家休息一下就去上班，文档的话，过两天再写吧。生产环境异常复杂的相互调用关系就像人类的神经网络，重要，但很难理清。然后分管不同业务的运维和开发，每个人都有自己的干货，这些干货平时是串不起来的，只有出事故的时候才能拿出来碰撞。这些只是想到的一点点内容，还有更多的信息，这些信息都是需要维护的，光靠Excel和大脑是无法存储和计算。

好，既然有这多需求和等待解决的问题，我们需要把CMDB建立起来。开发一个系统就像盖房子，首先你得决定盖多少层，每层有什么样的功能，然后根据用户的需求去设计房子，最后施工把整个房子最终盖起来。首先我们分解房子的功能，通过OO方法进行业务建模，分解每一个CI，从而建立业务运维领域模型。整个模型里分几大类：产品线、业务模块、应用服务、软件实例、主机、中心设备。产品线依赖与各业务模块，业务模块依赖于各软件实例和应用服务、实例部署于主机、主机使用存储、网络设备、IDC。然后我们决定房子有多少层，模型分层：资产层、服务层、业务层， 分层可以隔离人工操作部分、分阶段实现功能、局部重构，资产层：机房、IP、网络设备、配置信息。 极少数信息需要人工操作维护：例如主机所在U位。尽可能自动采集所有字段，部分物理信息其实也可以靠命名规则或流程规范自动获取。，服务层：软件信息、服务。应用名称、版本，服务内容等，业务层：业务线相关。域名、集群服务等。

CMDB整个分层我们已经结束了，那我们现在就去找哪些人会用CMDB，因为我们要采集它的需求，那我们去定义它的使用角色，谁最关心CMDB的数据，在我们这边，我们归为五类需求方，第一类是资产管理员，他们对数据是有最直接的需求，他们因为是作为整个资源管理的管理者和分配者，他需要管理所有的数据的采集、变更和分配，比如我们公司可能某个业务线他们要上一个活动，他们可能要找一台机器，我要找一台空闲的机器。

我们在表格里面看，所有的机器基本都是标注了使用的他才会进入到表格，没标注的就偷偷藏在那里，谁也不知道那个机器在那里。那么我们放到CMDB里，如果它没有跑业务，那么我们就标记为闲置，这样子我们的一个资产管理者它可以很轻松的就找到，我们在哪些地方有多少可用资源，然后在随时能上业务，谁能去给他分配。

第二类业务运维，他们是数据的产生者也是数据的变更者，因为它对线上会产生一条又一条的新的数据，或者对原来的数据做一些变更，他们对整个业务信息的知道他们最清楚，我们一定要把他大脑里面这方面的数据全部挖出来，他们会有哪些资源，他们平时会做怎么样的一些变更，把这些东西全部挖出来，然后我们去填业务相关和配置相关的内容。

然后第三类是监控，监控对这个CMDB里面的产品线这个东西是非常有需求的，因为业务可能产生一条报警，他们要知道这个报警应该报给谁，最终是找谁去解决这个问题，他们还会去根据你这个CMDB里面，它会跑什么业务，跑什么服务，它需要添加什么监控项目，第四类管理层，管理层他们对我们整个资源的使用的统计报表有需求，然后对整个的资源使用的整理规划和预算，我们在来年的一些预算。最后就是财务，财务他只关心资产编号这些东西，他只关心跟钱有关的东西。

OK，首先我们确定了这个需求对象，他们有什么样的需求，然后去采集他们的数据，他们会产生怎样的数据，整理一下他们会怎么去用它，做出我们正确的需求文档。然后我们把整个数据全部格式化，设计出表结构，然后开始去建设CMDB。

有很多开源的CMDB，像onecmdb,cmdbbuild等等。他们主要特点是实现了CI，关系和属性三个要素的这种模型的一个构建，但是对这种业务，业务发现，业务的一些关系的可视化还有一些数据安全方面的东西他们是比较欠缺的，因为他们不会去深入到你的业务。所以说，开源的软件，一个是不满足我们的需求，可能还再有一个学**成本和二次开发的难度，我们最终决定了，全部重新开发。整个开发过程我就不详细描述，前面需求采集到位，后面就是库表设计，最后做开发就是非常简单的一个事情。

主要讲一下，我们在哪个过程当中的一些关键细节，和一些实现的思路。考虑到线上的环境特别复杂，你可能会有很多很多操作系统，有很多帐户密码，还有一些网络限制。建议还是用三层体系结构，客户端负责采集属于数据层，服务端负责接收和处理属于业务层。WEB页面向用户提供数据属于表示层。这样客户端只负责数据采集，环境的多样性并不会影响到数据后面的处理，同时压力也可以分解到各个客户端。服务端只需要将数据过滤再存储，不需要操心数据取不取得到。另外通讯一定要考虑加密，毕竟传输的都是敏感信息。

 这样的分层的话，那我们客户端只需要负责数据的采集，环境的多样性不会影响到它数据后面怎么样去处理，我们可能有很多业务线，它不需要操心后面的业务线怎么去处理的，它只要把基础数据准备出来，然后同时这个压力它可以分解到各个客户端上面。然后服务端它只需要将这个数据去过滤，去解析，再去存储，它不需要操心这个数据我是不是能取到，只要报上来了，我就认为这个数据是可靠有效的。最后WEB表示层提供数据表现。

信息采集这个方面，有非常多的手段，例如facter，dmidecode，ipmi，wmi等。在后面我会去讲，最近看腾讯他们分享了一篇，一个文章是用tcpdump自动去抓流量，分析业务请求关系，我们准备参考这篇文章，我们也做到相关的东西，因为我们说的基础数据都有，我们现在只缺一个抓它的过程。还有，各个系统的一个API一定要进行规划好，因为你CMDB可能不只来自于客户端的采集，又可能还会来自于第三方系统。

最重要的一个是业务发现。这个是我们这边做的一个，最重要的一个功能。就是业务运维给我一个域名，它想找到这个域名，最终后面落地到哪些服务器上面。那么它给我一个关健词就是域名，我们从域名，我们先从DNS去查，我们去查到我们的外网IP，那外网IP有可能还走到CDN，我们要把它的原站要找出来，然后我们再从负载均衡一层层去找，或经过WAF，然后从WAF可能找到后面的缓存服务，我们一层层往后面去找，然后去把这个机器和域名的对应关系找出来，然后我们把它放在CMDB的资产里面。

为什么要做这个东西？因为像我们之前经常会有这么一个情况，有一个站点运维他说他有七台机器是跑这个站点的，后来我们就实际去看，在负载均衡上看的话，只上了了两台机器，剩下五台机器只配了域名和部署了程序，但根本没对外提供服务。我们会有大量的这种信息不准确，导致后面很多的服务器浪费在那里，他会认为他这些是要用的，他不能给你回收。那导致我们每次要做大促的时候，OK，我们没有机器，那要买买买。所以我们做了这么多功能，我们会去找出这个差异，我们告诉你，你这个域名实际上是跑两台机器，剩下五台机器我也帮你找出来，我会告诉你这五台机器跑了站点，但是没有上线。

OK，还有一个也是比较关键的东西，就是关系的维护。像我们的网络组经常会有这个需求，就是它想知道它的，他想找一台机器去换他的网线，但是他不知道他的机器接到哪里，有可能用户到布线柜子里去摸线也能摸的出来。但是这样其实蛮浪费人力物力的，然后我们这边去通过CDP，我们用CDP协议我们去获取到网络信息，获取到VLAN信息、交换机信息和对应端口，自动绘制出一个是交换机的一个接入关系，自动帮网络组绘制出他们网络拓扑架构。核心是什么设备，汇聚层是设备，接入层是设备，每个接入层接入的是什么机器，他们中间的一个网络连接线的一个关系，给他们一一汇聚出来。这个以前做网络运维的应该很痛苦，网络是经常会去做调整的，我们经常要换网络拓扑。基于这个需求，所以我们做出了这个。

然后还有一个就是，也是一个比较麻烦的一个事情，就是大家有一些虚拟机有问题吧，它想知道它的宿主机在哪里，他还知道上去重启这台机器，然后可能很多人都不知道他自己这台主机在哪个宿主机下面，然后我们也是根据上面的一个CDP，我们自动去抓出虚拟机和宿主机他们使用的相同的网络端口，然后来绘制出宿主机跟虚拟机的一个关系，生成了这样一个关系结构，还有根据这种IP去判断它的机房在哪里，然后根据CDP抓到的交换机信息，判断这个机器在哪个机位，然后我去对比业务主机发现的结果和主机实际配置的信息来形成一个差集，让运维去知道他在生产配置上的一些脏数据。

OK，一些细节都讲完了，这是我们整个CMDB的一些界面的展示

右边这张，这张图就是刚刚之前讲的那个，绘制出来的一个接入的交换的结构，不同颜色的连接线代表不同的VLAN。

这是整个基础字段的一些信息，这是我们刚开始做一些需求，采集一些字段，可能这是最早的一份，这份还比较原始。

然后再分享一些存在一些细节的和一些存在坑的地方。因为如果细节不做好的话，这个系统做出来的话没人用，他觉得这个东西满足不了他的需求，没人去用，那这个系统可能也就废掉了。然后我们怎么去做一些这个细节，我们层次一定要分清晰，这个层次之间是一定不要强依赖的，然后分层的话，刚才讲了分层可以隔离操作，可以分阶段实现，也可以方便局部重构，然后数据的需求一定要过滤的，像我们之前最开始做这个系统的时候，我们的监控人员，他希望把我们流量的监控图也放进去，然后系统操作组他希望把远程管理的重启按纽也放进去，我跟他们建议就是，CMDB他只是一个数据库，他不应该去做一些操作方面的内容，他只是做一些数据上的一些管理和更新，然后如果是你要监控的话，我们有监控系统，你要做操作的话我们有操作平台。

还有一定要保持这个数据的纯净，如果数据一旦不更新，那对线上来说基于这些数据做一些操作，可能会造成一些比较灾难性的东西，一定要减少人工操作的数据，有人的地方一定会有错误的。因为我们之前，我们已经碰到这个问题了，一旦一条数据里面一个字段没有更新的话，他这整条数据它都是一个脏数据。然后我们一定要用这种关系性的数据，去替代这种文本型的数据，整个运维过程当中，配置变更是非常频繁的，用关系去替代这些文本，我们可以减少数据量的储存，然后我们去做变更的话，系统开销也非常小。

每个项目都会有**小小的坑，讲讲我们整个实现过程中的痛苦。没有配置管理工具的前提下，客户端自动更新一定要考虑到，调试上线和改BUG总有无数次更新客户端。部署全部客户端整整花了一个月，有salt和puppet的还好解决。剩下的100台机器就有100种环境。有的机器没装salt，有的salt配置不正确，有的机器采集不到CDP，有的机器登录不了，有的机器没密码，甚至各种我们不知道的操作系统都出来了。最后我成了部署小王子。

很多小伙伴有各种各样的需求，要对需求进行正确识别。有要监控和日志都进你的系统里去的，有要你的客户端接收指令进行命令操作的（salt是什么鬼？）。对于这些，我认为这个系统是运维的底层数据库，不要期望他做监控和日志系统的事情，也许你完成了这个，下一次别人就要你让它实现负载均衡的功能，但是CMDB的数据是可以提供给任何其他系统接入使用。

我们看一下这个图片，它应该是我们当前，这个现在也是在沪江还比较老的一个图，现在我们已经改进了很多，它应该是包含整个基础的自动化运维平台，它CMDB是作为整个系统的各个配置变更的一个入口，所有的系统都要从它这里去获取数据进行管理和变更，各个系统的一个变更要回到CMDB。

可以思考一下我们后续的流程：资产管理员上架了一台新机器，并录入数据到CMDB的离线仓库，离线仓库发现这台机器没有装操作系统，即刻发出指令至装机系统自动化安装业务线需要的操作系统。机器安装完成CMDB自动采集入库后，CMDB通知监控系统加入系统监控，根据指定的业务线通知发布系统进行发布，发布完成之后变更CMDB上的业务信息，继续通知监控系统加入业务监控，然后CMDB继续通知测试自动进行回归测试，并推入负载均衡系统等待人工最后确认上线。整个就是运维的一整套自动化业务操作流程，这套流程完全依赖于CMDB与各个系统之间的相互数据流转，从而行成一整套强壮的自动化运维。

那还讲到就是，我们现在的话，我们希望是能做到非常一种理想的AI自动化，一个是做到这个AI自动化我们需要做好几个东西，一个是我们要制定一个非常完善的一个故障树结构，然后就是绘制一个完善的业务神经网络，这个业务神经网络。

就前几天看到腾讯分享的根据TCPDUMP抓取业务关系鄂一个观点。怎么去实现运维自动化，一开始谁也想不到和做不出一个大而全的东西，一定是结合我们的业务，先解决痛点，再按阶段实现。

那么先找出我们目前存在哪些急需解决或日常频繁操作的部分，先工具化。各个小工具就是每一个自动化的零件，组装起来就是自动化的平台。组装之前的每一个工具只能称之为操作自动化，各个平台数据打通和对接我们称之为事务自动化，如果能根据大量的数据和事件，服务器自行决策和执行，那是一种非常理想的AI自动化了（在这点上我已经给我们公司的同事们多次吹过风，一是制定完善的故障树，二是绘制完善的业务神经网络，三是无人或少人干预的持续集成）。归根到底运维自动化终归只是一个高级工具，并非解决一切问题，它的价值在于帮运维脱离出频繁的复杂性操作和容易发生事故的命令行操作，可以让运维关注于业务运维。