背景
最近半年,都在开发部门内部的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在这些系统或者流程中,起到一个数据基石的作用,我们举几个例子:
- 如果没有CMDB的配置数据,ITSM流程对用户(开发)就很难入手,比如要申请一台机器,流程里会有很多IT专用描述,开发无法快速申请流程
- 如果没有CMDB,那么DevOps中要实现自动化持续集成和交付,开发要将服务部署到哪台机器,运维无法得知
那么总结一下,CMDB能做的事情,主要有以下几点:
- 能数字化IT资产,并且提供到IT资产管理一个可靠的参考数据
- 能帮忙快速完成ISM流程,以及更加有效管理ITSM流程
- 能将业务与IT资产做关联,实现业务与IT资产的有效管理
怎么做
明白CMDB能做什么,那么我们应该如何设计一个合理CMDB呢?
首先,市场上已经存在各色各样的CMDB平台,主要有以下几个:
- 腾讯蓝鲸平台CMDB配置系统,基于腾讯蓝鲸平台的CMDB配置系统
- ITOP,一个完整的开源,ITIL,基于Web的服务管理工具,包括完全可定制的CMDB,帮助台系统和文档管理工具。
- 怎么开发CMDB平台这里就不做描述,无非几点:
- 可自由配置的CMDB模型的 管理web界面
- 开发标准API接口(主要模型的CRUD),对第三方工具提供服务
模型设计
一个可维护的CMDB平台,肯定脱离不了前期模型设计,所以一个良好且能够向前兼容的模型设计至关重要,因此我这边简单罗列了一下模型几大类,以及它们之间的关系:
- 业务模型,这里业务模型可以拆分多级,最多三级,因为三级业务树基本上能够满足大部分业务等级拆分
- 模块模型,模块即是从开发角度去理解的项目粒度,通俗的说,就是一个单独且完整的项目,
- 设备模型,就是服务器,包括:虚拟机、物理机、容器等
- 持续集成相关模型,主要包括:CI(持续集成)、CD(持续交付)等模型
- 网络架构相关模型,主要包括:网络策略、域名、证书等
再就是需要设计模型与模型之间的关系,这里会很绕,但是为了让大家更加清晰了解CMDB的设计,这里简单绘画了一下:
模型生命周期
每个CMDB中模型,都有其生命周期流程,结合ITSM就可以完成实现模型的生命周期状态扭转。
注意事项:
** 在CMDB实现阶段:一定要变成运维和运维研发的共同项目,并且具体的配置项管理人要全程参与,比如说需求讨论、测试、上线验收等等(运维研发项目都可以遵循该模式) **
导致CMDB失败的因素
- 在复杂流程上消耗太多的时间—我们是创建一个CMDB库,不是一个流程系统。
- 没有指定配置项负责人—-确保配置项有人专职维护。
- 目标过大,涵盖太多的功能—-比如说IT采购和预算管理等等。
- 颗粒度不合适—-配置合理的CMDB的配置项层次和粒度非常重要。
- 存在组织隔阂—-CMDB是一个集成体系,靠流程中的每一个人通力协作,而不是某个人。
导致CMDB成功的因素
- 业务导向。比如说我们在CMDB的新的系统中实时加入QR码技术,为了降低资产盘点的工作量。
- 能自动发现就自动发现,降低配置管理的成本,但自动发现的信息不能用来做告警。
- 配置项的管理员必须全程参与,需求定型、测试及验收等等。
- CMDB系统建设完成之后,其他系统必须和他联动。比如说监控、质量、容量等等,用场景驱动配置项的管理。
- 流程一定要平台化,不要让流程脱离CMDB存在,比如说搞一个OA流程,这个是很致命的。
- CMDB要持续演进,特别是云端资源的管理。
- 配置项和流程必须要文档化,后期要进行CMDB培训。
未来规划——自动化/智能化/更安全的运维
目前绝大部分的CMDB数据都是走运维人工手动录入,是否能够做到自动化,甚至智能化。
让数据自动化主要靠以下几点:
- 建立数据生命周期管理,自动化流程驱动数据更新
- 与多个运维工具对接,促进数据消费,提高数据流动性
- 通过规则校验以及人工审计确保及时发现和修复异常数据
依托CMDB的数据基石,能让运维走向智能化,运维的价值在于交付能力,主要:
- 开发能够随时交付,无需运维过多参与,自动化运维
- 实时监控,智能化告警,提前告知开发进行预警
- 服务异常自愈,依托CMDB数据,能够自动重启服务完成服务异常自愈
总结
CMDB其实就是一个数据管理平台,开发技术上难度不大,最大难度在于数据,以下几点:
- 第一要保证数据的准确性
- 第二要能快速自动化获取数据
- 第三数据模型以及其关联设计,主要完成这三点
但是完成CMDB数据后,只是迈开自动化/智能化运维的第一步,后面还需要基于CMDB去完成整个DevOps流程自动化/智能化。
- 本文作者: Qborfy
- 本文链接: https://www.qborfy.com/today/20230109.html
- 版权声明: 本博客所有文章除特别声明外,均采用 MIT 许可协议。转载请注明出处!