3. SLI 指标设计：如何为不同服务定义有效的 SLI 指标

SLI（Service Level Indicator）是 SLO 体系的基石。没有精确、可采集的 SLI，SLO 就是空中楼阁。本章聚焦于如何为不同服务类型定义有效的 SLI 指标，覆盖延迟、错误率、吞吐量、饱和度四个黄金信号，并提供从理论到落地的完整设计方法。

3.1 四大黄金信号与 SLI 映射

Google SRE 经典理论将服务监控指标归纳为四个黄金信号。每个信号对应一类典型的 SLI 定义方式：

3.2 延迟 SLI：从分布到阈值

延迟 SLI 的核心是“在给定时间窗口内，请求延迟低于目标阈值的比例”。定义时需明确三个参数：

• 采集窗口：通常为 1 分钟或 5 分钟滑动窗口，避免毛刺导致误告警。
• 聚合方式：推荐使用百分位数（p50/p95/p99），而非平均值。平均值会掩盖长尾延迟。
• 良好事件判定：延迟 ≤ 阈值（如 p99 ≤ 200ms）视为一次良好事件。

# 延迟 SLI 示例（PromQL 风格）
# 计算过去 5 分钟内，p99 延迟 ≤ 200ms 的请求占比
(
  sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
  /
  sum(rate(http_request_duration_seconds_count[5m]))
) * 100

3.3 错误率 SLI：区分显式与隐式错误

错误率 SLI 定义为“错误请求数 / 总请求数 × 100%”。但“错误”的定义需要精细设计：

# 错误率 SLI 示例（仅计算 5xx）
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

3.4 吞吐量 SLI：容量与负载的平衡

吞吐量 SLI 通常定义为“单位时间内成功处理的请求数”。它本身不直接反映服务质量，但结合延迟和错误率可以判断服务是否过载。

• 吞吐量：QPS / TPS，用于衡量系统处理能力。
• 相对吞吐量：当前吞吐量 / 历史峰值吞吐量，用于判断是否接近容量上限。
• 吞吐量异常：当吞吐量突然下降 50% 以上时，通常意味着服务故障或上游限流。

3.5 饱和度 SLI：资源瓶颈的早期预警

饱和度 SLI 关注资源使用量占总容量的比例。它是四个信号中唯一一个“预测性”指标，能在故障发生前发出预警。

# 饱和度 SLI 示例（CPU 利用率）
avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))
# 转换为利用率：1 - 上述值

3.6 SLI 设计流程：从服务类型到指标定义

不同服务类型需要不同的 SLI 设计策略。以下是一个通用的四步设计流程：

1. 识别用户旅程：确定服务对外提供的核心功能（如“用户登录”、“商品搜索”）。
2. 选择黄金信号：根据服务类型选择 1-2 个最相关的信号（如 API 选延迟+错误率，缓存选延迟+饱和度）。
3. 定义良好事件：明确“什么算一次好的请求”（如 p99 延迟 ≤ 200ms 且状态码 200）。
4. 设定采集与聚合：确定指标来源（APM、Exporter、业务埋点）、窗口大小、百分位选择。

3.7 不同服务类型的 SLI 设计模板

以下模板可直接用于常见服务类型的 SLI 定义：

3.8 SLI 与 SLO 的衔接：从指标到目标

定义好 SLI 后，下一步是设定 SLO 目标值。SLI 是“测量值”，SLO 是“目标值”。例如：

• SLI：过去 5 分钟内，p99 延迟 ≤ 200ms 的请求占比。
• SLO：该占比 ≥ 99.9%（即每月允许的坏事件窗口约 43 分钟）。

SLI 的采集窗口和聚合方式直接影响 SLO 的达成判断。建议在定义 SLI 时就明确：

• 窗口大小：推荐 5 分钟滑动窗口，平衡灵敏度与稳定性。
• 百分位选择：核心服务用 p99，非核心服务可用 p95。
• 排除策略：是否排除计划内维护、客户端错误等。