自动化运维系列-资产管理系统CMDB
# 自动化运维系列之CMDB
# CMDB 系统介绍
cmdb 翻译过来是 Configuration Management Database, 即配置管理数据库。从字面意思理解，大家很容易理解即为系统或软件的配置文件或参数的管理。其实这个理解是比较狭隘的，从广义上理解则为一切资源的管理系统，包括各种IT活动中物理资源和虚拟资源。总结定义如下：
狭义的定义： 系统或软件的配置文件或参数的管理系统。 广义的定义： 一切资源的管理系统，包括各种IT活动中物理资源和虚拟资源。为运维自动化工作提供基础数据支撑 - 物理资源：包括服务器、网络设备、机柜、机房、人员等 。 - 虚拟资源：包括软件、IP、域名、业务等。
cmdb 是一切自动化的基础，在运维自动的过程中起到了至关重要的角色。可以这样说，cmdb系统的崩溃，将会导致一切上层的自动化变得毫无意义。
# 如何构建CMDB系统
此处我们的CMDB系统定位为自动化运维的存储仓库，包括物理和虚拟资源。
- 抽象业务运维
抽象运维业务场景，以场景来驱动资产的模型的抽象。达到适应各种业务场景的目的。而不要抽象物理或虚拟资源本身的业务属性。
- 状态流程控制
使用详细的流程来控制资源的整个生命周期。流程分2种，例内和列外。列内流程为正常的流程如服务器的上线下线。列外的流程为特殊需求的流程，在现有流程无法满足的情况的特殊流程。
- 自动汇报+手动补充
任何系统都不可能做到完全的自动化，我们要以二八原则来看待，即80%实现自动化，20%靠人工来补充。但是需要做好人工修改的控制和记录，切勿权限过大，造成人为的误修改。
- 关系拓扑可视化
在资产系统中实现各资产的关系拓扑，供其他外部系统调用使用；此处注意系统边界问题，引用他人的一段描述如下：
CMDB实现拓扑是为了故障定位，但不能实现故障定位；CMDB实现资源管理，可以去评估故障影响，但不能实现故障和变更影响评估；CMDB实现业务拓扑是为了快速的故障定位，但不能实现故障根因分析；一切都是因为在CMDB提供的数据基础之上，周边系统（变更、监控、发布）借助的CMDB提供的数据能力，实现自身的场景化系统能力。来源 (opens new window)
- api接口
除了管理各资源外，还需要提供丰富的API，与外部系统做交互。
API 需要做好权限的控制、限流和调用日志的记录，以便后期审计。
至此，我们的资产管理系统便构建完成了。
# CMDB运维的痛点
在构建完成后的运维工作也是一大重点，在各业务流程的实时过程中难免会有各种问题，造成数据各种问题。其中最大的痛点总结如下：
- 流程不能使用所有应用场景
- 数据准确性
针对这下懂点应如何应对呢？可通过以下方式解决；
# 系统流程
增加列外流程，通过流程控制资源属性的变更，尽可能的减少人为的修改；
# 审计盘点
- 阶段性的遍历资产，核对资产属性，增加自我发现错误和修复错误的能力；
- 构建相关审计功能，可以记录相关资产的整个生命周期的变动；
# 总结
资产管理系统CMDB，已经是老生常谈的问题，各个大厂都自建自己的CMDB系统以适应其个性化的业务需求。在个性化的业务下，很难形成统一的解决方案，但是有些经验和教训还是可以提取共享的。总结以上如下：
- 以真实的业务场景来驱动cmdb的构建，包括模型和流程；
- 构建例外的业务流程，以满足个性化的复杂需求，减少人工参与造成的问题；
- 可通过流程控制和自审计来减少错误数据的产生；