谈一谈CMDB

大家好，我是易安！今天我们谈一谈运维相关的话题，配置管理，专业一点就叫作 CMDB（Configuration Management DataBase）。

概念

CMDB并不是一个新概念，它源于ITIL（Information Technology Infrastructure Library，信息技术基础架构库）。而ITIL这套理论体系在80年代末就已经成型，并在当时和后来的企业IT建设中作为服务管理的指导理论得到广泛推广和实施。但是为什么这个概念近几年才被我们熟知？为什么我们现在才有意识把它作为一个运维的核心部件去建设呢？

我想主要有两个因素，一个起了限制作用，一个起了助推作用。

CMDB这个概念本身的定义问题，限制了CMDB的实施；
互联网技术的发展驱动了运维技术的发展和演进，进而重新定义了CMDB。

传统运维阶段的CMDB

按照ITIL的定义：

CMDB，Configuration Management

DataBase，配置管理数据库，是与IT系统所有组件相关的信息库，它包含IT基础架构配置项的详细信息。

看完上面这个描述，我们能感觉到，这是一个很宽泛的概念描述，实际上并不具备可落地的指导意义。

同时，CMDB是与每个企业具体的IT软硬件环境、组织架构和流程强相关的，这就决定了CMDB一定是高度定制化的体系。虽然我们都知道它不仅仅是一个存储信息的数据库那么简单，但是它的具体形态是什么样子的，并没有统一的标准。

从传统IT运维的角度来看，运维的核心对象是资源层面，所谓的基础架构也就是网络设备和硬件设备这个层面；各种关联和拓扑关系，基本也是从服务器的视角去看。所以更多地，我们是把CMDB建设成为一个以设备为中心的信息管理平台。

这也是当前绝大多数公司在建设运维平台时最优先的切入点，因为这些运维对象都是实体存在的，是最容易被识别的和管理的；像应用和分布式中间件这种抽象的逻辑对象反而是不容易被识别的。

这种形态，如果是在软件架构变化不大的情况下，比如单体或分层架构，以服务器为中心去建设是没有问题的。因为无论设备数量也好，还是申请回收这些变更也好，都是很有限的，也就是整个IT基础设施的形态变化不大。

高大上的ITIL体系更多的是被当做流程规范来落地的，真正体现在技术方案和技术产品上的落地并不多。我想这是实施过程中对ITIL理解和运用的一大误区。

互联网运维中的CMDB

进入到互联时代，随着互联网运维力量的崛起，CMDB这个概念也真正地得到了落地实践，从理论概念的方法论阶段过渡到了具备具体技术方案的可实施阶段，而且得到了业界的持续分享和传播。我们现在能够看到的CMDB经验分享，基本上都是中大型互联网公司的运维最佳实践。

不过，值得注意的是，“此CMDB”已经非“彼CMDB”。我们前面提到，传统运维阶段，我们更多是以设备为核心进行管理，但是到了互联网技术阶段，这个核心就变了，变成了应用这个核心对象。互联网技术的快速发展，大大推进了微服务技术架构的落地和实践，这种场景下，应用各维度的管理复杂度、应用的复杂度就逐渐体现出来了，所以我们的很多运维场景就开始围绕着应用来开展。

与此同时，云计算技术也在蓬勃发展，逐步屏蔽了IDC、网络设备以及硬件服务器这样的底层基础设施的复杂度，有公有云或私有云厂商来专注聚焦这些问题，让我们的运维不必再花过多的精力在这些基础设施上面；同时，单纯以硬件为核心的CMDB形态也被逐步弱化。

所以，此时的CMDB，仍然可以叫做配置管理数据库，但是这个配置管理的外延已经发生了很大的变化。之前所指的简单的硬件资源配置管理，只能算是狭义的理解；从广义上讲，当前的应用以及以应用为核心的分布式服务化框架、缓存、消息、DB、接入层等基础组件，都应该纳入这个配置管理的范畴。

所以在这个时期，我们提到的运维自动化，远不是自动化的服务器安装部署交付或网络自动化配置这种单一场景，而是出现了持续交付、DevOps、SRE等更适合这个时代的对运维职责的定义和新的方法论。

到了这个阶段， 传统运维思路下的CMDB，因为管理范围有限，可以定义为狭义上的CMDB；而互联网运维思路下的CMDB外延更广，我们称它为广义的CMDB。新的时期，对于CMDB的理解也要与时俱进，这个时候， 思路上的转变，远比技术上的实现更重要。

面向资源管理

我来梳理一下，在建设运维的基础管理平台时通常要做的事情。

第1步，把服务器、网络、IDC、机柜、存储、配件等这几大维度先定下来；
第2步，把这些硬件的属性确定下来，比如服务器就会有SN序列号、IP地址、厂商、硬件配置（如CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等等；网络设备如交换机也会有厂商、型号、带宽等等；
第3步，梳理以上信息之间的关联关系，或者叫拓扑关系。比如服务器所在机柜，虚拟机所在的宿主机、机柜所在IDC等简单关系；复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系；
第3.5步，在上面信息的梳理过程中肯定就会遇到一些规划问题，比如，IP地址段的规划，哪个网段用于DB，哪个网段用于大数据、哪个网段用于业务应用等等，再比如同步要做的还有哪些机柜用于做虚拟化宿主机、哪些机柜只放DB机器等。

以上信息梳理清楚，通过ER建模工具进行数据建模，再将以上的信息固化到DB中，一个资源层面的信息管理平台就基本成型了。

但是， 信息固化不是目的，也没有价值，只有信息动态流转起来才有价值（跟货币一样）。接下来我们可以做的事情：

第4步，基于这些信息进行流程规范的建设，比如服务器的上线、下线、维修、装机等流程。同时，流程过程中状态的变更要同步管理起来；
第5步，拓扑关系的可视化和动态展示，比如交换机与服务器之间的级联关系、状态（正常or故障）的展示等，这样可以很直观地关注到资源节点的状态。

至此，从资源维度的信息梳理，以及基于这些信息的平台和流程规范建设就算是基本成型了。这个时候，以服务器简单示例，我们的视角是下面这样的：

面向应用管理

上面说明了CMDB的基础信息部分，如果从传统的SA运维模式，这些信息已经足够，但是从应用运维的角度，这些就远远不够了。

这时我们就需要一个非常非常重要的句柄： 应用名，或者叫应用标识。至此，应用运维里面最最重要的一条联系也就产生了： “应用名-IP“的关联关系（这里也可以是定义的其它唯一主机标识，如主机名、容器ID等等，因为我们使用的方式是IP，所以这里就以IP示例）。

之所以说“应用名”和“应用名-IP关联关系”非常重要，是因为它的影响力不仅仅在运维内部，而是会一直延伸到整个技术架构上。后面我们会介绍到的所有平台和系统建设，都跟这两个概念有关。

CMDB是IP为标识的资源管理维度，有了应用名之后，就是以应用为视角的管理维度了。首先看一下应用会涉及到的信息：

应用基础信息，如应用责任人、应用的Git地址等；
应用部署涉及的基础软件包，如语言包（Java、C++、GO等）、Web容器（Tomcat、JBoss等）、Web服务器（Apache、Nginx等）、基础组件（各种agent，如日志、监控、系统维护类的tsar等）；
应用部署涉及的目录，如运维脚本目录、日志目录、应用包目录、临时目录等；
应用运行涉及的各项脚本和命令，如启停脚本、健康监测脚本；
应用运行时的参数配置，如Java的jvm参数，特别重要的是GC方式、新生代、老生代、永生代的堆内存大小配置等；
应用运行的端口号；
应用日志的输出规范；
其他。

上面的梳理过程实际就是标准化的过程。我们梳理完上述信息后就会发现，这些信息跟CMDB里面的资源信息完全是两个维度的东西。所以从信息管理维度上讲，把资源配置和应用配置分开会更清晰，解耦之后也更容易管理。

好了，按照上面CMDB说的套路，梳理完成后，就是要进行信息的建模和数据的固化，这时就有了我们的“应用配置管理”。再往后，就是基于应用配置管理的流程规范和工具平台的建设，这就涉及到我们经常说的持续集成和发布、持续交付、监控、稳定性平台、成本管理等等。

从应用的视角，我们配置管理，应该是下面这样一个视图（简单示例）：

好了，有了资源配置信息和应用配置信息，这两个信息应该怎么统一管理起来呢。直接看图：

至此，CMDB和应用配置管理的分层分解就完成了，应用名关联着应用配置信息，IP关联着资源信息，二者通过“应用名-IP”的对应关系，联系到一起。

如何管理应用

微服务架构下会有很多应用产生出来，少则十几、几十个，多则上百甚至上千个。这时我们面临的第一个问题就是如何有效地组织和管理这些应用，而不是让它们在各处散乱，命名方式和层次结构可能还不统一。

你可能接触过“ 服务树”的概念，这个提法是小米在早期互联网运维实践的分享中传播出来的。

从服务树这个名字中，我们就可以了解到，有效组织和管理应用的方式，就是把它组织成一个树形的层次结构。这种管理模式，无论是在BAT，还是在其它的互联网公司，基本都是一样的思路和模式，所以叫法虽然不同，但是思路上却是相通的，可谓异曲同工。

基于业务维度的拆分，对应产生了我们的应用拆分原则。比如对于电商公司，大的维度会有电商、支付、广告、流量和搜索等业务领域；进一步，电商业务领域里最典型的会有用户、会员、商品、交易、商家、店铺以及物流等；这里面还可以再进一步细分，比如商品会有详情、SKU、SPU、库存、评价、标签等。

讲到这里，我们再看一下技术团队的组织架构，基本上是对应着整个业务技术架构的拆分的。也就是 业务架构决定了技术架构，而技术架构又决定了一个研发团队的组织架构，这个组织架构中不同的团队单元分别承担着对应业务的需求开发和实现职责。

上面这个组织架构建设的逻辑和思路，也是我们在组建团队和职责划分时可以参考的。

这样一个逻辑讲下来，我们的 应用管理思路 其实也就明晰了： 产品线-业务团队-应用。

这里举个电商商品的例子就是：电商技术-商品团队-商品中心-商品详情等。

当然因为每个公司对组织架构定义的方式不同，也可以用一、二级部门这样的方式来指代。但是具体团队的分工和职责，一定是来自于业务架构决定的技术架构，只有这样，各业务团队才会职责清晰，配合协作才会顺畅起来。

对于应用名定义，要设定规范，比如：

应用名必须以大小写英文字母以及下划线组合；
应用名长度不超过40个字符，尽量简单易懂；
不允许出现机房代号和主机名称这样的信息。

简单举例，商品中心命名为itemcenter，商品详情命名为detail。

这里做个小结：到了软件运维阶段，运维工作是否可以高效地组织开展，很大程度上，在前面的业务架构拆分阶段就决定了。也就是业务架构拆分得是否合理、职责是否明晰，决定了后续团队组织架构是否合理、团队职责是否明晰。如果这点没做好，到了运维阶段必然就是混乱的。

运维能力的体现，一定是整体技术架构能力的体现，割裂两者单独去看，都是没有意义的。同时，对于当前仍然把运维割裂建设的研发团队，也需要去思考一下在组织架构建设上的合理性了。

应用的集群服务分组

上述讲到的是应用的组织管理，看上去逻辑思路相对清晰，组织起来也不复杂，但是再往下，应用的集群服务分组建设就会相对复杂了。

为什么会有集群服务分组呢？我们一起来看这么几个需求场景。

场景一：多环境问题。

我们常见的环境会有开发联调环境、集成测试环境、预发环境、线上环境等等。后面我们讨论持续交付时会讲到，实际场景下所需要的环境会更多。

场景二：多IDC问题。

对于大型互联网业务，会做业务单元化，或者有海外业务拓展需求的场景，我们会在多个IDC机房部署应用，应用代码是相同的，但是配置可能会不同。

场景三：多服务分组问题。

这个场景就跟具体业务场景相关了。举个例子，比如商品中心IC这样一个核心应用，对外会有商品详情、交易下单、订单、购物车、评价、广告、秒杀活动、会场活动、商家、店铺等一系列应用依赖它，但是这些依赖它的应用优先级是不一样的。

核心应用和非核心应用：比如交易支付链路上的应用属于核心应用，任何时候都必须要优先保障，但是对于评价、商家和店铺这些应用优先级就低一些。反过来理解就是一个应用出现故障，是不是会影响业务收入，如果影响就属于核心应用，如果不是或者影响非常小，那就属于非核心应用。所以IC这个应用下面，就会有IC的交易分组，IC的广告分组、IC的电商分组等， 这些分组就会相对固定和静态。
场景因素决定。这个对于电商就会比较典型，比如大促时的秒杀场景，对于参加秒杀活动的商品，瞬时的访问量就会非常大，而不参加活动的商品就不会有这么大的访问量。所以这时为了隔离较大的流量，就需要有多个不同的秒杀IC分组，从资源层面进行隔离；同时上层秒杀活动的应用在配置中心配置依赖时，就要配置到对应的秒杀IC集群分组上，这样即使秒杀IC出现问题，也不会影响正常的商品IC访问。所以根据场景，不同阶段就会有IC的大促秒杀分组， 这种类型的分组就需要根据实际的业务场景来决定，是个动态调整的过程，需要开发和运维一起来讨论和验证。

一般情况下，集群服务分组会有以上三个维度中的一个或多个来决定。还是以商品中心IC为例，按照上面的介绍，就会对应如下关系：

至此，“ 应用-集群服务分组-资源”的对应关系就建立起来了。这里我们叫它“应用树”或者“服务树”都可以，不管叫什么，这个信息是CMDB中最为关键和核心的信息。为什么是最关键和核心的呢？

基础服务体系中的应用

这里我们以应用为核心来看，CMDB中会保存“应用-分组-资源”的对应关系，这个关系对于周边系统来说都是需要的，举例如下。

监控系统。

我们需要以上的对应关系，监控到每个应用、每个集群以及每台机器上的关键信息。

发布系统。

我们需要将每个应用对应的代码进行编译打包，然后发布到对应集群的主机上，也需要这个对应关系。

服务化框架。

需要依赖应用和集群分组两个信息，其中主要是对应用名和集群分组名的依赖，对于服务化框架来说，更多的是通过其配置管理中心注册的应用名，来实现应用的服务和API管理，这里要做到与CMDB统一。同样，像LVS和Nginx这样的四七层负载，以及ZK这样的开源分布式配置管理，凡是涉及服务注册、服务发现以及服务上下线的基础服务，都是类似思路。

基础服务中。

如分布式DB、分布式缓存和消息等，就需要应用的应用名，以及应用与资源IP的对应关系，或者集群分组与IP的对应关系。

应用名，是因为要建立应用与分布式服务实例之间的关系。如应用与缓存NameSpace的对应关系，应用与消息Topic的对应关系等，以便于这些基础服务的生命周期管理和自动化开发。
应用与资源的对应关系，是因为有些核心资源是要做ACL访问控制的。比如对于用户、交易或支付这样非常敏感的数据，它们对应的数据库就不允许随意连接，而应该是仅限于授权过的应用访问。这时就要针对应用对应的IP地址进行白名单配置。一方面，可以通过分布式DB中间件进行配置；另一方面，也可以通过在DB层面进行设置，比如MySQL就可以直接配置白名单策略；同时也可以在机器的iptables上配置，至于如何配置就看具体需求了，但是无论怎样，应用与资源的对应关系是非常重要的。

稳定性保障平台，或者服务治理平台。

针对系统的稳定性，我们会在应用中做很多的降级限流和开关预案策略，这些都是跟应用直接关联的。而且按照我们前面介绍的，不同的集群分组，策略可能会有不同，所以又会跟集群分组相关。同时，这些策略最终下发到具体服务器上运行的应用实例上，所以这里就会需要应用、集群分组以及对应的资源关系。

总结一下，简单示意图如下：

总结

今天我们讲了运维相关的概念CMDB，从传统阶段到互联网发展应用，从面向资源到面向应用。

CMDB是运维的基石，但是要发挥出更大的价值，只有基础是不够的，我们要把更多的精力放到上层的应用和价值服务上，可以说应用才是运维的核心。

如果仅仅基于CMDB的资源信息作自动化，最多只能做出自动化的硬件资源采集、自动化装机、网络-硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务还很远，就更谈不上给业务带来价值了。但是基于应用这一层去做，就可以做很多事情，比如持续集成和发布、持续交付、弹性扩缩容、稳定性平台、成本控制等等，做这些事情带来的价值就会大大不同。

基于以应用为核心的CMDB中，又衍生出“应用-集群服务分组-资源”这样一个运维体系中的核心关系。经过这三部分的分析，我们之前所说的基于应用为核心的运维视图就可以建立出来了：