配置管理与基础设施即代码边界是什么
配置管理与基础设施即代码是两种互补的自动化：前者把已有资源的状态收敛到期望值（装包、写配置、管服务），后者把资源本身声明式地创建与销毁（网络、计算、存储、集群对象）。划分边界的常用标准是生命周期与可重建性：能声明式创建、销毁代价低、且要求跨环境一致的资源交给后者；而需要就地演化、无法随意重建或有状态的部分交给配置管理。划不好就会演变成两套工具争夺同一资源。
基本信息
| 分工依据 | 生命周期长短、可否重建、是否要求跨环境一致 |
|---|---|
| 基础设施即代码负责 | 资源声明与创建销毁、网络与计算、集群对象 |
| 配置管理负责 | 已有资源内部状态、软件与配置、服务管理 |
| 共享约定 | 单一来源、资源打标、属性归属明确 |
| 主要风险 | 两套工具覆盖同一属性，互相改回 |
典型使用场景
- 云主机与网络由声明式描述创建，账号与软件由配置管理收敛
- 集群节点扩缩由声明式描述控制，节点内配置由配置管理处理
- 数据库等有状态服务采用受控流程，避免随意销毁重建
- 环境级参数差异用同一份声明的变量表达
- 用打标与命名规范让两套工具都能识别资源归属
归属划分经验规则
归属划分经验规则
# 可随时重建、需跨环境一致 → 交给基础设施即代码
# 就地演化、有状态、不便重建 → 交给配置管理
# 同一属性只能有一个拥有者，避免两边都写造成反复回滚
# 资源打标包含：环境、归属工具、所属应用、负责人
# 变更前先判断目标属性归谁管理，跨边界修改需显式协调决定因素与倾向
| 决定因素 | 倾向基础设施即代码 | 倾向配置管理 |
|---|---|---|
| 生命周期 | 短、频繁重建 | 长、就地演化 |
| 可重建性 | 销毁代价低 | 重建成本高或数据不可丢 |
| 一致性要求 | 要求跨环境严格一致 | 允许按实例微调 |
| 状态性 | 无状态 | 有状态 |
边界改动比初始划分更容易出事故：把某类资源从配置管理迁到声明式管理时，要先让原工具停止管理该属性并清理其状态记录，否则两边会交替把配置改回去，表现为难以解释的反复漂移。
不要把有状态服务的存储与数据交给「随时可销毁再重建」的流程。声明式重建的默认假设是无状态，一旦作用于数据卷，代价往往不可逆。