成熟度看的是分工方式
自动化成熟度衡量的不是用了多少工具，而是人与机器在变更中的分工方式：谁发起、谁执行、出错后谁能恢复。惯例上把它分成四级——以手工操作为主、脚本辅助；脚本化但靠人记住流程；用配置管理与编排工具统一执行；业务侧可自助触发且平台负责收敛。级别之间没有硬边界，关键看能否用证据说明当前主要靠哪种方式完成变更。
基本信息
| 评估对象 | 一个运维团队、一个业务系统或一条交付链路 |
|---|---|
| 取证方式 | 最近 1 至 3 个月的变更工单、流水线记录、事故复盘 |
| 评估周期 | 每季度一次，或重大架构调整前后各一次 |
| 输出结论 | 当前级别、卡点、下一级的最小改造项 |
自评的五个维度
- 变更入口：同一类变更是否只有一个入口，还是命令行、控制台、脚本各来一遍。
- 可重复性：同一操作重复执行两次结果是否一致，失败后能否原样重跑。
- 资产受控：脚本、模板、配置是否有版本控制与评审，还是散落在个人目录。
- 可度量性：能否说清自动化覆盖了哪些变更、成功率多少、节省多少工时。
- 兜底能力：自动化失败时有无回滚、告警与人工接管的明确路径。
成熟度分级对照
| 级别 | 主要特征 | 典型风险 | 进入下一级的触发条件 |
|---|---|---|---|
| 手工为主 | 人记流程、人敲命令 | 误操作与知识集中在个人 | 同类变更每周重复三次以上 |
| 脚本化 | 有脚本但靠人调用 | 参数写错、跳步、无记录 | 脚本数量增长到无法清点 |
| 编排与配置管理 | 统一入口、状态可收敛 | 资产缺版本管理、变更不透明 | 多人协作改同一份资产 |
| 自助化与平台化 | 请求式交付、平台兜底 | 平台自身故障影响面大 | 平台需要独立的可靠性与容量治理 |
自评最容易犯的错是「按工具打分」：装了配置管理工具就自认三级，但实际变更仍从控制台上去改。评分时以最近真实发生过的变更为样本，抽十条工单看它究竟走了哪条路径。
级别不是越高越好：变更频率很低、生命周期很短的临时环境，停在脚本化就够了。把资源投在收益最大的那一段，比追求级别更有意义。