3. SLI 口径设计原则：有效 SLI 的四个黄金信号与口径定义三要素
在基础设施即代码（IaC）的可靠性评审中，SLI（Service Level Indicator）的口径定义直接决定了评审结论的客观性与可操作性。一个无效的 SLI 可能掩盖真实故障，而一个过度复杂的 SLI 则难以在 IaC 流水线中持续采集。本章围绕两大核心原则展开：四个黄金信号（Latency、Traffic、Errors、Saturation）与口径定义三要素（测量对象、测量方法、聚合窗口）。
3.1 四个黄金信号：从 Google SRE 到 IaC 的映射
Google SRE 团队提出的四个黄金信号，为基础设施监控提供了通用框架。在 IaC 场景下，每个信号都需要转化为可被代码化采集的指标。
| 黄金信号 | 核心关注点 | IaC 典型测量对象 | 常见误用 |
|---|---|---|---|
| 延迟 (Latency) | 请求处理耗时，区分成功与失败请求 | API 网关响应时间、数据库查询耗时、Terraform apply 执行时长 | 仅统计成功请求的延迟，忽略错误请求的快速失败 |
| 流量 (Traffic) | 系统承载的请求量或数据量 | 每秒请求数 (RPS)、每分钟 IaC 变更次数、网络吞吐量 | 使用平均值掩盖突发峰值 |
| 错误 (Errors) | 显式错误（HTTP 5xx）与隐式错误（业务逻辑失败） | HTTP 状态码分布、Terraform plan 失败率、证书过期比例 | 仅监控显式错误，忽略业务层面的错误响应 |
| 饱和度 (Saturation) | 资源使用程度，通常以利用率百分比表示 | CPU 使用率、内存占用、磁盘 IOPS 上限、Pods 数量配额 | 仅关注平均利用率，忽略 99 百分位的高负载节点 |
评审提示： 在可靠性评审报告中，每个黄金信号至少应包含一个 SLI。如果某个信号完全缺失（例如未定义饱和度 SLI），评审结论应标记为“高风险”，因为资源耗尽往往是级联故障的前兆。
3.2 口径定义三要素：让 SLI 可测量、可复现、可审计
一个完整的 SLI 口径必须包含三个要素，缺一不可。缺少任何一个要素，都会导致不同团队对同一 SLI 产生歧义。
- 测量对象 (Measurement Object)：明确“测量什么”。例如：
http_requests_total指标中 status 为 5xx 的请求。 - 测量方法 (Measurement Method)：明确“怎么测量”。例如：Prometheus 拉取间隔 15s，使用
rate()函数计算每秒错误数。 - 聚合窗口 (Aggregation Window)：明确“在什么时间范围内聚合”。例如：5 分钟滑动窗口，或 1 小时固定窗口。
口径定义示例（错误率 SLI）：
- 测量对象：所有到达 API 网关的 HTTP 请求，按 status 分类。
- 测量方法：Prometheus
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])。 - 聚合窗口：5 分钟滑动窗口，每 1 分钟计算一次。
3.3 四个黄金信号与三要素的融合：SLI 设计矩阵
将四个黄金信号与口径三要素结合，可以形成 SLI 设计的结构化矩阵。以下是一个针对 IaC 控制平面的完整 SLI 设计案例。
3.4 常见口径设计陷阱与避坑指南
在可靠性评审中，以下三个口径设计错误最为常见，需要特别关注。
陷阱 1：聚合窗口过短导致信号噪声
例如：使用 10 秒聚合窗口计算错误率。在低流量系统中，10 秒内可能只有 1 个请求，一旦该请求失败，错误率瞬间变为 100%。
建议：聚合窗口至少应包含 100 个以上的样本点。对于低频系统，使用 5 分钟或更长的窗口。
例如：使用 10 秒聚合窗口计算错误率。在低流量系统中，10 秒内可能只有 1 个请求，一旦该请求失败，错误率瞬间变为 100%。
建议：聚合窗口至少应包含 100 个以上的样本点。对于低频系统，使用 5 分钟或更长的窗口。
陷阱 2：测量对象遗漏隐式错误
例如：仅监控 HTTP 5xx 状态码，但业务逻辑返回 200 OK 且 body 中包含
建议：在测量对象中明确包含业务错误码，或使用自定义指标标记业务失败。
例如：仅监控 HTTP 5xx 状态码，但业务逻辑返回 200 OK 且 body 中包含
{"error": "insufficient_quota"}。这种隐式错误不会被 SLI 捕获。建议：在测量对象中明确包含业务错误码，或使用自定义指标标记业务失败。
陷阱 3：测量方法未对齐采集精度
例如：使用 Prometheus
建议：在测量方法中明确说明是否处理了 counter 重置，或使用
例如：使用 Prometheus
rate() 函数时，未考虑 counter 重置（如进程重启）。建议：在测量方法中明确说明是否处理了 counter 重置，或使用
increase() 配合足够长的窗口。
3.5 可靠性评审中的 SLI 口径检查清单
在评审报告中，建议使用以下清单逐项检查每个 SLI 的口令完整性。
| 检查项 | 通过标准 | 评审结论 |
|---|---|---|
| 黄金信号覆盖 | 延迟、流量、错误、饱和度至少各 1 个 SLI | ✅ / ❌ |
| 测量对象明确 | 指标名称、标签过滤条件、排除条件均已定义 | ✅ / ❌ |
| 测量方法可复现 | PromQL / SQL / 脚本命令可直接执行，结果唯一 | ✅ / ❌ |
| 聚合窗口合理 | 窗口长度 ≥ 100 个样本点，且与 SLO 周期对齐 | ✅ / ❌ |
| 隐式错误覆盖 | 业务错误码或自定义失败指标已纳入测量对象 | ✅ / ❌ |
评审报告撰写建议： 对于每个 SLI，在报告中以“三要素”格式列出其口径定义。例如：
SLI: API 错误率
测量对象: http_requests_total{status=~"5.."}
测量方法: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])
聚合窗口: 5 分钟滑动窗口, 每 1 分钟计算一次
数据来源: Prometheus (prod-cluster)