SLI

概述 凌晨三点，你被告警吵醒。爬起来一看：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 设计的起点是业务目标，而不是技术指标。业务目标回答的问题是：这个服务对业务的价值是什么？...