2018-03-21 14:00
今天给大家介绍一个在运维领域非常专业的平台CMDB，配置管理系统，整体介绍稍微偏理论一点。
简单做一个自我介绍，我是2011年加入腾讯的，加入腾讯之后开始做运维，曾经负责过几款游戏业务的运维工作（穿越火线、地下城勇士等），大概在2012年开始加入腾讯的一体化运营平台蓝鲸的构建团队，刚刚晓玲在前面的标准里面多次提到了蓝鲸。
今天给大家的分享主要有三个部分：
第一部分是谈一下CMDB的定义以及在行业里面的现状。
第二部分针对构建CMDB有几个关键点需要给大家做一个详细的分析。
第三部分从CMDB在我们内部所起到的角色及结合运维的实际案例给大家做一些分享。
首先CMDB是什么？我们认为有两大块，第一块主要要是它负责存储运维所有的IT设备以及IT设备上面所跑的业务的相关信息，起到一个信息库的作用。第二块是为运维所有的交互服务流程提供操作对象，比如说要做一个监控，监控对象是一台主机或者是一个交换机、防火墙这块，同时它还提供了信息验证和权限校验的机制。在腾讯内部目前有数百款游戏业务，每一款业务（相当于大家玩的每一个游戏）是不同的运维人员负责的，我们需要通过CMDB严格控制每个运维人员的信息查看和操作的权限。
关于CMDB在运维体系中的定位，其实CMDB在最底层，里面存储了非常多的信息，简单地描述就是业务、主机、网络还有非常多的公共组件，传统企业把打印机、电脑存到CMDB里面来。我们刚刚讲CMDB其实是一个信息库，里面可以供查询和写入，我们通过一个总线调用CMDB的信息，去读或者写。
下面讲一下针对CMDB这块的一些痛点。纵观整个行业好像还没有一个统一的通用CMDB，当然在一些外企，像IBM有一个Tivoli，还有惠普专门做运维领域做一些商业化的CMDB，他们的CMDB有几个特点，第一是贵，动辄几百万，第二个是很笨重，都是基于传统的巨石架构开发出来的，功能过于复杂，使用效率非常低下。
我们针对CMDB在运维流程里面的作用，讲一下很多企业在面对CMDB的时候碰到的一些难点，第一个就是信息的一致性，一个企业级的CMDB经常会有非常多的部门要到上面读取或者是更新信息。很多时候在企业内部业务流程都不规范，就导致了它的CMDB数据化时A部门和B部门信息同步不一致。第二就是数据的准确性，由于CMDB中非常多的一些信息随着业务的变更或者是硬件组件的更换，如果没有一套自动发现更新制，就会造成CMDB中的信息与实际线上运行的我们经常碰到线上服务器某些进程或者是端口，或者是CPU或者是内存信息其实是不准的，需要手工去改，准确性很难把控。
第三块就是可审计，我们CMDB是企业内部很多企业甚至把它当成是一个资产管理，信息更改要求非常严格，但是又不得不很多时候去改，更改之后审计成为痛点。所以我们也在行业里面针对以上三点做了关于CMDB的很多交流。
另外一块就是DevOps，云计算，甚至将人工智能的东西，新技术其实对CMDB提出了很多新的要求，比如说CMDB具有动态拓展，支持多样化的数据模型。
第二个是数据，以前传统行业几百台服务器存CMDB就可以。现在大家采用云计算、公有云自建私有云这块，所有内部的数据就翻倍增长或者是成指数的增长，数据量非常大，传统的方式就是手工入，或通过一个Excel表去导入，而且每个模型里面属性很多，包括一个服务器比如说CPU、内存什么内网IP、外网IP、维护人各种各样信息，线上线下信息非常多，这就要求具备数据自动发现的功能，从而减轻人工的手工录入的工作。
第三块是关联分析，现在在腾讯内部出了问题或者是故障我们都需要与CMDB做关联。比如说我现在是负责王者荣耀的运维，如果某一天我的王者荣耀在线掉了，运维如何去定位。首先，我们需要查看王者荣耀是哪个区掉的，哪个玩家投诉过来，整个反馈到业务架构上面，可能在哪一个机房，在哪一个交换机下面。整个这个信息都是基于CMDB去做的，信息查询、问题定位才能变得更清晰。
第四块是信息库，它要提供海量的信息查询和写入，需要有非常灵活的API，支持便捷查询信息。
最后我们提到了跨云管理，我们在2016年腾讯的游戏开始出海，我们就在全球统一部署发行，王者荣耀大家都知道，我们在国外东南亚、美国、欧洲都同时部署，部署在这块特别是在欧洲、美国那边，我们很多的点是Cover不到的，而且那是基础设施都不是我们自己的，可能我们买的AWS的，有可能是本地的运营商提供的IaaS，所有这些网络都不一样，有可能三个内网的网段的IP很多时候就有重复或者是冲突，这些问题都必须要去面对和解决。
我要讲的第二大方面，就是针对我们面对这么多问题和困难如何构建CMDB，我们开发或者设计CMDB重点要关注以下四点：一是信息模型管理的设计，如何去设计一个合适的信息模型，囊括你所有企业内部的IT设备，甚至是未来有可能出现的所有这些对象。二是当你把所有这些设备信息都录到CMDB之后，你要去针对你的企业或者你这个不同的行业的业务架构，进行管理，比如金融行业用CMDB，怎么才能做到通用？在我们腾讯也是一样的，对于我们来讲，我们面对的是全球一百多家不同的开发商，有可能一款游戏、一种游戏开发出来是同样的玩法，但是针对不同的开发商可能采用的架构都是不一样的，如何去适配千奇百怪的业务架构管理到CMDB来，这是一个问题。三是你的CMDB建立出来之后，怎么面向运维场景，CMDB只是存储信息而不去跟运维场景相关联，这时候你发现CMDB建立起来很快就没有人用它，这就变成一个无用的CMDB了。四是我们针对CMDB如何让它在建立好之后运转起来。
第一个就是信息模型管理，我们针对CMDB的管理对象，刚才我讲到整个CMDB的模型种类其实很多，比如像我们一个业务设备之下，又是业务的进程，这些信息可能至少有上千个维度，这些维度很多时候是有复杂的关联关系的，不像一盘散沙。模型种类包括各个种类模型之间的关联互补。
传统的CMDB设计，我们看到很多以前的CMDB是硬编码，我们调研这个企业多少个人，把所有模型硬编码到CMDB中。我们做的是可视化的增删模型，某一个设备假如说我们的小型机或者是大型机有一天淘汰了，这个模型可以删掉。有了新的模型再进行处理。
模型里面最重要的是字段，一个模型里面有很多字段，这些字段需要支持自定义。举个简单的例子，比如防火墙，负责人电话、责任人，这些都是线下的，针对防火墙做一些审核，还有IP等等很多的端口，而且每一个字段的类型是不一样的，比如说责任人是用户，那应该是用户名这样一个字段，有可能跟企业内部的帐号管理体系要关联起来，有可能是一个审核时间有一个时限字段，IP字段的话这块要对它进行校验，否则的话很多时候要录入信息的话会走样。还有一些索引，就是你需要对每一个字段里面我们经常要做一些查询或者针对它做一些索引。当然你还可以给它定义很多的约束。这样就可以做到自定义的字段无限地扩展。
另外讲到模型与模型之间的关系，这里面举个例子，相信大家看得懂，服务器存放在哪个机位，服务器一个模型，机位一个模型，机架是一个模型，机架在IDC里面放在哪一个逻辑区里面，存在哪个IDC，同时服务器上面可能跑了操作系统，操作系统里面可能使用了IP地址和IP网段，各种各样的信息构成了网状信息。
针对这块的关系我们把它抽象出来，所以这些模型关系我们把它抽象出来，一对多的关系。比如说一个防火墙跟下面所属的主机或者是交换机，防火墙是属于某一个部门的模型，可能属于哪一个厂商这样的模型，是一对多的，甚至可能多对多的关系，通过两种关系把所有关系从上往下梳理出来，映射出CMDB对应的关系。
这个是对典型的虚拟化场景的实现，比如说这个应该是电商业务，底层有非常多的硬件设备，像服务器、网络、存储，可能通过虚拟化技术，通过虚拟化把所有的这些虚拟成想要的虚拟机、虚拟对象，可以在上面跑业务。这个时候我们针对这样的场景，我们对它进行建模。比如我建一个实体机这样的模型出来，这里面很多字段都没有描述，同时一些字段的约束和定义都会到这里去对它进行区分。
当我们与这个模型建立起了关系，里面的字段都维护起来之后，企业内部所有这些资产信息都可以往里面录，录入进去我们要把所有的信息面向业务，根据我们的业务架构去对它进行分层管理。
业务管理的问题有几个，首先第一个是行业差异，CMDB有可能是电商的、有可能是金融的，行业差异非常大。第二就是业务本身的形态的差异，比如说我们原来做游戏的话，一个是端游的PC端的、客户端的，比如手游可能是手机APP端，还有网站Web端的，还有小程序、公众号这种不同的业务形态这些差异，都要去能够兼容它们。
第三块就是环境，一个企业内部的业务形态架上去之后，可能根据业务的需要或者是其他的需求，可以分很多环境，我们分为三套环境，第一个就是测试环境，内部的版本随便测，当版本达到一定程度之后，我们可能要放到大家说的沙箱环境、体验环境，我们外部有一部分用户可以把他们放进来到这里来体验这部分功能是否有问题，这是体验环境。当体验环境OK之后我们就批量对外放了，我们叫正式环境。这样可能很多的企业都有这样的分类，分类的话名字或者是分多少类这是不一样的。
针对业务差异的话我们有几个思考的关键点，首先针对不同的行业或者不同的业务架构或者是不同的环境去建设你业务的模型。
而第二个如何满足业务层级，在腾讯内部我们大部分的业务都是按四层去分，也有按三层的。举个简单的例子，比如说王者荣耀，第一肯定分区，首先它是一个业务，下面分区，某一个区手Q或者是微信几区，在这个分区下面有可能分模块，这个模块是开发，你们看到一个功能就是模块提供的，下面可能有成百上千个模块，每一个模块下面就挂着对应的主机实力或者是存储，类似这样的信息，就分四层。还有比如像QQ游戏大厅，就是统一个大区，这种首先是业务，下面就是模块，模块下面才是主机，这样就是分三层。当然还有很多其他不同行业的有五、六层，甚至更多，分部门放到层里面去，比如说电商有移动端和PC端，会分非常多的层，要满足这种业务层级。
第三要支持动态拓展，就是说有可能企业组织架构发生变动了，业务层级有可能做调整，有可能原来的五层变成三层或者增加更多层，要支持做动态拓展。
第四是针对业务的生命周期或者是业务场景的执行，这时候把业务状态放里面去。比如说目前我们的服务是测试状态，或者是开放状态、关闭状态，这些状态很多时候跟公司内的电子流等等都关联起来。
针对这几个关键点从运维实际基本需求出发的话，把最基本的三层抽离出来，首先第一个就是最上层的业务层，不管你这个企业怎么样，可以把它抽离成业务的，首先最重要的是隔离人员的权限，做一个项目基础，A业务的人不能看B业务的东西，不能操作B业务任何执行类的东西。
第二块是集群，在运维日常的发布，或者是扩容或者是新搭建的一组服务，这块需要用到。
第三块就是模块，比如说模块商店，这个模块上面跑的是同样的进程或者是端口都是一样的，所以整个这块我们把它抽象成三层出来。
刚才我们讲到很多行业企业不一样，可能不是三层，可能把企业组织架构也放进去了，在上面放一个小组，就可以往里面加。后面另外一个公司又不是一样的，我们外面交流，像餐饮行业，肯德基、必胜客的管理方式是按区域来的，华南区、华东区，业务下面有很多门店，门店下面又是集群或者是模块，按这种模式来。也就是说业务模块的层级我们基于三层最基础的可以无限拓展。
层级属性的拓展，当我们有三层或者五层或者六层，每一层很多时候我们要对它每一层的属性进行拓展。比如说我们这里面，这是我们一个游戏业务的，运维维护王者荣耀、吃鸡游戏，这些游戏里面在每一层的层级里面很多时候会对层级里面做一些标签，这些标签很多时候要通过这些标签去寻找操作对象。比如把某一个Open-status是一个集成标签，会有不同的发布，不同的发布有不同的对象，我们怎么在CMDB体现，我们制订一个open-status可能是1的时候是第一批发布的，是2的时候就是第二批发布的，这个时候跟我们运维场景关联起来，我们就可以对应这些信息，等等。所有的层级里面可以有很多的层，业务配制文件都可以从每一个层级里面进行读取。
业务状态的管理运维对象从资源入库到模块应用，它的状态的管理是贯穿整个业务运维的所有流程，像我们这样，比如说从资源池拿一些主机，把它上架上去，这个时候通过CMDB可以自动发现出来，发现上架还是下架的，这种状态就可以做出来。我们针对监控我们有类似于治愈，比如说服务器宕机，我们通过治愈手段把服务器修理好或者替换掉，假如说我们替换，如果是老的机器之后，我在CMDB状态流转是流转成故障的不能再用了，这个过程是故障，替换完成之后就把它放在空闲的状态，这样的话后面大家不会把它当成业务的，否则主机还会有问题。
比如说发布，分测试和正式，测试发布的话优先级或者发生问题的处理流程不一样，这种状态会有一个标准。比如像我们的监控，监控这块就是你针对你所有的CMDB这些运营的对象可以做监控，针对那些停用状态的就不用做监控了，所有的这些状态流转都可以通过CMDB进行流转。
这是一个可视化的拓扑，刚才讲了CMDB的一些模型，以及模型下面的一些实例包括刚刚说的业务层级，都可以在这里可视化分配出来，可以分配到对应的层级上面去做。
第三个大的方面就是面向运维场景，CMDB状态好了、模型建立好了，这时候要面向运维。刚才讲了CMDB的监控，CMDB里面这些设备资源一转移到某一个模块下面就可以自动接入我们的监控，一录入进去监控就自动跑起来。当某一天发现异常了之后，发现某一台IT告警之后，要到CMDB查询主机状态是什么样的，需不需要做下一步的处理。如果需要处理，监控就告警，告警这块需要针对告警负责的业务人员进行告警，不要把A业务告警给B业务。这跟所有CMDB的每一个业务都可以关联起来。
第二我们讲集群模板，这个在我们内部是一个非常普遍的问题，大家知道玩游戏有非常多的大区，北京一区、北京二区，游戏很火三区、四区、甚至到几十区，对业务人员这种状态非常好，对运维人员是一个恶梦，游戏火起来之后会开新区，就是开一组新的逻辑服务。这个时候刚才讲的那些实例都要录入到CMDB，每一个业务有几百个实例，每一个实例下面挂着非常多的模块，每一个模块下面管理着非常多的设备，每一个层级里面制订属性很多，这时候必须要有一个模板，配几个模板生成几十个，否则会很费力，所以我们提供模板的功能，支持的就是从集群室里面批量的生成和管理，有些地方如果单独改单独去弄就可以了，这样就可以自动应用模板上面的属性，可以大幅度地减轻运维配制、维护的工作。
第三讲CMDB业务配置文件管理。每一个业务是有业务逻辑架构的，可能有非常多的模块，各个模块与模块之间是有访问关系的，就比如说你的接入层跟后台的逻辑层，DV层整个这块有访问关系的，表现就在配置文件上，所以运维都要维护配置文件，有些比较简单的就几个配置项，业务架构有时会有千上百个配置项，出一些错误就会导致一些问题。我曾经做过穿越火线的运维，穿越火线是韩国人开发的，业务架构做的不太好，那时候有两、三百个大区，有非常多的配置文件，当时还没有CMDB功能的话就非常混乱，比如说广东一区可以在房间里面继续玩，后面延缓二区，相当于你进入到广东一区看到的数据是广东二区，这是非常不能容忍的，发现一例这样的事件运维就把饭碗丢了，腾讯这块对于数据非常敏感，不容忍逻辑混换。我们在CMDB上面针对某一个模块它所要访问其他的相关联的模块，以变量的形式配置进去，当我们要生成实例的时候，把变量录入到CMDB的那些设备也好或者是属性也好，自动生成就可以下发到每一台服务器上面去，这个时候配置文件都是非常准确的，就不需要人一台一台上去改，防止改错的情况。甚至有时候配置好后，可以跟线上正在运行的业务配置文件比对，如果发现问题可以告警通知你，链接错误，比如某一个集群连到另外一个集群，这个错误就非常大了。
还有一块是进程管理，我们也是做到了非常轻量的业务进程的管理。每一台服务器上面跑了服务器和端口，每一台服务器上匹配了模块，比如登陆模块，这一块统一以模板的模式录入到CMDB之后，就可以生成实例之后对它的进程进行一个启停，所有的模块的启停都可以在CMDB操作。同时我们只要一接入，监控就可以自动取CMDB拿起每一台实例配置的端口进行一个监控告警。
这个是我们一个界面，你会把所有这些每一台主机上面跑的所有端口进程，绑定的IP、内网、外网都录入进去，可以看到它的状态，这个进程是在运行中还是已经红了，已经停了，整个都可以看到，同时还可以对它进行启停。
前面讲跟业务相关的，面向业务架构的，第四块就是讲除了业务架构之外CMDB还要活起来，怎么活起来？刚刚前面讲了一个信息的录入，信息录入其实是非常大的工作量，初次使用CMDB的时候，你所有的资产信息都是手动去录入，像这块有一部分其实是避免不了的，比如说你服务器的号贴在服务器上，当然也有扫描技术可以用，我们讲的是主机以上的OS以上的这些信息，比如说内存、硬盘、CPU、操作系统是什么样的、网卡、路由、防火墙等等所有这些东西都可以只要你把它录入进去之后，它就可以自己上报上去了，这些都可以不用再录了。甚至有一些线下的流程所能够录入的信息都可以对接，比如说服务器上架，或者网络交换机这块，像腾讯有一个架构平台部，他们上架有一个架构平台管理系统，他们那边有非常严格的流程，上某一台这个时候系统要录入或者扫描进去，把这些信息都可以录入进来。
还有一块是将这些信息录入进去之后，可能要看一些经常变化的状态，比如说CPU的占用率、使用率，这个很多时候是变化的，变化的话这块想要看到的话，就通过一个快照的功能，左边是大体实现的流程（见图），你可能想看的信息是不一样的，针对通用信息可以实时上报，最后到这个快照系统里面去，可能有时候你需要看一些业务内部的信息在服务器上是怎么样的，可以制订采集项，通过下行管道分发上去。到数据服务器、一个队列，你可以对信息进行查找。还有公共组件，可以看到公共组件实时的状态信息。
还有一块是CMDB的角色，CMDB虽然信息管理起来了，但是信息谁可以用谁不能用，谁能看谁能改，谁可以删除都有一个严格的限制，我相信每一个公司都有这样一个规章制度。所以在这块我们的CMDB可以去制订一个角色，每一个角色具有的权限是不一样的，可以通过模型自定义角色，可以修改。甚至针对CMDB上的功能模块都可以对应去做修改，可能A用户进来看到三个菜单，B用户进来有四个菜单，相当于一个企业有各个不同的层面，看到的内容也都是可以不一样的。
还有一块是API的对接，企业内部在用CMDB之前，以前有很多的现有的已经建立的CMDB，怎么把信息对接过来，无缝衔接到CMDB里面来。我们的计划是你可以针对每一个模型，做一个API，你可以针对这个模型，比如说把防火墙给管理起来，把防火墙的API放进来，这样你慢慢地把你的管理对象迁移到这里面来。
我们CMDB提供了非常多的自定义查询，我们经常会做各种各样的组合式的查询，各种外条件、BIM等等，可以在这里面制订各种各样灵活的条件，制订出API出来，可以在运营场景里面对它进行使用。
接下来给大家讲的是CMDB在运维应用场景的案例，这个案例就拿我们自己目前腾讯内部在游戏业务的场景举几个流程图给大家做一个分享。这是在我们腾讯内部目前CMDB的使用量，CMDB管理了这么多信息，我们管理了非常多的业务量，除了游戏之外还有像影视、文学、动漫、电信等等都在这里管理，管理的主机对象差不多有二十万，我们每天看了一下每天接口调用量一千万以上，它更重要的是信息库，除了自己定义固化信息，不同的运维人员在里面定义不同的定义性属性，差不多有八十多万。同时进程端口有很多，这里面我们把主要维度的信息给大家看一下。
针对日常的运维场景，CMDB是一个信息库运维的基石，比如说像集群搭建、业务发布、扩缩容、故障处理、业务迁移等等所有这些都是基于CMDB去做的。
这个讲的就是游戏开区的流程，针对其他的行业也都差不多，就是你重新搭建一组新服，新服在逻辑上都是隔离出来的和，第一你要获取资源，就是你有可能你是物理机，拿IP服务器拿过来，新建大区实例，然后获取的资源需要注册到我们CMDB来，同时你要去创建DB，把DB数据库整个这一块，另外在所有这些主题上面构建业务程序把它部署起来，部署完以后做一些初始化，初始化就把这个进程拉起来了，然后再部署监控，监控布好之后，我们QA或者QC进去了，开始测试看看业务是否有问题，测试OK之后这个时候我们清理测试数据，清理脏数据完了之后我们就可以对外。这个可以映射到企业内部其他的业务形态，其实都差不多。这块对CMDB来讲每一个结点都用到了，比如说获取资源有可能你是导入进去的，你们没有其他的虚拟化平台或者是云管平台，或者有时候用到的公有云或者是用到腾讯云、阿里云，整个这块都可以对接起来，然后把主机的资源打到我们的资源池里面。新建的实例就是用到新建的业务模板，通过模板编辑就可以建立起来。第三节点就是主机注册，这个时候放进去的时候放到空闲池，把CMDB的空闲池划到集群的模块下面，然后你创建DB，创建DB之后把信息录入到CMDB里面来，针对后来的运维的操作连接CMDB的话，可以直接从CMDB读取DB有可能是IP、域名端口的方式读取进来。然后部署版本，每一个集群、模块上面部署什么样的版本信息，需要有一个地方去维护，除了主机本身上面看到大的版本号，应该有一个信息库去维护，这时候你可以把它录入进去。然后初始化数据，从CMDB拉取相关的信息，填充到初始化数据里面去。
这是一个发布流程，发布肯定要选择发布范围，传统以前用一些开源工具直接填IP，在这里用到CMDB可能把它进行一个统一可视化管理起来，通过CMDB就可以管理你们的发布范围。
还有备份的目标主机这部分都是从CMDB做的。包括最重要的就是里面的一些状态，这个状态其实跟你公司企业内部的流程整个这块都是密切关联的，非常多的流程、系统都要到这里有一个状态单，包括老板要看业务某一个集群现在是什么状况，电子工单走到哪里了。都要通过这些做的。
这个就是一个故障替换流程，每一个流程、每一个节点都会针对CMDB做非常多的联动，要么消费它，要么写入它。
最后，在这里跟大家预告一个好消息，蓝鲸全新的CMDB在今年4月2号会对外开源出来，同时也会更新到我们蓝鲸社区版中v4.0版本中，期望与大家一起打造一个业界的CMDB。
另外，这个是我们蓝鲸的官网以及微信公众号，有关蓝鲸的实时动态与活动信息都会通过公众号对外发布，同时针对我们几千家蓝鲸社区版的有户，我们建立了一个QQ交流群，用于解答大家在布署、使用以及开发SaaS时遇到的问题，我们建了几个蓝鲸助手帐号在里面答疑，针对不同的类型的问题分了职能，有部署助手、开发助手、使用助手等，希望大家在使用蓝鲸时能快速得到帮助，好，我今天的分享就到这里，谢谢。