Loop Engineering 系列完结篇：闭环成熟度模型
写了这么多闭环的文章，从原理到实操到案例，该收束了。这篇给闭环能力定个级——你团队的闭环在哪个阶段，下一步该往哪走，一目了然。
五级成熟度模型
L0：有监控，没闭环
特征： 有 Grafana 面板，有告警，但告警触发后全靠人处理。
典型场景： 值班收到告警 → SSH 上机器 → 查日志 → 手动操作 → 等恢复。
常见问题：
- 平均恢复时间 15-60 分钟
- 凌晨告警响应慢
- 不同人处理方式不同，质量参差
- 复盘文档写了一堆，下次还犯
怎么升级到 L1： 选一个最高频的故障场景，写一个自动化脚本处理它。不需要完美，能自动执行就行。
L1：单点自动响应
特征： 有一两个自动化的闭环，但各自独立，没有协调。
典型场景： 支付服务超时自动降级，库存 lag 高自动扩容。但两个闭环互不知道对方的存在。
常见问题：
- 闭环之间可能冲突（一个扩容一个降级）
- 阈值是写死的，不分时段不分业务
- 误触发率较高（10-20%）
- 新故障模式没有闭环覆盖
怎么升级到 L2： 给闭环加验证环节，加动态阈值，开始记录闭环自身的运行指标。
L2：多闭环协调
特征： 多个闭环运行，有基本的协调机制。闭环自身的健康度有监控。
典型场景： 资源预算防冲突，冷却期防循环触发，每周看闭环准确率报表。
常见问题：
- 规则覆盖不了的场景越来越多
- 规则维护成本高，改规则要发版
- 大促/异常场景的预案还是手动执行
怎么升级到 L3： 引入 Error Budget 做发布决策，开始做主动预案，考虑 LLM 辅助决策。
L3：预算驱动 + 主动预案
特征： Error Budget 接入发布流程，大促有自动预案，LLM 辅助处理规则覆盖不了的场景。
典型场景： 预算耗尽自动冻结发布，大促前自动扩容，模糊故障由 LLM 辅助判断。
常见问题：
- LLM 辅助决策的准确率不够高（70-80%），还不能完全信任
- 闭环配置分散在不同地方，非运维人员不敢改
- 团队对自动化的信任度在建立中，偶尔还会手动关掉闭环
怎么升级到 L4： 闭环配置化/自助化，LLM 决策链路完善，团队建立”闭环优先”的文化。
L4：自治闭环
特征： 闭环是默认运维手段，人工干预是例外。新故障模式能自动学习。非运维人员可以自助配置闭环。
典型场景： 大促全程零人工，新上线的服务自动接入闭环，故障复盘后的改进直接变成闭环规则。
这是理想状态。 大部分团队在 L2-L3 就够用了，不必追求 L4。
自测：你在哪一级
对每项回答”是”或”否”，数”是”的数量：
L0 → L1 的标志：
- 你有至少一个自动化的故障响应动作（不是手动执行的脚本）
- 那个动作从告警触发到执行不超过 1 分钟
- 动作执行后有自动验证（不是人看面板确认的）
L1 → L2 的标志：
4. 你有 3 个以上的自动化闭环在运行
5. 闭环之间有协调机制（资源预算、优先级、冷却期）
6. 闭环的阈值是动态的（不是写死的）
7. 你知道每个闭环的准确率（上周是多少能说出来）
L2 → L3 的标志：
8. Error Budget 接入了发布流程（预算耗尽会自动拦发布）
9. 大促/高峰有自动预案（不是值班手动操作）
10. 规则覆盖不了的故障有 LLM 或其他方式辅助判断
L3 → L4 的标志：
11. 新服务上线自动接入闭环，不需要运维手动配置
12. 非运维人员可以自助调整闭环参数
13. 故障复盘后的改进 80% 变成了闭环规则（而不是留在文档里）
14. 过去 3 个月没有因为”怕自动化出问题”手动关闭过闭环
得分解读：
- 0-2 个”是”：L0
- 3-5 个”是”：L1
- 6-8 个”是”：L2
- 9-11 个”是”：L3
- 12-14 个”是”：L4
每一级的关键投入
| 级别 | 关键投入 | 预期时间 | 团队规模 |
|---|---|---|---|
| L0→L1 | 第一个闭环的开发+调试 | 1-2 周 | 1 人 |
| L1→L2 | 协调机制+动态阈值+自身监控 | 1-2 月 | 2-3 人 |
| L2→L3 | Error Budget+预案+LLM集成 | 2-3 月 | 3-5 人 |
| L3→L4 | 配置化+自助化+文化建设 | 3-6 月 | 全团队 |
L0 到 L1 的 ROI 最高——花一周时间，故障恢复时间从 15 分钟降到 1 分钟。L3 到 L4 的 ROI 最低——投入大，但边际改善小。
大部分团队停在 L2 就很好了。L3 是加分项，L4 是锦上添花。
别跳级
见过不少团队想从 L0 直接跳到 L3——上来就要搞 Error Budget、搞 LLM 决策、搞自动预案。结果三件事都没做好，还不如先把一个闭环跑稳。
跳级的问题在于：高级闭环依赖低级闭环的基础设施。
- 没有 L1 的自动动作能力，L2 的协调机制协调什么？
- 没有 L2 的闭环自身监控，L3 的 LLM 决策你怎么知道好不好用？
- 没有 L3 的 Error Budget 实践，L4 的”闭环优先”文化没有数据支撑
一级一级走，每级跑稳了再升级。稳的标志是：连续 4 周闭环准确率 > 85%，且团队没有手动关闭过闭环。
系列回顾
这个 Loop Engineering 系列写了八篇，从原理到实操覆盖了闭环的主要方面：
- 落地手册 — 最小闭环的代码实现
- 反模式 — 五个典型翻车方式
- LLM 决策层 — 规则+AI 的混合架构
- 跨服务设计 — 三种协调模式
- 电商案例 — 从零闭环到五个闭环的演进
- Prometheus+Alertmanager — 工具链实操
- Error Budget — 预算驱动的发布控制
- 成熟度模型 — 这篇，自测和升级路径
闭环不是目的，是手段。目的是让系统更稳定、让运维更省心、让团队有精力做更有价值的事。如果你的闭环做到了这些，到哪个级别不重要。
系列文章：
- Loop Engineering 落地手册
- Loop Engineering 反模式
- 当 Loop 遇到 AI
- 跨服务闭环设计
- 电商实战案例
- Prometheus+Alertmanager 实操
- Error Budget 实战
相关阅读：
- Google SRE Book & SRE Workbook
-《反脆弱》- 塔勒布 - Netflix Chaos Engineering