Toil

概述 2021 年我刚接手一个运维团队时，做了个简单统计：团队 12 个人，一周 40 小时工作时间里，平均 24 小时花在手动处理工单、重启服务、补磁盘空间这些事情上。琐事占比 60%。剩下 16 小时里，一半在开会同步信息，真正做工程优化的时间每周不到 8 小时。 团队里每个人都很忙，但系统还是不稳定。MTTR 40 分钟，可用性 99.5%，告警群每天 200 多条。老板问我：“我们团队到底行不行？“我答不上来。不是谦虚，是没有量化标准。 后来我花了 3 年时间，把可用性从 99.5% 推到 99.9%，MTTR 从 40 分钟压到 8 分钟，琐事占比从 60% 降到 20% 以内。回头复盘，最关键的一步不是引入了什么工具，而是建立了一套成熟度评估体系——先搞清楚团队在哪个段位，再决定下一步投什么。 这篇文章分享我实际用过的 SRE 团队成熟度 5 级模型。它借鉴了 CMMI 的分层思路，但完全针对 SRE 场景重新设计，每个级别都有可量化的判断标准。文末有一份 Python 自检脚本，你跑一下就知道自己的团队在哪一级。 为什么需要 SRE 成熟度模型 先说几个常见场景，看看你中了几条： 招人时 JD 写"精通 K8s 和 Prometheus”，面了一圈发现候选人技术栈差不多，但来了之后产出天差地别——因为你不知道团队缺的是"会写 PromQL 的人"还是"能设计 SLO 体系的人” 申报预算时跟老板说"我们需要买 Datadog 和搭建混沌工程平台"，老板问"现在是什么水平？投了能到什么水平？“你答不上来 跨团队协作时，开发觉得 SRE 只会卡上线，SRE 觉得开发只管发版不管稳定性——根源是双方对"SRE 该干什么"没有共识 团队里有人想推进自动化，有人觉得"手动操作挺好的为什么要改”，你作为负责人没法用数据说服 这些问题的共同根因是：没有一把可量量的尺子来衡量团队能力。...