1. 配置管理概述
1.1 配置管理的定义
配置管理（Configuration Management, CM）是一套通过标识、控制、记录和审计系统及其组件的功能特性和物理特性的工程化实践。在 DevOps 和 SRE 语境下，配置管理聚焦于基础设施即代码（IaC）与应用配置的声明式管理，确保环境状态可预测、可复现、可审计。
核心公式： 配置管理 = 版本化声明 + 自动化收敛 + 一致性校验
配置管理的管理对象涵盖：
- 基础设施配置： 服务器规格、网络拓扑、存储策略、负载均衡规则。
- 应用运行时配置： 环境变量、特性开关、数据库连接串、日志级别。
- 编排与调度配置： Kubernetes 资源清单（Deployment、ConfigMap、Secret）、Docker Compose 文件。
- 安全与合规配置： 访问控制策略、证书轮换规则、审计日志配置。
1.2 配置管理的核心目标
配置管理的五大核心目标构成了发布健康口径的底层支撑：
| 目标 | 说明 | 对发布健康的影响 |
|---|---|---|
| 一致性 | 消除环境漂移，确保开发、测试、预发、生产环境配置完全对齐 | 减少“在我机器上能跑”类故障，降低发布回滚率 |
| 可追溯性 | 每次配置变更都有版本记录、变更人、时间戳和审批链 | 快速定位配置引发的故障根因，缩短 MTTR |
| 自动化 | 配置变更通过 CI/CD 管道自动下发，拒绝手动登录服务器修改 | 消除人为操作失误，提升发布成功率 |
| 可复现性 | 从版本库中的配置声明即可重建任意历史环境状态 | 支持快速回滚和灾备恢复，保障发布韧性 |
| 安全性 | 敏感配置（密钥、）加密存储，最小权限原则下发 | 防止配置泄露导致的安全事故，维护发布合规性 |
SRE 视角： 配置管理的终极目标是让配置成为“可审计的代码”，而非“运维人员的记忆”。当配置变更成为发布故障的首要原因时，CM 的成熟度直接决定了发布健康度的基线。
1.3 配置管理在 DevOps/SRE 体系中的战略地位
配置管理不是孤立的工具链环节，而是贯穿 DevOps 和 SRE 所有实践的基础设施层。下图展示了 CM 在发布管道中的战略位置：
1.4 配置管理成熟度模型
不同组织的配置管理实践成熟度差异巨大，直接影响发布健康口径的可靠性。以下模型帮助团队自评：
| 成熟度等级 | 特征 | 发布健康影响 |
|---|---|---|
| L1：手动 | 运维人员 SSH 登录服务器修改配置，无版本控制 | 发布故障率 > 30%，MTTR 以小时计 |
| L2：脚本化 | 使用 Shell/Ansible 脚本批量修改，但脚本未纳入版本库 | 发布故障率 15-30%，环境漂移频繁 |
| L3：版本化 | 配置声明（YAML/JSON）存储在 Git 中，通过 CI/CD 下发 | 发布故障率 5-15%，支持回滚 |
| L4：声明式 | 使用 Terraform/Kubernetes 声明式 API，自动收敛至期望状态 | 发布故障率 < 5%，MTTR 分钟级 |
| L5：策略驱动 | 配置变更自动触发合规检查、金丝雀发布、健康度评估 | 发布故障率 < 1%，配置变更即发布健康口径的输入 |
常见误区： 很多团队认为“用了 Ansible 就是配置管理”，实际上如果 Playbook 没有版本控制、没有自动化测试、没有变更审批，仍然停留在 L2 水平。配置管理的核心是可审计的自动化，而非工具本身。
1.5 配置管理与发布健康口径的关联
发布健康口径（Deployment Health SLI/SLO）的三大核心指标——部署频率、变更失败率、恢复时间——均直接受配置管理质量影响：
- 部署频率： 声明式配置管理允许团队通过 PR 合并即可触发部署，消除手动配置环节，将部署频率从周级提升至日级甚至小时级。
- 变更失败率： 配置版本化 + 自动化校验确保每次变更都经过语法检查、合规扫描、预发验证，将配置引发的变更失败率从 20% 降至 2% 以下。
- 恢复时间（MTTR）： 可追溯的配置历史支持一键回滚到任意已知健康状态，将配置故障的 MTTR 从小时级压缩到分钟级。
以下示意图展示配置管理如何驱动发布健康口径的闭环：