Prometheus误差预算台账与质量门禁的SLA联动 - 第1节
1.1 SLA 定义：服务等级协议的核心要素
服务等级协议（Service Level Agreement，SLA）是服务提供方与客户之间就服务质量达成的正式契约。在可靠性工程中，SLA 定义了当服务未达到约定标准时提供方应承担的后果，通常表现为服务信用（Service Credit）或罚金。
| SLA 构成要素 | 说明 | 典型示例 |
|---|---|---|
| 服务范围 | 明确哪些功能或接口受 SLA 约束 | API 网关、核心交易链路 |
| 指标定义 | 量化服务质量的测量方式 | 可用性 ≥ 99.99% |
| 测量窗口 | 统计周期与数据来源 | 月度滚动、Prometheus 30d 窗口 |
| 例外条款 | 不计入 SLA 的免责场景 | 计划内维护、DDoS 攻击 |
| 违约后果 | 未达标时的补偿机制 | 10% 月度服务费减免 |
SRE 视角：SLA 是商业合同，不是技术指标。SRE 团队不应直接承诺 SLA，而应通过 SLO 来驱动可靠性决策，避免将商业风险与技术实现过度耦合。
1.2 SLO 与 SLI：可靠性工程的量化基石
1.2.1 SLI（Service Level Indicator）—— 服务质量指标
SLI 是服务质量的直接测量值，通常是一个随时间变化的比率或分布。常见的 SLI 类型包括：
- 可用性 SLI：成功请求数 / 总请求数（如 HTTP 200 比例）
- 延迟 SLI：请求响应时间的百分位分布（如 p99 ≤ 200ms）
- 吞吐量 SLI：每秒处理请求数（RPS）
- 错误率 SLI：5xx 响应占比
1.2.2 SLO（Service Level Objective）—— 服务质量目标
SLO 是 SLI 的目标阈值，表示服务在给定时间窗口内应达到的可靠性水平。SLO 通常以“SLI ≤ 阈值”或“SLI ≥ 阈值”的形式定义，并附带时间窗口。
# Prometheus 中定义 SLO 的典型方式
# 可用性 SLO：30 天内可用性 ≥ 99.9%
slo:availability_30d = 1 - (
sum(rate(http_requests_total{status=~"5.."}[30d])) /
sum(rate(http_requests_total[30d]))
) >= 0.999| 概念 | 角色 | 示例 | 是否可协商 |
|---|---|---|---|
| SLA | 商业契约 | 月度可用性 ≥ 99.99% | 法律约束，不可随意调整 |
| SLO | 内部目标 | 30 天滚动可用性 ≥ 99.95% | 可随业务需求调整 |
| SLI | 原始测量 | 过去 5 分钟请求成功率 99.97% | 客观数据，不可协商 |
关键原则：SLO 应比 SLA 更严格（通常预留 0.05%~0.1% 的缓冲），这样即使 SLO 偶尔被突破，SLA 仍可得到保障。例如 SLA 要求 99.99%，SLO 可设为 99.95%，留出误差预算空间。
1.3 SLA 在可靠性工程中的核心地位
SLA 在可靠性工程中扮演着北极星的角色，它决定了 SRE 团队的资源投入优先级、故障响应等级和架构演进方向。没有 SLA，可靠性工作将失去量化依据。
1.3.1 SLA 驱动的三大工程决策
- 故障优先级排序：影响 SLA 的故障（如核心链路中断）获得最高响应等级（P0），SLA 范围外的告警可降级处理。
- 容量规划依据：SLA 要求的可用性决定了冗余设计（多 AZ、多 Region）和资源预留策略。
- 变更节奏控制：误差预算消耗速率直接影响发布频率——预算充足时加速迭代，预算紧张时冻结变更。
常见误区：不要将 SLA 直接作为告警阈值。SLA 是月度/季度统计值，实时告警应基于 SLO 的误差预算消耗速率。例如：当误差预算在 1 小时内消耗超过 10% 时触发告警，而非等到 SLA 被突破才响应。
1.4 SLA、SLO、SLI 的联动关系总结
三者构成从商业承诺到技术测量再到工程行动的完整链路：