浅谈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路上有所帮助，谢谢