2. SLI 口径定义五大原则详解
SLI（Service Level Indicator，服务等级指标）是可靠性工程的量化基石。一个定义不当的 SLI 会导致误判、告警风暴或盲区。业界公认的 SLI 口径定义需遵循五大原则：明确、可测量、面向用户、可区分好坏、可自动化采集。以下逐一展开工程解析。
2.1 原则一：明确（Unambiguous）
口径必须消除歧义，不同团队（SRE、开发、产品）对同一指标的理解应完全一致。模糊的口径是可靠性评审中最大的风险源。
| 反例（模糊） | 正例（明确） |
|---|---|
| “接口响应时间” | “从客户端发起 HTTP GET 请求到收到完整 200 响应体的 P50 耗时，单位 ms” |
| “系统可用性” | “每分钟内成功返回非 5xx 状态码的请求数 / 总请求数 ≥ 99.9%” |
| “数据库延迟” | “从应用侧发起 SQL 查询到收到第一条结果行的耗时，排除网络往返，单位 μs” |
工程要点：在 SLI 定义文档中强制包含“测量起点、终点、单位、聚合方式、采样窗口”五个要素，缺一不可。
2.2 原则二：可测量（Measurable）
SLI 必须能从现有系统或日志中直接或间接获取数值，不能依赖人工估算或主观判断。可测量性决定了 SLI 的落地成本与可信度。
- 直接可测：从 APM 工具、负载均衡器日志、数据库慢查询日志直接提取的指标。
- 间接可测：通过多个原始指标计算得出，例如“错误率 = 5xx 计数 / 总请求计数”。
- 不可接受：“用户体验良好”、“系统稳定”等无法量化的描述。
避坑提示：避免定义“每秒事务数（TPS）”作为核心 SLI，因为 TPS 受业务流量波动影响大，且难以区分好坏。优先选择“成功率”或“延迟分布”。
2.3 原则三：面向用户（User-Facing）
SLI 应反映用户真实感知的服务质量，而非内部组件健康度。用户不关心 CPU 使用率，只关心页面能否打开、下单是否成功。
常见误区：将“数据库连接池利用率”作为核心 SLI。即使连接池满，若应用有重试和降级机制，用户可能无感知。应优先定义“用户请求成功率”作为 SLI。
2.4 原则四：可区分好坏（Good/Bad Discernible）
SLI 必须能清晰划分“好”与“坏”的边界，否则无法触发告警或计算 SLO。区分标准应基于业务容忍度，而非技术理想值。
| SLI 示例 | 好（Good） | 坏（Bad） |
|---|---|---|
| API 响应延迟 | P99 ≤ 200ms | P99 > 200ms |
| 支付成功率 | ≥ 99.95% | < 99.95% |
| 视频首帧时间 | ≤ 1.5s | > 1.5s |
工程要点：好坏阈值应通过历史数据分析和业务方协商确定，避免拍脑袋。建议使用“错误预算”机制，将坏事件量化为预算消耗。
2.5 原则五：可自动化采集（Automatically Collectable）
SLI 数据必须能从监控系统、日志平台或链路追踪工具中自动拉取，无需人工手动统计。自动化采集是持续可靠性评估的前提。
- 采集方式：Prometheus Exporter、StatsD、Fluentd、OpenTelemetry SDK。
- 采集频率：核心 SLI 建议 10s-60s 粒度，非核心可放宽至 5min。
- 存储与计算：使用时序数据库（如 VictoriaMetrics、Thanos）存储原始数据，通过 Recording Rules 预聚合。
# Prometheus Recording Rule 示例：计算 5 分钟窗口的请求成功率
groups:
- name: sli_recording_rules
interval: 1m
rules:
- record: job:request_success_rate:ratio_rate5m
expr: |
sum(rate(http_requests_total{status=~"2..|3.."}[5m]))
/
sum(rate(http_requests_total[5m]))
自动化检查清单：
- 数据源是否已接入统一采集层？
- 采集脚本是否在 CI/CD 中版本化管理？
- 采集失败时是否有告警通知？
- 历史数据保留周期是否满足季度 SLO 回溯需求？
2.6 五大原则综合对照
| 原则 | 核心问题 | 常见反例 | 验收标准 |
|---|---|---|---|
| 明确 | 口径是否无歧义？ | “系统响应慢” | 新成员阅读后能独立复现采集逻辑 |
| 可测量 | 能否从现有系统获取数值？ | “用户体验良好” | 已有对应 Grafana 面板或 PromQL 查询 |
| 面向用户 | 是否反映用户真实感受？ | “CPU 使用率” | 指标下降时用户问题应同步改善 |
| 可区分好坏 | 好坏边界是否清晰？ | “延迟尽量低” | 有明确阈值且与业务方达成一致 |
| 可自动化采集 | 是否无需人工介入？ | “每周手动导出日志统计” | 采集脚本已部署且数据持续写入 TSDB |