为什么需要分层
运维自动化很少一步到位，它通常由若干关注点不同的层次叠加而成：最底层是把手工命令固化成脚本，往上是把脚本编排成可重复执行的任务，再往上是把任务要达成的结果声明成配置，最终才是把配置与发布串成流水线。分层的目的不是画架构图，而是让每一层只解决一类问题——出故障时能立刻判断是「动作写错了」还是「期望状态设计错了」，而不是从头翻一遍所有脚本。
基本信息
| 适用对象 | 自有 IDC、云主机、容器平台混合的运维环境 |
|---|---|
| 分层依据 | 按意图抽象程度划分，而非按工具品牌 |
| 典型载体 | 脚本库、配置管理工具、镜像与装机模板、流水线 |
| 推进顺序 | 自下而上：先固化动作，再编排任务，最后声明状态 |
典型分层
- 脚本层：把临时命令固化成带参数、带日志、带返回码的脚本，先消灭纯手工重复劳动。
- 任务编排层：把多个动作按顺序与条件串起来，加上批次、超时、失败处理与执行记录。
- 配置声明层：用声明式工具描述主机应处于什么状态，由工具负责比对差异并收敛。
- 环境交付层：把操作系统与中间件安装整体模板化，做到新节点可复制交付而不是手工装机。
- 流程集成层：把审批、执行、验证接入工单与流水线，让每次变更都可追溯、可回放。
- 度量反馈层：统计覆盖率、失败率与节省工时，用数据决定下一层该补什么。
各层职责对照
| 层级 | 解决的问题 | 典型产物 | 常见失效表现 |
|---|---|---|---|
| 脚本层 | 重复劳动 | 带参数与日志的脚本 | 参数写死、无人维护 |
| 编排层 | 执行顺序与批次 | 编排定义与执行记录 | 中断后无法续跑 |
| 声明层 | 状态一致性 | 状态描述文件与模块任务 | 手工改动被静默覆盖 |
| 交付层 | 节点可复制 | 镜像模板、装机模板 | 新节点与老节点不一致 |
| 流程层 | 变更可追溯 | 工单与流水线记录 | 绕过流程的暗箱变更 |
| 度量层 | 收益可判断 | 覆盖率与失败率报表 | 自动化被当成黑盒 |
分层不等于必须换工具：脚本加一个配置管理工具通常就能覆盖前三层。判断是否要进入下一层的标准是上一层是否已经反复出现手工补救，而不是行业里流行什么工具。
同一层内的工具尽量收敛到一种。同一批服务器上并行存在三套脚本规范时，维护成本会超过自动化本身节省的成本，这也是很多团队自动化做到一半就停住的主要原因。