共计 6679 个字符，预计需要花费 17 分钟才能阅读完成。
大家好，我是易安！明天咱们谈一谈运维相干的话题，配置管理，业余一点就叫作 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 中，又衍生出“利用 - 集群服务分组 - 资源”这样一个运维体系中的外围关系。通过这三局部的剖析，咱们之前所说的基于利用为外围的运维视图就能够建设进去了：
本文由 mdnice 多平台公布
