浅谈CMDB

什么是CMDB

CMDB，Configuration Management Database的简称，从英文单词中直译”配置管理数据库“，但实际上更多的被称呼为”资产管理系统“。
其实出现这种误差的起因在于不一样建设思路中对所要达成的”目标“不一样，而对该”Configuration“的理解不一样所致使。
CMDB一般具有存储”Configuration“、创建”Configuration“之间的关系、利用流程或工具维护”Configuration“数据和保证其数据正确性等功能
而在此基础上开放数据对外服务、联动其他平台（CI、CD、流程等）构建完善的运维架构体系是经常使用的作法。

为何要建设CMDB

在没有CMDB时，运维人员会采用excel、记事本或者纸质文件去记录相关的机房、机柜、物理设备、主机、应用相关的信息。
在这种状况下常常会遇到疏于更新数据或遗漏丢失数据致使，在整理业务架构、分析当前资源使用率、机房机柜等采购决策时作出错误的判断，致使资源浪费、故障排查难、迁移难等问题。
总结下来本质问题为：

1. 数据信息散乱、遗漏、不集中
2. 数据维护手段多种多样、无规范化处理
3. 数据正确率低
4. 数据有效利用率低

为解决以上问题，进行CMDB的建设，能够保证如下基本需求

1. 统一数据存储
2. 统一数据校验
3. 统一数据维护手段

而在此基础上开放CMDB数据给予其余平台消费，让数据获得充分的利用，例如根据关系链绘画架构图、故障根因分析等经典消费场景。

何时要建CMDB

很简单，当你吐槽excel的时候就能够开始了！

其实在你吐槽的时候，已经表明着公司的业务成长，你已经没法用当前的作法去很好的维护这些数据、协调你的工做。
而你总会想着有个地方能够统一的存储这些数据，有个web界面给你去查看、更新，接下来你只须要保证数据的不丢失，就能达到你想要的初期效果。
更进一步不断的优化该系统，使它更加的强大健壮时，你将会发现它不知不觉中成为了不少系统的基石，这其实就是CMDB最原始的雏形。
固然，如今CMDB已经不止怎么简单了，每家公司由于它自身的文化、需求不一样，造就的CMDB形态也各不相同。
而有些由于建设目标不明确，致使CMDB最终建设失败，推倒重来也不在少数。

建设CMDB注意事项

我的从工做中总结，建设CMDB需注意如下几点

1. 明确你的需求
   列出当前你所遇到的问题，分析其中起因，肯定最迫切、最麻烦的问题是什么，从而肯定你的需求是什么。
2. 制定你的目标
   整理出了需求以后，你得定下目标，不能只经过需求知足就已达成目标，目标必须是能够量化的，好比说接入了多少数据、数据的准确率等等
3. 肯定你的CMDB形态
   在你肯定了需求、初定了目标以后，基本已经确认了你建设的是什么样的CMDB，而后能够试图从IOS7层去看何种方向去丰富你的数据。

CMDB形态简介

1. 资产管理CMDB
   这种用户遇到的问题每每会是机房、机柜和物理设备等管理混乱、购买合同对不齐、交换机端口线路对不齐和IP地址网段分配散乱不清晰
   而从问题出发看出建设方向应是从下（物理层）往上去建设，将机房、机柜、物理设备、合同、交换机等信息录入并创建他们之间的关系。
   趋向于从摸得着到摸不着的数据丰富
2. 配置管理CMDB
   这种用户遇到的问题是业务信息混乱、应用端口分配错乱冲突、组件部署主机不清晰时，
   从问题出发看出建设方向应是从上（应用层）往下去建设，将从业务角度出发，将应用、中间件、主机等属性配置信息存放并创建他们之间的关系。
   趋向于从摸不着到摸得着的数据丰富

不管是哪一种方式，都是归一化的将其属性数据化、关系数据化存放，更加易于消费使用。

如何建设CMDB

建设CMDB需从战略方面开始、以战术方面落地实施

战略方面

从战略方面需作到如下四点

1. 明确建设目标以及建设方向：知道自身痛点得出需求，接着从需求出发设定量化目标，最后从量化目标出发明确建设方向。
2. 明确须要数据化的对象：全盘梳理建设方向所涉及到各个对象名称，需梳理各对象属性（过程与建模同理）
3. 整理资源间的关系：从对象列表中，整理其关系，从中区分核心与非核心，优先建设核心上的对象
4. 整理用户使用路径：从用户角度出发，模拟操做使用路径，梳理业务流程，好比如何录入、如何查看等

战术方面

采购 or 自研

在常见的运维团队里，具有研发基础或高级研发水平的人趋于少数。
若是要进行自研CMDB的话，天然须要寻求研发部外援或者招专职研发
但不管是招人，仍是团队调整以及磨合都是须要时间的，
并且这里也会有建设经验上带来的研发质量、需求实现误差等问题。
因此选择采购仍是自研能够从时间成本、人员成本两个维度去衡量

1. 考虑人员成本

   1. 团队中是否具有研发基础或高级研发水平的人
   2. 团队中当前工做安排是否能允许人员进行研发工做
   3. 团队中是否有相关建设经验的人员

2. 考虑时间成本

   1. 建设需求是否并不紧急实现（如1~3个月就算紧急）
   2. 若是须要招人，是否允许招聘时间和团队磨合时间（1到2个月）
   3. 若是须要培养，是否允许成员学习相关知识时间（1到2个月，甚至更久）

以上两个维度的问题中，若是以上问题，”是“居多时可考虑选择自研，”否“居多时考虑选择采购。
固然若是财大气粗，又不想麻烦的话，也能够选择采购。
但切记并非采购就等于没麻烦，选择成熟且领域顶尖的CMDB产品能够减小麻烦，但这里的技术维护成本、甲乙双方之间的沟通成本以及安全性都须要考虑。
也切记自研并非必定要从0开始，站在巨人的肩膀上也能够解决很多麻烦。

CMDB系统总体考量

我的在以往思考中对CMDB系统总体考量梳理以下，但愿能够提供参考，而这里只是浅谈就不展开了。

功能层面上

1. 考虑数据开放策略

   • 外部系统如何对接
   • 用户如何使用这些数据

2. 考虑数据安全问题

   • 访问如何进行权限校验
   • 数据是否须要加解密传输
   • 存储的数据是否须要脱敏

3. 考虑事件响应机制

   • 系统如何变动通知
   • 对接用户如何消费

4. 考虑数据维护环路

   • 如何数据读取的入口
   • 如何对数据进行变动
   • 查询语法是否知足需求
   • 如何验证数据正确性
   • 如何制定数据准入规范

5. 考虑数据如何展现

   • 展现数据的图表组件是否足够丰富
   • 是否提供通用以及强大的SQL层（查询语法）
   • 是否能依据不一样需求进行场景化展现

架构层面上

1. 考虑组件高可用

   1. 考虑前端web组件如何进行扩缩容（注意无状态、有状态）
   2. 考虑后端处理逻辑组件如何进行扩缩容（注意无状态、有状态）
   3. 考虑数据库选型

2. 考虑数据库容灾

   1. 考虑数据备份方案
   2. 考虑数据恢复机制方案

3. 考虑跨机房方案

   1. 考虑网络流量
   2. 考虑网络延迟
   3. 考虑集群建设

自研技术建设考量

1. 语言选择

   • python
   • golang

2. 考虑数据存储性能指标

   • 可承受量级
   • 查询效率
   • 写入效率
   • 查询丰富度

3. 考虑数据库存储方案

   1. 单数据库存储方案
   2. 多数据库存储解决方案

4. 考虑事件总线组件方案

   1. 成熟队列组件，支持发布订阅
   2. 高可用

5. 考虑数据入口方案

   1. 自动录入

      • agent定时任务主动推送
      • 服务端定时拉取信息

   2. 文件录入

      • excel
      • txt
   3. 对接流程变动录入

如何评估CMDB建设

在建设中，要对成果或者阶段作个评估，以便后续更加精进该系统或修正方向
而这时须要可量化的指标，因此就须要指定如下指标

1. 围绕建设目标

   1. 当前已管理的对象数：对象个数
   2. 当前已管理的对象数据量级：各对象的实例数据量、以及总数据量
   3. 当前热点消费数据分布：根据访问对象的次数（写入、读取)
   4. 当前热点消费的对象是否符合预期：判断是否符合建设目标中的核心对象
   5. 当前数据平均准确度：能够经过反馈数和平常维护时的记录去记录，若是平台有修正功能的话，能够是修正数据次数

2. 技术层面

   1. 平台性能

      • 平均查询速度：根据CMDB查多写少的场景，查询速度是一个很是重要的指标
      • 平均组件CPU使用率：持续优化各组件所使用
      • 平均组件内存使用率：持续优化各组件所使用
      • 平均组件IO使用率：持续优化各组件所使用
      • 最大并发数：测出最大并发数以便维护并优化平台
      • 平均磁盘占用：持续优化各组件所使用
      • 平均网络流量：持续优化各组件所使用

   2. 平台稳定性

      • 请求成功率：保证其余已对接的平台能正确的使用数据
      • 高可用有效性：保证平台的做为基石的健壮性

有趣的看法

CMDB与监控结合

CMDB通常存储的是静态稳态的数据，这表明这并不会有高频率的变更，从这点出发代表咱们没法从CMDB层面去看资源的当前运行态是如何的
而这时候咱们该怎么作呢？
监控平台是能够经过高效、丰富并支持分钟级或秒级的采集手段采集着各类对象的指标数据。
可是监控平台的数据在传统建设中，只有在遇到问题时才会来使用，这是极其浪费的事情。
因此经过CMDB + 监控平台两平台的数据结合，咱们能够结合稳态（配置、关系）和动态的数据（指标）去观测资源的各方面的状态
好比，经典场景中的”由业务关系出发的应用之间调度链以及实时请求访问状态图“，这个图例能够实时的观测到应用的运行状态，也从图中能够全局把控整个调度链路。
这是一个很是有趣而实用的场景。
还有着，从关系链进行告警根因分析、告警收敛也是很好的实践场景。
固然场景还有不少，能够值得去深挖。

如何关联起来？

CMDB的数据与监控平台的数据的关联，在于监控数据的维度概念

维度的简单理解就是sql语句中的where条件所使用的字段，维度值通常以字符串存储，能够参考influxDB的tag概念

监控平台的数据是从维度去定位到相关的对象的数据，好比经过mysql的ip、port定位到该mysql的指标数据
而CMDB中的数据实例中也会需具有这样的稳态数据，从这点出发，创建二者的共性数据关联策略就可将二者数据关联起来。
这里不详细展开。

地图化

在常见的CMDB中，录入的数据，都可以用列表展现，可是若是用地图呢？
能够像地图同样，检索查询定位你想要的点，而后经过拉动，扩大缩小查看周边的信息。
是否是很是有趣？
其实所谓的地图化，简单理解就是关系+场景化
那场景化是什么呢？
场景化，简单来讲就是"什么地图"
好比你是从业务场景去看，那这个地图就是业务地图，而后你想要定位mysql实例位置
那顺着业务出发层层分割，从业务->应用->依赖服务->Mysql服务->Mysql实例顺着定位。
这跟咱们看地图是同样的思路，从国家->省->市->县->镇->街道，是否是很贴切？

地图化有什么用？

在一般状况下CMDB中全部资源的关系都是平等的，就是一张很是巨大的网
而地图化就是经过特定场景化封装出有层次、有重点的关系链路网图，在越靠近源点的关系数据价值越高。
这样有利于梳理核心和非核心数据，去除干扰数据，专一场景消费使用，让数据最大价值化。

结束语

本文是我的经历中对CMDB认识的总结，但愿对各位建设CMDB路上有所帮助，谢谢