配置管理流程要点
配置管理包含四个动作：识别配置项、控制其变更、记录状态并审计完整性。软件项目常与版本控制、构建流水线结合，硬件项目与图纸版本管理结合。配置管理保证版本一致，变更控制保证决策留痕，两者配合才能回答「现在生效的是哪个版本」与「这个版本是谁批准的」。
基本信息
| 四个动作 | 识别、控制、状态记录、配置审计 |
|---|---|
| 配置项示例 | 需求文档、设计文件、源代码、模型、图纸、环境参数 |
| 关联系统 | 版本控制、构建流水线、制品库、变更管理 |
| 状态记录 | 当前版本、责任人、生效时间、变更来源 |
| 审计要求 | 定期核对实物与记录一致性 |
典型使用场景
- 项目启动：列出配置项清单并明确唯一标识与责任人
- 变更执行后：更新配置项版本并记录生效时间与批准依据
- 发布管理：核对发布制品与批准版本一致，避免带错版本上线
- 配置审计：抽样比对记录与实物，检查变更是否留痕
- 多环境管理：对比各环境关键参数，防止测试通过生产失败
配置管理动作
配置管理动作
识别：列出配置项清单（文档、代码、模型、图纸、环境参数）
控制：变更须经评估与批准后方可入库或发布
状态记录：当前版本、责任人、生效时间、关联变更单
审计：定期核对实物与记录一致性，抽查变更留痕
多环境：维护各环境参数差异清单，纳入配置管理
示例：禁止直接修改生产配置，必须走变更与版本记录配置审计
| 检查 | 做法 | 发现问题的表现 |
|---|---|---|
| 版本一致 | 抽样比对记录与实物 | 实际运行版本与记录不符 |
| 变更留痕 | 抽查变更单与入库时间 | 存在无审批的版本变更 |
| 环境一致 | 对比各环境关键参数 | 测试通过但生产异常 |
| 基线完整 | 核对基线是否包含全部配置项 | 遗漏第三方依赖或许可信息 |
配置项的粒度需要平衡：过细维护成本高，过粗则无法追溯；通常以「变更时需要独立控制」为界来划分。
允许直接在生产环境改配置而不记录，会在故障复盘时缺少关键线索，也无法判定影响范围。