配置版本化与审计是什么
配置版本化指把环境配置放进版本库管理：Kustomize、Helm values、纯 YAML 都可以作载体；变更走 MR 评审，发布等于「合并加同步」，回滚等于「revert 加同步」。配合 GitOps 控制器（Argo CD / Flux）时，仓库声明与集群状态有明确的同步关系与责任人，漂移可检测、可收敛。审计链条由两段拼起来：提交记录（谁为什么改）与部署记录（什么时候到集群）互相印证——这是它相对「登录服务器手改」的核心优势。配置仓库掌握生产行为，分支保护与权限等级要与代码仓库看齐。
基本信息
| 载体 | Kustomize、Helm values、纯 YAML 清单均可入库 |
|---|---|
| 流程 | 变更走 MR；发布 = 合并 + 同步；回滚 = revert + 同步 |
| 审计 | 提交记录即变更记录，与流水线部署记录互相对照 |
| 要求 | 配置仓库与代码仓库同等级的分支保护和评审 |
典型使用场景
- 多云环境配置：各集群配置集中在仓库，变更一处可见全局影响。
- 审计需求：合规审查时提供「配置何时被谁改、何时生效」的证据链。
- 回滚：revert 提交即回到旧配置，回滚对象和路径都明确。
- 漂移治理：控制器检测集群与声明不一致，告警或自动收敛。
- 多人协作：配置评审替代口头协商，避免口径不一致。
GitOps 循环
GitOps 循环
git commit → MR 评审 → 合并 main
→ 同步控制器（Argo CD/Flux）拉到集群
→ 漂移检测 → 告警或自动收敛
# 回滚: revert 提交 → 控制器同步回旧状态对照手改
| 维度 | 版本化配置 | 手工直改 |
|---|---|---|
| 可追溯 | 提交记录完整 | 依赖个人记忆 |
| 回滚 | revert 可预期 | 重新手改常出错 |
| 评审 | MR 留痕 | 口头沟通 |
| 漂移 | 可检测收敛 | 难以发现 |
配置仓库同样要保护分支与评审：它掌握生产行为，权限与代码库同级，不要因为「只是配置」而放低要求。
交接边界要写清：哪些配置在仓库、哪些仍由手工维护（如云控制台参数），边界模糊时漂移排查会失去方向。