配置管理基础：配置项(CI)、配置管理数据库(CMDB)与配置基线(Baseline)

聊配置管理，咱们得先把地基打牢。这三个概念——配置项、CMDB、配置基线——说白了就是整个配置管理体系的「三驾马车」。我见过不少团队，工具上了好几套，流程画得天花乱坠，结果一查，连CI是什么都没统一。嗯，这课咱们就从根上捋清楚。

一、配置项（CI）—— 到底什么算「配置」？

配置项，英文叫 Configuration Item，简称 CI。你可能会问：「服务器算不算CI？IP地址算不算？代码版本算不算？」

我的答案是：凡是需要被独立管理、跟踪、审计的IT资产，都可以是CI。但注意，不是所有东西都值得做成CI。我曾经见过一个团队，把每台服务器的每个网口都单独建了一个CI，结果CMDB里几万个条目，查个东西比翻字典还累。

我个人习惯，判断一个东西要不要做成CI，就看三点：

• 可标识：有没有唯一ID？比如主机名、序列号、UUID。
• 可变更：它会不会变？比如IP地址会变，机柜位置不会。
• 可审计：出了问题，能不能追溯到它？

举个例子，一台物理服务器，它的CI属性可能包括：

你想想看，如果这些信息散落在各个Excel表格里，每次排查故障都要问「这台机器是谁的？装的什么系统？」——那效率得多低？

二、配置管理数据库（CMDB）—— 配置项的「家」

CMDB，全称 Configuration Management Database。它不是普通的数据库，而是专门用来存放CI及其关系的数据库。

我经常跟团队说一句话：CMDB不是资产台账，它是关系图谱。资产台账只告诉你「有什么」，CMDB要告诉你「谁和谁有关系」。

举个例子，你发现应用A访问数据库B超时了。如果CMDB里记录了「应用A依赖数据库B，数据库B运行在服务器C上，服务器C的IP是10.0.1.100」，那你排查路径就清晰了：先看服务器C的网络，再看数据库B的负载，最后看应用A的配置。

这里我画了一张图，帮你理解CMDB的核心逻辑：

你看，有了CMDB，你就能从「应用」一路追踪到「物理服务器」。这就是为什么我总说，CMDB是运维的「大脑」。

三、配置基线（Baseline）—— 给配置拍张「快照」

配置基线，英文叫 Baseline。说白了，就是在某个时间点，给一组CI的配置状态拍一张「快照」。这张快照就是后续变更的参照物。

为什么会需要基线？你想想看，一个系统上线时跑得好好的，运维人员改了个参数，第二天就出问题了。这时候你问「谁改了什么？」——没人承认。但如果你有基线，一对比就知道：哦，原来连接池从50改成了200。

我个人习惯，基线一般用在三个场景：

1. 版本发布基线：每次上线前，把当前生产环境的配置全部记录下来。万一回滚，直接恢复基线。
2. 审计合规基线：比如等保要求，密码策略、日志级别必须符合规范。基线就是「合规标准」。
3. 灾难恢复基线：灾备切换后，配置必须和主站一致。基线就是「对账依据」。

举个例子，一个典型的发布基线可能包含：

基线ID: BL-2024-001
创建时间: 2024-03-15 10:00:00
关联CI:
  - 应用: 交易系统 v3.2 (CI-APP-001)
  - 数据库: MySQL 8.0 (CI-DB-002)
  - 服务器: prod-db-01 (CI-SRV-003)
配置快照:
  - 应用配置: max_connections=100, timeout=30s
  - 数据库配置: innodb_buffer_pool_size=8G
  - 系统配置: vm.swappiness=10
审批人: 王五
状态: 已锁定

四、三者关系：CI是砖，CMDB是墙，基线是设计图

最后，我帮你理一下这三个概念的关系：

• CI 是基础单元，就像一块块砖头。
• CMDB 是这些砖头砌成的墙，记录了每块砖的位置和连接关系。
• 基线 是设计图，告诉你「这面墙在某个时间点应该长什么样」。

没有CI，CMDB就是空的。没有CMDB，基线就不知道要拍谁的快照。没有基线，你改了配置都不知道改了什么。

嗯，这三个概念，你只要记住一句话：CI是管理对象，CMDB是管理关系，基线是管理状态。后面讲配置审计、变更管理，全都离不开它们。