复用的层级
可复用的自动化通常分三层：最下层是原子能力，比如装包、渲染配置、管理服务，只做一件事且参数清晰；中间层是组件角色，把多个原子能力组合成「部署并配置某组件」的完整做法；最上层是编排剧本，决定在哪些主机上按什么顺序调用哪些角色。复用不等于把所有东西塞进一个大角色，而是让每层只承担一种变化：环境差异在变量层变化，做法本身保持稳定。
基本信息
| 原子层 | 单一动作，参数少而明确 |
|---|---|
| 组件层 | 组合动作，表达一套完整做法 |
| 编排层 | 决定范围、顺序与批次 |
| 变化归属 | 环境差异进变量，做法进角色，流程进剧本 |
判断抽象层级是否合适
- 新增一个环境时，需要改的是变量文件还是角色本体：改角色说明抽象漏了。
- 同类角色是否出现大量雷同文件：雷同说明该提取公共部分。
- 角色是否能独立测试：依赖某个具体环境才能跑的角色难以复用。
- 变量名是否表达含义而非位置：以主机名或 IP 命名的变量会阻碍复用。
- 是否有人能读懂：抽象过度的角色会把简单变更藏进五层调用里。
抽象层级与变化点
| 层级 | 负责的变化 | 不该承担 |
|---|---|---|
| 原子能力 | 工具与命令的差异 | 环境具体的地址与口令 |
| 组件角色 | 组件的标准做法与默认值 | 某个环境的特例配置 |
| 编排剧本 | 执行范围、顺序、批次 | 组件内部实现细节 |
| 变量层 | 环境差异与版本选择 | 流程控制逻辑 |
| 公共库 | 跨团队共享的常用能力 | 尚未稳定的试验性做法 |
抽象层级要与团队协作方式匹配：只有两个人用的角色可以做得很薄，跨团队共享的公共库才需要严谨的参数契约与版本发布节奏。过早追求通用会拖慢所有变更。
公共资产要有版本与变更说明：使用者依赖的是某个版本的行为，直接修改共享角色会让所有引用方同时受影响。