1. SLO 基础概念：什么是 SLO、SLI、SLA
在开始使用 Prometheus 构建 SLO 告警体系之前，必须先理解三个核心术语：SLI、SLO 和 SLA。它们是现代站点可靠性工程（SRE）的基石，也是后续所有告警规则、作业模板和故障响应流程的设计依据。
1.1 核心定义
| 术语 | 英文全称 | 中文释义 | 一句话理解 |
|---|---|---|---|
| SLI | Service Level Indicator | 服务等级指标 | 你测量什么——一个可量化的数值 |
| SLO | Service Level Objective | 服务等级目标 | 你承诺什么——一个目标阈值 |
| SLA | Service Level Agreement | 服务等级协议 | 你合同上写什么——有惩罚条款的承诺 |
记忆口诀：SLI 是数据，SLO 是目标，SLA 是合同。没有 SLI 就没有 SLO，没有 SLO 就没有 SLA。
1.2 三者的区别与联系
下面这张关系图清晰地展示了 SLI → SLO → SLA 的层级结构：
关键区别：SLO 是内部目标，由团队自主设定；SLA 是外部合同，通常附带赔偿条款。SLO 一般比 SLA 更严格，为 SLA 留出安全缓冲。
1.3 为什么 SLO 对现代运维如此重要
传统运维以“系统不宕机”为唯一目标，但现代分布式系统无法做到 100% 可用。SLO 提供了一种可量化、可协商、可告警的运维范式，其重要性体现在以下五个方面：
- 从“尽力而为”到“数据驱动”——不再凭感觉判断系统是否健康，而是用 SLI 数据说话。
- 定义“足够好”的标准——明确告诉团队：“系统达到什么程度就算正常”，避免过度追求不切实际的 100%。
- 指导告警与故障响应——基于 SLO 燃烧速率（Burn Rate）设置告警，比静态阈值更精准、更早发现问题。
- 平衡可靠性与迭代速度——SLO 为“允许犯错”划出边界，团队可以在 SLO 范围内放心发布新功能。
- 建立客户信任——SLA 是商业承诺，SLO 是技术保障，两者结合形成可审计的服务质量报告。
常见误区：不要将 SLO 等同于 SLA。SLO 是内部工具，可以随时调整；SLA 是法律文件，修改需要合同流程。很多团队把 SLA 直接当作 SLO 使用，导致告警过于宽松或频繁触发无意义的告警。
1.4 典型 SLI 指标分类
在 Prometheus 生态中，常见的 SLI 指标通常分为四大类，每一类都可以通过 Prometheus 的 histogram、counter 或 gauge 来采集：
| 类别 | 典型指标 | Prometheus 示例 |
|---|---|---|
| 可用性 | 请求成功率 / 服务存活率 | sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m])) |
| 延迟 | P50 / P95 / P99 响应时间 | histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) |
| 吞吐量 | 每秒请求数（RPS） | sum(rate(http_requests_total[5m])) |
| 错误率 | 5xx / 4xx 占比 | sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) |
1.5 一个完整的 SLO 定义示例
假设我们有一个电商 API 服务，可以这样定义它的 SLO：
# SLI 定义
- 指标名称：API 请求延迟（P99）
- 数据来源：http_request_duration_seconds 直方图
# SLO 定义
- 目标：过去 30 天内，99.9% 的请求延迟 ≤ 200ms
- 测量窗口：30 天滚动窗口
- 燃烧速率告警：当 1 小时内消耗 5% 的误差预算时触发告警
# SLA 定义（对外）
- 承诺：99.95% 的请求延迟 ≤ 500ms
- 惩罚：低于 99.95% 时，按月度服务费的 10% 赔偿
本课程后续内容：我们将基于这个示例，使用 Prometheus 的
sloth 或 prometheus-operator 生成 SLO 告警规则，并联动作业模板实现自动化故障响应。