背景

最近半年，都在开发部门内部的CMDB平台和申请流程，因此对CMDB有了一定了解，但是又不够系统，所以希望写一篇文章能够系统完整的认知一下CMDB，包括以下几点：

• 是什么
• 能做什么和怎么做
• 优秀方案
• 未来方向

是什么

CMDB(Configuration Management Database)，配置管理数据库，主要包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。
CMDB存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。
CMDB存储目标定义为：配置管理致力于通过维护IT基础设施和IT服务的逻辑模式来协助管理IT服务的经济价值(客户需求、质量和成本的结合)，并将与此相关的信息提供给其他业务流程。它通过识别、监测、控制和提供有关配置项及其版本方面的信息来实现目标。
以上描述来自百度百科CMDB。

按照个人理解，CMDB按照比较容易理解的说法，CMDB主要存储公司内部IT基础架构数据存储和配置，能够数字化IT资产与业务的关联关系。

更加明确的说，CMDB是运维的基础核心系统，包括运维所需要的元数据，同时共享数据管理源。 CMDB存储的数据包括但不限于：

• 逻辑资源，指的是底层物理资源对应的逻辑资源，包括：xxx系统、xxx服务、xxxApp等
• 物理资源，指的是可供运维人员实际操作的物理资源，包括：服务器(cvm、物理机、容器)，机房、机柜、网络设备、链路资源、配件等

能做什么

上面描述CMDB是什么，CMDB到底能做什么呢？或者它对运维有什么作用呢？

这里需要简单介绍几个概念：

• ITSM(IT service management), IT服务管理，主要是给用户提供标准流程完成IT资产交付，和管理这些IT流程的系统
• ITIL(Information Technology Infrastructure Library)，IT服务管理标准库， 是ITSM最常用的实现方案，侧重于使 IT服务与业务需求保持紧密关联
• DevOps由英文 Development（开发）和 Operations（运维）组合而成，是开发和运维紧密结合的思想理念，是开发和运维团队之间的流程能够自动化和持续集成、交付，从开发到交付部署形成一个循环的过程。后面我们会单独抽出一个文章做详细了解。

上面的几个概念，只要是IT从业者或多或少都有接触到，那么CMDB在这些系统或者流程中，起到一个数据基石的作用，我们举几个例子：

1. 如果没有CMDB的配置数据，ITSM流程对用户(开发)就很难入手，比如要申请一台机器，流程里会有很多IT专用描述，开发无法快速申请流程
2. 如果没有CMDB，那么DevOps中要实现自动化持续集成和交付，开发要将服务部署到哪台机器，运维无法得知

那么总结一下，CMDB能做的事情，主要有以下几点：

1. 能数字化IT资产，并且提供到IT资产管理一个可靠的参考数据
2. 能帮忙快速完成ISM流程，以及更加有效管理ITSM流程
3. 能将业务与IT资产做关联，实现业务与IT资产的有效管理

怎么做

明白CMDB能做什么，那么我们应该如何设计一个合理CMDB呢？

首先，市场上已经存在各色各样的CMDB平台，主要有以下几个：

• 腾讯蓝鲸平台CMDB配置系统，基于腾讯蓝鲸平台的CMDB配置系统
• ITOP，一个完整的开源，ITIL，基于Web的服务管理工具，包括完全可定制的CMDB，帮助台系统和文档管理工具。
• 怎么开发CMDB平台这里就不做描述，无非几点：

1. 可自由配置的CMDB模型的 管理web界面
2. 开发标准API接口（主要模型的CRUD），对第三方工具提供服务

模型设计

一个可维护的CMDB平台，肯定脱离不了前期模型设计，所以一个良好且能够向前兼容的模型设计至关重要，因此我这边简单罗列了一下模型几大类，以及它们之间的关系：

• 业务模型，这里业务模型可以拆分多级，最多三级，因为三级业务树基本上能够满足大部分业务等级拆分
• 模块模型，模块即是从开发角度去理解的项目粒度，通俗的说，就是一个单独且完整的项目，
• 设备模型，就是服务器，包括：虚拟机、物理机、容器等
• 持续集成相关模型，主要包括：CI(持续集成)、CD(持续交付)等模型
• 网络架构相关模型，主要包括：网络策略、域名、证书等

再就是需要设计模型与模型之间的关系，这里会很绕，但是为了让大家更加清晰了解CMDB的设计，这里简单绘画了一下：

模型生命周期

每个CMDB中模型，都有其生命周期流程，结合ITSM就可以完成实现模型的生命周期状态扭转。

注意事项：

** 在CMDB实现阶段：一定要变成运维和运维研发的共同项目，并且具体的配置项管理人要全程参与，比如说需求讨论、测试、上线验收等等（运维研发项目都可以遵循该模式） **

导致CMDB失败的因素

1. 在复杂流程上消耗太多的时间—我们是创建一个CMDB库，不是一个流程系统。
2. 没有指定配置项负责人—-确保配置项有人专职维护。
3. 目标过大，涵盖太多的功能—-比如说IT采购和预算管理等等。
4. 颗粒度不合适—-配置合理的CMDB的配置项层次和粒度非常重要。
5. 存在组织隔阂—-CMDB是一个集成体系，靠流程中的每一个人通力协作，而不是某个人。

导致CMDB成功的因素

1. 业务导向。比如说我们在CMDB的新的系统中实时加入QR码技术，为了降低资产盘点的工作量。
2. 能自动发现就自动发现，降低配置管理的成本，但自动发现的信息不能用来做告警。
3. 配置项的管理员必须全程参与，需求定型、测试及验收等等。
4. CMDB系统建设完成之后，其他系统必须和他联动。比如说监控、质量、容量等等，用场景驱动配置项的管理。
5. 流程一定要平台化，不要让流程脱离CMDB存在，比如说搞一个OA流程，这个是很致命的。
6. CMDB要持续演进，特别是云端资源的管理。
7. 配置项和流程必须要文档化，后期要进行CMDB培训。

未来规划——自动化/智能化/更安全的运维

目前绝大部分的CMDB数据都是走运维人工手动录入，是否能够做到自动化，甚至智能化。

让数据自动化主要靠以下几点：

1. 建立数据生命周期管理，自动化流程驱动数据更新
2. 与多个运维工具对接，促进数据消费，提高数据流动性
3. 通过规则校验以及人工审计确保及时发现和修复异常数据

依托CMDB的数据基石，能让运维走向智能化，运维的价值在于交付能力，主要：

1. 开发能够随时交付，无需运维过多参与，自动化运维
2. 实时监控，智能化告警，提前告知开发进行预警
3. 服务异常自愈，依托CMDB数据，能够自动重启服务完成服务异常自愈

总结

CMDB其实就是一个数据管理平台，开发技术上难度不大，最大难度在于数据，以下几点：

• 第一要保证数据的准确性
• 第二要能快速自动化获取数据
• 第三数据模型以及其关联设计，主要完成这三点

但是完成CMDB数据后，只是迈开自动化/智能化运维的第一步，后面还需要基于CMDB去完成整个DevOps流程自动化/智能化。

赏

谢谢你请我吃糖果

支付宝

微信