SLI

概述 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 该干什么"没有共识 团队里有人想推进自动化，有人觉得"手动操作挺好的为什么要改”，你作为负责人没法用数据说服 这些问题的共同根因是：没有一把可量量的尺子来衡量团队能力。...

概述 凌晨三点，你被告警吵醒。爬起来一看：CPU 正常、内存正常、Pod 也在跑，但用户投诉说"系统卡得用不了"。你打开 Grafana 面板，画了一堆曲线，却说不清楚——这到底算不算故障？ 这个场景，我在多个企业客户的 SRE 咨询中反复遇到。核心问题不是监控不够多，而是度量体系设计错了方向：我们一直在监控"系统内部的指标"，而不是"用户感受到的服务质量"。 曾经在一次某出行平台的故障复盘中，团队发现一个讽刺的事实：告警系统在故障发生 12 分钟后才触发，而用户在故障发生后 30 秒就已经开始投诉了。原因很简单——告警基于 CPU 使用率超 80% 触发，但实际故障是数据库连接池耗尽，CPU 才 35%，根本没碰阈值。 可靠性度量的本质，是把"系统稳不稳"这个问题，从主观感觉变成可量化的数字。这篇文章不讲 SLI/SLO 的基础概念（这些在 相关文章：SRE核心理念：SLI、SLO与错误预算 中已经讲透了），而是聚焦于：如何从零设计一套完整、可落地、能驱动决策的可靠性度量体系。 为什么传统监控体系不能回答"系统稳不稳" 先说结论：传统监控体系回答不了"系统稳不稳"，因为它度量的对象错了。 传统监控的三个盲区 盲区一：监控的是资源，不是用户体验 大多数团队的监控面板长这样：CPU 折线图、内存折线图、磁盘 IO 折线图、网络流量折线图。这些指标反映的是"服务器忙不忙"，而不是"用户爽不爽"。 举个真实的例子：某电商平台的订单服务，CPU 使用率常年 70%，运维觉得"不太对劲"，计划扩容。但实际上 P99 延迟 120ms，请求成功率 99.97%，用户体验完全没问题。另一个缓存服务，CPU 才 20%，看起来"很健康"，但缓存命中率从 95% 掉到 60%，导致数据库被打爆，用户实际体验已经很差了。 盲区二：没有"好"和"坏"的量化边界 “CPU 80% 算好还是算坏？"——这个问题在传统监控体系里没有答案。80% 可能是正常的批处理负载，也可能是即将打满的前兆。没有 SLO 的情况下，80% 就只是一个数字，不是判断依据。 Google SRE Book 里有一段话说得很到位：“如果你不能度量它，你就不能管理它。” 但更准确的说法应该是：如果你度量错了对象，比不度量更危险——因为你会基于错误的信号做决策。 盲区三：告警基于静态阈值，不感知业务影响 传统告警的逻辑是"指标超过阈值就报”。问题是，同样的阈值在不同业务场景下含义完全不同： 场景 CPU 80% 含义 是否需要告警 凌晨 2 点批处理任务 正常负载 不需要 大促期间核心交易服务 即将打满 紧急告警 测试环境压测中 预期行为 不需要 生产环境空闲时段 异常进程 需要排查 静态阈值无法区分这些场景，导致的结果就是：要么告警太多（告警疲劳），要么告警太晚（用户已经投诉了才报）。...

概述 很多团队在实践 SRE 时遇到的第一个困境是：知道 SLO 是什么，但不知道怎么设。要么照搬 Google 的 99.99%，要么随便拍一个 99.9%——然后发现这个数字既不反映用户体验，也无法驱动工程决策。 好的 SLO 不是拍脑袋拍出来的，而是从业务目标出发，经过用户旅程分析、指标选择、数值校准、多层级设计、定期评审等一系列工程方法推导出来的。详细梳理 SLO 设计的完整方法论，帮助你建立从"业务目标"到"技术指标"的完整映射链路。 本文假设读者已了解 SLI/SLO 的基本概念。如需补充，可参考 Google SRE Workbook - Service Level Objectives 和本站 SRE核心理念：SLI、SLO与错误预算。 一、SLO 设计金字塔 SLO 设计不是孤立的技术活动，而是从上到下的分层推导过程： ┌─────────────┐ │ 业务目标 │ "我们的服务需要做到什么程度？" └──────┬──────┘ │ ┌──────▼──────┐ │ 用户体验 │ "用户关心什么？" └──────┬──────┘ │ ┌──────▼──────┐ │ SLI 定义 │ "我们怎么衡量用户体验？" └──────┬──────┘ │ ┌──────▼──────┐ │ SLO 目标值 │ "这个指标要做到多少？" └──────┬──────┘ │ ┌──────▼──────┐ │ 告警与行动 │ "不达标时怎么办？" └─────────────┘ 第一层：业务目标 一切 SLO 设计的起点是业务目标，而不是技术指标。业务目标回答的问题是：这个服务对业务的价值是什么？...