整个运维领域有哪些兵器？以前我们都讲秘密执行、配置管理、监控，正好今天涵盖了好几个，现在在运维自动化领域，我们是不是发现一个很难的点，就是资产很难管，第一场演讲嘉宾讲cmdb，讲完之后大家可能觉得运维领域还有一个很关注的点，就是运维安全，其实很多时候你们可能不太关注一点，就是你们手机的密码很简单，电脑密码也很简单，123456，我也很喜欢用，但是它会泄漏很多安全，有专门的安全老大给我们讲讲运维的安全。之后再讲两个兵器，一是现在用得最多的监控软件Zabbix，还有一个是Nginx。

【刘宇】：大家下午好！整个运维领域有哪些兵器？以前我们都讲秘密执行、配置管理、监控，正好今天涵盖了好几个，现在在运维自动化领域，我们是不是发现一个很难的点，就是资产很难管，第一场演讲嘉宾讲cmdb，讲完之后大家可能觉得运维领域还有一个很关注的点，就是运维安全，其实很多时候你们可能不太关注一点，就是你们手机的密码很简单，电脑密码也很简单，123456，我也很喜欢用，但是它会泄漏很多安全，有专门的安全老大给我们讲讲运维的安全。之后再讲两个兵器，一是现在用得最多的监控软件Zabbix，还有一个是Nginx。

今天讲第一场cmdb的时候，还有一个比较重量级的东西，这个重量级的东西是什么？还是由演讲嘉宾吴城在讲完cmdb构建的时候给大家完整的宣布。cmdb是现在自动化运维架构的核心和底层，我在外面讲什么是自动化运维的时候也很关注cmdb，包括构建cmdb的时候到底应该怎么样做，接下来有请吴城跟我们讲解运维的数据银行应该怎样建设。

【吴城】：大家下午好！能到这里来跟大家做一次关于cmdb的分享，我的主题是“运维的数据银行”。关于数据银行这个词，讲到后面几页PPT大家就知道这几个词代表什么意思。

聊cmdb之前，先聊一聊配置管理，配置管理跟配置文件管理肯定是有很大的区别，配置管理这个词是ITIL服务支持中的一个环节，跟配置管理一起属于服务支持环节，什么是配置管理数据库呢？我们认为配置管理数据库是将IT资源进行抽象建模后的资源系统，它是为运维后续工作提供数据支撑的。

这是我们团队的协作模型，从最底层的基础设施资源，上层系统运维模型，由资源管理系统提供支撑，主要参与人员是系统运维，即Sysadmin，再上层是业务运维模型，由服务管理系统提供支撑，参与人员是业务人员，还有业务发布模型。基于我们这样一个写作的模式，我们对ITIL中若干部分做了两个实现，我们这边只是分析了两个系统：Auto-Bank和Auto-Gear。

资源的分为分为物理资源和虚拟资源，物理资源包括服务器、网络设备、机柜、机房、人员等等。虚拟资源包括软件、IP、域名、业务等等。我们认为你具备这四个最核心的资源，就可以拥有cmdb最核心的系统，这是服务树模型，我们的例子是汽车之家，下面是技术部，产品是系统平台，有一个例子是N层负载均衡，模块是Nginx，服务是CDN，模块是X机房CDN。这是数据库中对一台服务器进行建模的模型，绿色背景是公司、机房，这些数据都是通过人工录入的，黄色的是静态数据，这些数据都是通过自动化插进采集入库的，红色背景是跟服务树建立对应关系的，这边有一个非常重要的字段叫设备状态，这个非常重要，我们就是通过这个字段对服务器的生命周期模型进行建模的。

这是一台物理服务器的生命周期，我们定义了这么多个状态，在我们这边的命名是这样的，上架未上线、上架上线、维护、在途、库存、报废。只要能够适合公司团队实际工作的习惯就可以，每两个状态之间会有一些有方向的箭头连接起来，这些箭头代表两个状态进行变更所需要走的流程。

这是虚拟机生命周期定定义，分为不存在、上架上线、维护、回收。

这些定义到底代表什么意思？用怎样精确的方式描述它，然后我们在这个基础上进行自动化？我们认为我们需要对状态进行精确的属性定义，比如上架未上线有哪些属性代表，它一定有机房、有机柜号，图中圆圈是从外部导入的，每一个状态都通过这种方式来描述。IP和应用模型，包括IP地址、掩码、网关、VLAN等等，红色部分是产品线用这个方式跟服务树挂钩，也就是说服务树上会挂着这个产品线的硬件资源池，同时也挂IP资源池，IP有三个状态，未使用、已使用和预留，这三个状态和前面的原理是一样的，通过这种机制对资源进行精确的定义。应用代表服务器跑什么应用类型。

刚才讲了，每一两个状态之间通过有效的箭头连接，这些箭头代表着流程，我们定义出这么一些流程，上线和下线流程、上架和下架流程、维护和恢复流程、调出和调入流程、报废流程，基本上能够覆盖物理设备的生命周期，如果大家觉得状态不够，那么你可以用同样的方式往里添加。

虚拟机有上线流程、维护和恢复流程、删除和还原流程、释放流程。

举一个例子跟大家介绍一下物理机申请上线流程，这个路涉及到三个状态，三种人员角色，从服务器到机房，由系统运维将固资等等信息录入Auto-Bank中，然后将机器上架，配置临时管理IP，这个服务器就会自动被引导为LiveOS，LiveOS大家平时接触也挺多的，我们对这个系统进行配置，系统默认引导完之后就会直接用这个系统，这个系统中会自动在系统运行完之后跑起自动化采集插件，这几个插件会自动向Auto-Bank报详细的数据，这个时候服务器处于上架未上线，也就是准备就绪的状态，这个时候会收到来自于业务部门服务器申请，流入部门工单平台，我们接到工单之后，会有一个工单处理机，它会通过自动化双机系统，产品名是Auto Turbo，接到工单之后对它进行配置，重新引导配置，配置好环境，然后引导系统安装，安装完之后初始化系统环境，用接口对接自动化添加分号。至此为止，这个服务器利用Auto-Bank系统流程就完成了。

下一步这个机器会被同步推到Auto-Gear，挂到服务树，这个时候等到业务运维去配置这个产品线接下来要建什么服务，这个服务下有什么模块，然后把这台服务器分配到那个模块中，关联软件配置模块，进行参数配置，控制下发，这台服务器就可以完成顺利交付，业务开发可以在发布系统中对这台服务器进行代码发布。

这里有几个深色背景环节点，接下来的PPT中会解释，比如自动化装机，这是一个工单流程图，工单来自于两部分，一是来自于业务部门的外部工单，我们觉得作为一个公司的技术部门，你维护了一大堆资源、设备，是给外部业务部门提供服务的，我们跟外部服务部门相互衔接的手段是工单，通过工单流入工单部，Auto-Bank自己也会由运维人员操作，操作会产生内部工单，一起流入到工单库中，工单库作为统一的任务出口，下面的状态处理机来消费这里面的工单，拿到工单之后，通过管理系统以接口的模式提交任务，如果业务方申请的是虚拟机的话，状态处理机还会调用OpenStack开机，开机之后会进行一系列匹配服务。

Auto_Turbo中央机系统的逻辑架构是这样的，它有一个中心化的Controller，对外提供API，等待中央机工单的提交，每一个IDC有一套PXE Server，下面有Handler，初始化PXE的配置环境。

我们的装机系统可以做到一键部署，同时可以满足Linux中Windows自动化装机。

前面还讲到对硬件参数的自动化采集，这个图大家应该非常熟悉，底层是由Puppet来支持的，Puppet通过一系列Classify定义，然后将定义完的配置编译为Catalog下发执行，我们做这件事的时候利用到两个比较关键的技术点，一是Puppet里的Facter，还有一个是PuppetReport，Puppet自身可以汇报很多数据，比如系统版本、内存大小之类的，但是我们需要更加细化的数据它不能提供，比如我们想知道这个机器上一共有多少硬盘，每个硬盘的序列号是什么、有多少内存卡，每个内存卡有多大，这些都是Facter不提供的。

这张图最下面有一个Assets Report，这是我们自己添加的汇报处理器，整个闭环流程跑完的最后一步，它会负责把所有机器的配置参数统一汇报到Auto-Bank，Auto-Bank提供一个HTTP接口，来接收这些数据就可以了。

这是插件的目录结构，我在下面放了所有采集的插件，在你的cmdb系统只要开发一个HTTP汇报接口，就可以把所有数据入库，这个插件打算今年年底之前推出。

前面讲到cmdb数据，一部分是需要人工录入的，比如机器在哪个机房、哪个机柜，刚才又讲到大部分精彩数据是通过自动化插件自动采集的，其实我们最害怕的是在你不可控的情况下，未知的情况下，很有可能一些脏数据流入到你的系统中去，给你cmdb数据肯定性带来很大的困扰，而且这些途径可能是你想不到的，当你流程控制不完善的时候，这种情况很有可能会发生。这些数据流入到系统中之后，肯定是要被外部各个系统给消费的，我们可以通过哪些手段尽量保证这个数据的准确性呢？我们认为有两个方法可以尽量做到这一点，一是流程，一是自审计。

流程的作用是约束行为和约束数据，约束行为即你的资产在cmdb里面，这个数据是不可以被随意变更的，它一定要通过既定的流程，通过这种方式变更数据才能保证准确性。约束数据即你的数据也是经过检验的，标准化的，经过格式校验的。

自审计，审计对象有两个，一是资产审计，一是流程审计。资产就是前面所讲的有几种录入途径的，在你库里所有资源进行，不管是物理的，其是虚拟的，我们会对这些资产的格式和含义进行校验，每天都会以这样的任务去跑，跑完之后，对于不符合既定规则的，我们都会把它列入黑名单，这些规则都是我们在设计系统以及边边角角的细节时，把所有规则全部程序化，每天去跑，跑出来之后录入黑名单，黑名单里的数据有两个用途，一是对资产进行锁定，二是发布通告督促人进行数据修复。下图代表的意思是处于黑名单中的资产代表它现在是不健康的，它在cmdb自己的系统里使用会被限制，也就是说你可以锁定这台设备，让使用者在cmdb中不能对这台设备进行操作，这是一个处罚性手段。这个设备不仅仅在cmdb里被使用，下面几个也会被使用，比如Auto-Gear服务管理系统、AutoRadar都会有关联，我们提供实时黑名单校验方式，下面每一个外围系统都可以通过这个接口来校验这台设备是否处于健康状态，如果不健康，你可以决定是否在你自己的系统对这台设备进行锁定，不让人操作，同时提示这台设备的责任人有哪几位，反推他们修复数据。

听到这儿，大家可能会感觉这个手段好像有一些强硬，你一旦把这个设备在某些时候锁死了，那个系统里的人可能有些工作就会被你限制，他不能完成平时的工作了，锁定手段其实是比较灵活的手段，可以让下面的Auto-Gear系统自己控制是否要使用这个强制性手段，他只要在系统里实现个开关，就能够做到使用者操作这台设备的时候是锁还是不锁。如果所有人都选择不锁，那么大家就不要抱怨cmdb里的数据怎么怎么不准，因为这个数据的产生不是cmdb自己，而是所在的IT环境，所有方面都会产生这些数据，消费者也是大家，cmdb里数据的准确性要靠所有系统来一起维护，没有一个人可以独善其身说我只要消费数据是准的，里面的数据我压根不管它的准确性，数据的准确性还是要靠生态一起维护。

这个截图是我们每天做自审计出来的有问题的设备，第5列可以看到有一些字段是有问题的，这台设备就会在cmdb的黑名单中。

这是我们的通告，我们用E-mail手段发出来有多少台设备是有问题的，第4点列出了详细的排列规则分别是哪些，如果发现下面哪一条有问题，可以直接对照规则，下面是每台业务线分别有多少台设备是有问题的。这是倒排序，最上面的是拥有问题数最多的，通过这个邮件发出来，让所有人知道他有这么多设备是有问题的，他需要去维护。第二个明细是把前面那些有问题的内容列出来。

流程审计的目的是把违规的操作行为找出来，大家还记得前面有两张状态定义图，还有流程，我们认为你要做合规的行为，必须依赖于电子流，电子流会通过自动化的方式触发这台设备的状态，如果我们根本找不到电子流的存在，那么说明两个问题，一个问题是电子流缺失，这个电子流没有满足现在运维的工作现状，二是有人恶意绕过了我们的电子流，做了恶意的破坏，我们通过对服务器状态的审计找出违规事件，每个违规事件都有处罚条例，公司可以自己定义怎么处罚，这两个条件放在一起可以产生罚款事件，这个可以由每个公司自己去定义要不要实行。

这是我们订立的条例，条例的内容是缺少上线和下线工单。

这个表格里是我们涉及出来的十台设备，状态从上架未上线变成上架上线的流程，也就是它走过了上线流程，但是缺少工单。这是违规事件的源头，只要一天之内这个事件没有处理掉，它就会产生违规事件记录，等待部门中的专人每天来处理这些违规事件，处理方法有两种，它可以选择结合前面违规的条例，产生是一个罚款单。

到此为止，Auto-Bank资源管理系统就介绍得差不多了，接下来简单聊一下服务管理系统Auto-Gear。

这个图在前面也出现过，这是我们基于Puppet扩展的模型图，我们用这个系统去做配置的变更、配置的下发以及服务的管理，这里面用到了几个比较关键的技术点，用Puppet模块去定义服务模块，这是映射的，然后通过ENC输出这个模块需要的参数，其实这两家加在一块很像一种编程的手段。我们在这个基础之上针对我们的业务进行了抽象，因为一个服务器上可能存在多个软件实例，我们对它进行了Multi_Instance抽象，这个抽象也是在Puppet上实现的。

这是一个简化的模型，我们的库里存储了服务树、资源、服务器，它的应用是什么，它映射了下面Puppet的什么模块，我们用关系数据库建立了这些关联关系，但是这些关联关系又不是非常方便的被Puppet使用，所以我们把关联关系转储到MongoDB里面，由PuppetMaster编译下发。整个模式有非常完整的发布和回馈机制，服务模块可以通过写Puppet模块、组织参数去进行扩展，如果顺利的话，这个系统打算在明年Q1推出。

这是这两个系统接下来的计划，Auto-Bank我们打算在里面加入更加丰富的资源关联关系，用可视化形式描述拓扑，更进一步提升自动化能力。Auto-Gear我们打算将它的Runtime和代码容器化，在此基础上做服务弹性化的工作。

今天我要分享的内容就是这些。感谢大家！

【刘宇】：非常感谢吴城的精彩演讲，把cmdb从头到尾，如何自动化，一股脑全讲完了，现在给你们很多机会问细节，吴城讲了很多点，还有很多关键的地方，不知道你们有没有留意到，右下掉就是一个开源时刻表，他讲了这么多高大上的东西，你可能觉得用不上，怎么办？等他开源，加他微信，等他开源。

接下来是提问环节，吴城是这么说的，奖品没有，有红包。

【提问】：吴老师，您好！我想咨询一下，我看你讲了很多cmdb流程、处理理念、实践，在企业内，我们没有见过这种的话，怎样实践？

【吴城】：我的建议是不要一上来就找工具，先去梳理一下整个团队对这些工作，平时的工作模式是怎么样的，平时人肉做的话是怎么做的，如果抽象流程的话应该怎么抽象、抽象出哪些流程，用这些流程去归因行为，然后再看看市场上有没有能满足我们的需求，如果没有就开发。

【提问】：你的cmdb应该是生产者的角色，里面存了很多数据，消费者有哪些？你们平时对接哪些系统？

【吴城】：我们的外部系统有服务管理系统Auto-Gear，还有监控系统等。通过审计的过程可以发现问题，这个问题有可能是我们自动化的方式不完善，针对问题，我们在Auto-Bank里面有一些开发好的数据变更流程，由他们直接进来，通过这些流程变更里面的数据，同时记录是谁在什么时候对什么数据做了变更。cmdb是一个数据汇集的地方，它同时又是总体对外消费的地方，数据的回流也必须回流到cmdb里面来，修改的地方我们也放在cmdb。

【提问】：吴老师，刚刚听您的介绍，cmdb主要是基础架构信息，有没有应用层的信息，cmdb里面有没有存这样的数据，它跟日常变更或数据流是怎么交互的？

【吴城】：在我们这边的实践方式是把你刚刚说的那部分数据放到服务管理系统里面，但我见过有的公司是把整个都糅到一个系统，这也是可以的，只要在统一的地方能够查得到数据就可以了，比如我们把这些数据在Auto-Gear里做关联关系，这个设备跟应用软件做了一些关联关系，这些关联关系同时也会反向推到cmdb里面，在cmdb里面统一查询。

【提问】：就是数据是分两个地方存的？

【吴城】：对。cmdb里面数据的丰富性，你可以把你认为所有跟你所在环境的IT资源全都往里放。比如说你要查DNS，某个域名DNS解析，一整串逻辑都可以通过cmdb把它关联出来，只要你数据的详细程度足够。

【刘宇】：吴城说得很细，我补充一下，关于业务级的关联关系系统和cmdb，cmdb一般我们把它作为资产管理系统，你刚才提的问题涉及到业务逻辑关系，在我所知道的互联网企业中，能把两套系统合并在一套的，阿里是这么做的，其他大部分都是将两套系统拆开存放，业务关联关系系统读取cmdb里面的核心关联数据，仅此而已用这样的方式去做是比较合理的，也就是两套系统拆开，因为业务变更很频繁，而资产管理系统没有那么频繁，刚才吴城讲了很多很细的点，我建议大家回去再仔细看一下吴城分享的PPT。非常感谢吴城的精彩演讲。