自动化成熟度评估：从手工到自主

摘要：自动化不是「做了多少工具」，而是「出问题时机器能替你做到哪一步」。本文给出五级成熟度模型与一份可打分的自评表，帮你定位现状并找到最该补的能力。

适用环境

任意规模的技术团队
已有部分自动化实践（哪怕只是几个脚本）
参与评估的人覆盖开发、运维、测试视角

操作步骤

1. 五级成熟度模型

text

L1 手工      ：所有操作靠人敲命令，靠文档和记忆
L2 脚本化    ：常用操作写成脚本，但仍需人登录执行
L3 受控自动化：有配置管理 / IaC，变更经评审与流水线，可回滚
L4 自动化编排：部署、扩容、巡检自动触发，人工只做审批与例外
L5 自主      ：系统可自愈、可预测容量、自动优化，人只定策略

多数团队在 L2-L3 之间。不要跳级：L3 的评审与回滚没做好，直接上 L4 会让故障扩散更快。

2. 十维自评打分表

每个维度打 0-4 分（0=完全没有，4=成熟且持续优化）：

bash

cat > ~/automation/maturity.md <<'EOF'
## 自动化成熟度自评（0-4 分）
| 维度 | 典型证据 | 分数 |
|---|---|---|
| 脚本化 | 高频操作有脚本，脚本纳入版本管理 | |
| 配置管理 | 配置由 Ansible/同类工具统一，有基线 | |
| IaC | 云资源由 Terraform/OpenTofu 管理，state 远程化 | |
| CI/CD | 提交即触发构建测试，部署走流水线 | |
| 测试 | 基础设施代码有 lint 与自动化测试 | |
| 幂等回滚 | 变更可重复执行，有已验证的回滚手段 | |
| 密钥管理 | 密钥不进 Git，有轮换与审计机制 | |
| 审批门禁 | 生产变更需评审，有变更窗口与紧急通道 | |
| 可观测 | 有指标/日志/告警，自动化动作本身可观测 | |
| 自愈 | 明确故障自动恢复，带限流熔断 | |
EOF

text

总分 / 40：
  < 12  → L1-L2，先补脚本化与版本管理
  12-24 → L2-L3，重点补 IaC、CI/CD 与回滚
  24-32 → L3-L4，重点补测试、审批门禁与可观测
  > 32  → L4-L5，重点做自愈与预测性优化

3. 找最该补的一块

原则：补「最低分且被高频依赖」的维度，而不是追最时髦的工具。示例：脚本化 4 分但密钥管理 0 分 → 立刻补密钥管理；CI/CD 4 分但幂等回滚 1 分 → 立刻补回滚（自动化越快越危险）。

4. 四个衡量指标

变更前置时间、变更失败率、平均恢复时间（MTTR）、人工操作占比（需人手敲命令的操作次数 / 总操作次数）。

bash

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://gitlab.example/api/v4/projects/$PROJECT_ID/pipelines?per_page=100" \
  | python3 -c "import sys,json,collections; d=json.load(sys.stdin); print(collections.Counter(p['status'] for p in d))"

5. 90 天改进计划

第 1 个 30 天补最低分的风险项（密钥、回滚、备份演练）；第 2 个 30 天把最高频手工操作脚本化并纳入 Git；第 3 个 30 天把脚本接入流水线并加 lint 与审批门禁；每 90 天重打一次分。

分数高不等于风险低

工具装得多但没人维护，比没有工具更危险——大家会误以为有保护。每个自动化资产都要有负责人和最近验证时间。

验证

[ ] 十个维度都打了分，且每个分数有对应证据
[ ] 能说出当前处于 L 几，以及最优先要补的一项
[ ] 改进计划写成了具体的、可验收的动作
[ ] 已确定下次复评时间（建议 90 天后）

常见坑

照搬大厂成熟度模型

大厂的 L5 建立在多年 L3 基础上。中小团队应先做到脚本化 + 可回滚 + 有审批。

只看工具覆盖率，不看使用率

「我们有 Ansible」但 80% 变更仍靠手工，实际成熟度仍是 L1。要看真正走自动化的操作比例。

为了分数而自动化

把不成熟的流程自动化会放大故障。先标准化流程、保留人工确认，跑稳了再逐步去掉人工环节。

自动化成熟度评估：从手工到自主 ​

适用环境 ​

操作步骤 ​

1. 五级成熟度模型 ​

2. 十维自评打分表 ​

3. 找最该补的一块 ​

4. 四个衡量指标 ​

5. 90 天改进计划 ​

验证 ​

常见坑 ​

参考资料 ​