1. SLO 与 SLI 基础：定义服务等级目标与服务等级指标

聊服务等级监控，绕不开两个最基础的概念：SLI 和 SLO。很多团队一上来就拍脑袋定目标，结果监控数据一堆，却不知道到底该看哪个。说白了，SLI 是你「测量什么」，SLO 是你「承诺什么」。这两者搞不清楚，后面的优化全是空中楼阁。

我个人习惯，每次接手一个新服务，第一件事不是搭监控，而是先问三个问题：

• 用户真正关心的是什么？
• 我们用什么指标来衡量？
• 做到什么程度才算「好」？

这三个问题，正好对应 SLI 的定义、SLI 的选择、SLO 的设定。咱们一个一个拆开看。

1.1 什么是 SLI？

SLI（Service Level Indicator），服务等级指标。它是你用来衡量服务质量的一个具体数值。比如请求延迟的 P99、错误率、吞吐量，这些都是 SLI。

嗯，这里要注意：SLI 必须是可测量的。你不能说「用户体验好」，你得说「首页加载时间小于 200ms 的比例」。我在项目中遇到过团队把「系统稳定性」当 SLI，结果吵了半天也没法量化——这其实是个坑。

常见的 SLI 类型，我整理了一张表：

类别	典型 SLI	说明
可用性	请求成功率	成功响应数 / 总请求数
延迟	P50 / P95 / P99 延迟	不同百分位的响应时间
吞吐量	QPS / RPS	每秒处理的请求数
错误率	5xx 占比	服务端错误占总请求比例
饱和度	CPU / 内存使用率	资源接近极限的程度

1.2 什么是 SLO？

SLO（Service Level Objective），服务等级目标。它是你给 SLI 设定一个目标阈值。比如「P99 延迟小于 200ms，达成率 99.9%」，这就是一个 SLO。

你想想看，SLI 只是告诉你「现在延迟是 150ms」，但 150ms 算好还是不好？没有 SLO 你就没法判断。SLO 就是那把尺子。

SLO 的典型表达方式：

• 「过去 30 天内，99.9% 的请求延迟小于 200ms」
• 「过去 7 天内，可用性不低于 99.99%」
• 「每月错误率不超过 0.1%」

1.3 SLI 与 SLO 的核心区别与联系

很多人把这两个概念混着用，其实它们的关系很简单：

我画了一张图，帮你理清它们的关系：

1.4 如何选择好的 SLI？

选 SLI 有个原则：从用户视角出发。别盯着内部指标不放，用户不关心你的 CPU 使用率，他们只关心页面能不能打开、打开快不快。

我建议用「四个黄金信号」来筛选：

1. 延迟：请求处理需要多久？
2. 流量：系统承载的请求量有多大？
3. 错误：请求失败的比例是多少？
4. 饱和度：系统资源还有多少余量？

1.5 如何设定合理的 SLO？

SLO 的设定，说白了就是一场「理想」和「现实」的博弈。定太高，运维成本爆炸；定太低，用户满意度下降。

我一般按这个步骤来：

• 第一步：看历史数据。过去三个月你的服务实际表现如何？取一个合理的基线。
• 第二步：对齐业务需求。跟产品、业务方聊，他们能接受的最低标准是什么？
• 第三步：留出误差空间。别把 SLO 定在 SLI 的极限值上，留 0.1%-0.5% 的余量。
• 第四步：分等级设定。核心接口用 99.99%，非核心接口用 99.9%，别一刀切。

1.6 一个完整的例子

假设你负责一个电商平台的「商品详情页」服务。咱们来实操一下：

维度	SLI	SLO
可用性	HTTP 200 响应占比	过去 30 天 ≥ 99.95%
延迟	P95 响应时间	过去 7 天 ≤ 300ms
错误率	5xx 错误占比	过去 7 天 ≤ 0.1%
吞吐量	峰值 QPS	≥ 5000 QPS 且不触发限流

你看，每个 SLI 都有明确的测量方式，每个 SLO 都有具体的时间窗口和阈值。这样监控系统才能自动判断「服务是否达标」。

嗯，最后说一句：SLI 和 SLO 不是写一次就完事的。随着业务变化、系统演进，它们需要定期 review。我每季度都会跟团队过一遍，看看哪些指标已经过时了，哪些目标需要调整。这才是 SRE 的常态。