1. 概述
在站点可靠性工程（Site Reliability Engineering, SRE）中，SLI（服务等级指标）、SLO（服务等级目标）和 SLA（服务等级协议） 是衡量、管理和维护服务可靠性的核心概念。这些指标和协议构成了我们评估系统稳定性、性能和用户体验的基础。
随着 SRE 实践的发展，这些概念已经成为现代软件工程中不可或缺的一部分。最初由 Google 提出的 SRE 方法，如今已在整个行业广泛传播，推动了对系统可靠性和性能的关注。
本文将深入讲解 SLI、SLO 和 SLA 的定义、作用及其在实际工程中的应用，帮助你更好地实施 SRE 实践。
2. 服务等级指标（SLI）
✅ SLI（Service Level Indicator） 是用来衡量服务性能和可靠性的具体指标。它们是评估服务质量的基础，通过监控 SLI，我们可以获得关于延迟、可用性、错误率等方面的关键数据。
选择合适的 SLI 非常重要，因为它们直接影响我们衡量服务是否满足用户期望的方式。
常见 SLI 示例
| SLI 类型 | 描述 |
|---|---|
| 延迟（Latency） | 衡量服务响应请求所需的时间，直接影响用户体验 |
| 吞吐量（Throughput） | 衡量系统单位时间内处理的请求数量 |
| 错误率（Error Rate） | 衡量失败请求占总请求数的比例 |
| 可用性（Availability） | 衡量服务正常运行的时间比例 |
进阶 SLI
除了基础指标，还可以引入一些更高级的 SLI，例如：
- 错误预算（Error Budget）
- 用户满意度评分（User Satisfaction Score）
- 请求成功率（Request Success Rate）
这些指标能帮助我们更细致地了解服务状态，提前发现潜在问题。
3. 服务等级目标（SLO）
✅ SLO（Service Level Objective） 是我们为 SLI 设定的目标值，代表我们期望服务达到的性能和可靠性水平。
SLO 是团队内部设定的目标，用于衡量是否达到了预期的服务质量。
示例说明
- 延迟 SLO：95% 的请求响应时间应小于 200ms
- 可用性 SLO：服务在一个月内的可用性应达到 99.9%
- 错误率 SLO：过去 30 天内错误率不超过 0.1%
⚠️ 当 SLI 超出 SLO 时，就需要采取纠正措施，确保服务质量不下降。
SLO 的动态性
SLO 不是一成不变的。随着用户需求和技术演进，我们需要定期回顾和调整 SLO，确保它们仍然具有现实意义并能推动系统持续改进。
4. 服务等级协议（SLA）
✅ SLA（Service Level Agreement） 是服务提供方与客户之间签订的正式合同，明确了服务应达到的最低标准，并通常包含违约时的赔偿条款。
SLA 与 SLI 和 SLO 的区别在于，它具有法律效力，直接影响客户信任和商业利益。
SLA 的典型内容
| 内容项 | 说明 |
|---|---|
| 性能指标 | 如 99.9% 可用性、95% 请求响应时间 ≤ 100ms |
| 违约惩罚 | 如服务积分补偿、费用减免 |
| 例外条款 | 如计划维护期间不计入 SLA 考核 |
真实案例：AWS 的 SLA 违约
2019 年，AWS 发生一次大规模宕机事件，导致其多个服务未能达到 SLA 中规定的可用性标准。最终，AWS 向受影响的客户发放了服务积分作为补偿。
⚠️ 这个案例说明，SLA 不仅影响客户信任，还可能带来实际经济损失。因此，设置 SLA 必须谨慎，确保系统具备支撑能力。
5. SLI、SLO 与 SLA 的对比
| 项目 | SLI | SLO | SLA |
|---|---|---|---|
| 定义 | 服务性能的衡量指标 | SLI 的目标值 | 服务提供方与客户的合同 |
| 用途 | 监控服务健康状况 | 设定目标 | 明确法律责任和赔偿 |
| 使用场景 | 内部监控 | 内部目标设定 | 客户对外承诺 |
| 示例 | 延迟、可用性 | 99.9% 可用性 | 99.9% 可用性 + 服务积分赔偿 |
✅ 三者关系总结：
- SLI 是“我们测量什么”
- SLO 是“我们希望达到什么”
- SLA 是“我们对外承诺什么”
三者共同构成了 SRE 的核心框架，帮助我们系统性地管理服务质量和客户满意度。
6. SRE 指标监控工具推荐
要有效管理 SLI、SLO 和 SLA，离不开合适的监控工具。以下是一些业内广泛使用的工具：
6.1 Prometheus + Grafana
- Prometheus：用于采集和存储时间序列数据
- Grafana：用于数据可视化，支持灵活的仪表盘配置
✅ 适合用于实时监控 SLI，跟踪 SLO 达成情况。
6.2 Google Cloud Operations Suite（原 Stackdriver）
- 提供 Google Cloud 服务的深度监控
- 支持 SLO 自动计算和告警
✅ 适合运行在 GCP 上的服务。
6.3 Datadog
- 支持多云平台和多种应用类型
- 支持基于 SLI 设置告警规则
✅ 适合需要统一监控多个环境的团队。
6.4 New Relic
- 提供应用性能深度洞察
- 支持延迟、错误率等关键 SLI 指标的监控
✅ 适合关注应用性能的场景。
6.5 SLO Tracker
- 专门用于 SLO 管理和自动跟踪
- 可与 Prometheus、Stackdriver 等集成
✅ 适合需要系统化管理 SLO 的团队。
7. SLI、SLO 与 SLA 管理的最佳实践
7.1 涉及利益相关者
在制定 SLO 和 SLA 时，应邀请产品、工程、客户支持等多方参与，确保目标合理、可达成，并获得广泛认同。
7.2 定期审查
服务在变，用户需求也在变。建议每季度或半年审查一次 SLI/SLO/SLA，确保它们依然贴合当前业务。
7.3 自动化监控
自动化监控 SLI 和 SLO 可以减少人为干预，提高响应速度。例如：
- Prometheus 自动采集指标
- Grafana 自动生成仪表盘
- 告警系统自动通知团队
7.4 明确沟通机制
- 对外：与客户明确 SLA 条款，包括覆盖范围、例外情况和违约处理
- 对内：制定 SLA 违约的应急响应流程，确保快速响应
7.5 平衡挑战性与可行性
- 目标太高：容易导致团队压力大、目标难以达成
- 目标太低：无法推动服务质量提升
✅ 推荐采用“错误预算（Error Budget）”机制，允许一定容忍度，鼓励团队在保障质量的同时持续创新。
8. 总结
本文系统讲解了 SRE 中的三个核心概念：SLI、SLO 和 SLA。
- SLI 是我们监控服务健康状况的“尺子”
- SLO 是我们设定的目标，驱动系统改进
- SLA 是我们对客户的承诺，具有法律约束力
通过合理设置和管理这三者，我们可以构建高可靠、高性能的服务体系，既满足用户需求，又保障业务稳定。
✅ 记住一句话：
“SLI 告诉我们当前在哪里，SLO 告诉我们想去哪里，而 SLA 告诉我们不能不去的地方。”
希望这篇文章能帮助你更好地理解 SRE 的核心理念，并在实践中灵活应用。