如何建立基础架构标准化的运维体系之CMDB

何为CMDB

维基百科的定义：配置管理数据库（configuration management database）简称CMDB，是信息技术基础架构库（ITIL）用语，是组织用来储存软件硬件资产（常称为形态项目CI）资讯的数据库。配置管理数据库可以将形态项目拆解到对应的逻辑层。数据库类似组织的资料仓储，也会记录各资产之间关系的资讯。CMDB提供方式可以了解组织的关键资产以及彼此之间的关系，例如信息系统、upstream来源以及资产之间的相依性、以及资产的downstream目标。

下面是ChatGPT给的定义：

未来，我更喜欢说CMDB银行换个名字叫UMC（Unified Metadata Center）

为何CMDB

从以下3个方面来看为什么需要CMDB。

从定义来看，CMDB本质上是一个存储软硬件资产的数据库。一般由公司内部技术部的基础架构团队负责管理和维护。技术部在没有CMDB之前，通过各类表格进行硬件资产的入库登记、机房上架信息登记、软件资产登记等各类的信息登记。一是人工维护；二是信息不准；三是效率低下，虽说诸多缺点，但没有CMDB也是万万不能的。

从作用来看，管理和维护由基础架构团队负责，着眼于资产管理，面向底层的软硬件资产的录入、查询、修改。一是替代原始的资源表格；二是起到快速检索和资源共享的作用。总体来说服务于运维，小范围内赋能运维对软硬件资源的管理。

从数据来看，录入的信息仅限于软硬件资产，数据的流动受限于的部门墙仅在技术部，甚至只局限在运维团队。数据本身的价值，未有效使用（被消费），一方面局限在某一团队，无法保障数据被充分消费也就无法保障；另一方面局限在软硬件资产管理上，没有从应用或者业务系统的视角，自上而下的进行资产的拆解和数据的血缘关系培养

弃之可惜，食之无味

行业统计数据告诉我们，只有 25% 的组织从其 CMDB 投资中获得了有意义的价值。
如上所述，传统的CMDB弃之可惜，食之无味。 看它不爽，但也干不掉他。作为CMDB管理和维护方的技术部，需要进行破局。CMDB作为技术运营部的基建本是非常重要的一部分，但管理层很少关注。总结下来有三点

• “基建”，本就是如水电时刻在用，也就无人关注
• “资产”，在ITIL中更多的是面向资产管理，作用局限
• “不准”，如果你在公司内部负责CMDB的建设，我相信一定在为CMDB的数据准确性犯愁，亦或为模型CI为难

换个思路，围绕应用系统开展工作

如题，应用系统贴近业务，业务服务公司战略，为公司挣钱。思路上正确。
但，
如何开展？
既然围绕业务系统开展，那么看看业务系统的生命周期和CMDB的关系

理清组织内部信息系统的建设生命周期

CMDB需要和信息系统整个生命周期挂钩，或者也可以反过来说信息系统整个生命周期需要依赖CMDB

理清各个节点CMDB的角色

对于CMDB来说，任何一个模型的任何一个CI项，均需要有意义。从供需角度分别来说

• 供方：CMDB提供信息，供上游平台消费使用
• 受方：使用CMDB的数据，并负责录入、更新模型的所有CI

信息录入和消费使用

CMDB为整个技术部门乃至业务的信息底座。
从上至下看，它是统一数据的来源；
从下至上看，它是上层建筑的底座。

信息录入

4种标准方式，分别为

• 人工维护：最为原始，简单。适用于公司规模小，资产未规模化的公司。数据录入时间不固定，数据一致性差
• 自动发现：自动化，高效。数据录入在事后，数据一致性好
• 生命周期管理流程：流程触发，维护对象全生命周期的状态。数据录入在事前，数据一致性好
• 自动化场景维护：一是依赖CMDB中的数据提高devops的效率，例如完成评审后，自动创建git仓库、ci流水线、制品仓库、容器平台NS、配置中心NS等等并赋予相应人员权限；二是各类实时运营场景，消费CMDB中的数据提运维运营的效率，例如可观测性需要全面贯通CMDB中的各类数据，自动化获取。

消费使用

针对数据的使用，不管是CMDB还是UCM，关键词有两个，一是统一要求数据的全局性，二是中心强调数据的权威性。