在云环境中运行的应用越来越多，系统规模、依赖关系和发布频率都在上升。只靠“服务是否在线”很难判断用户真实体验，也很难指导工程团队做取舍。
SLA、SLO 和 SLI 的价值，是把“服务可靠性”变成可讨论、可衡量、可执行的目标。SRE 团队可以围绕这些指标判断系统是否达标、是否需要降级发布速度、是否要优先投入稳定性建设。
核心要点
- SLA 是对客户或用户的服务承诺，通常包含业务和法律后果。
- SLO 是内部或对外承诺背后的可靠性目标，用来指导工程实践。
- SLI 是衡量 SLO 是否达成的具体指标，例如可用性、延迟、错误率和吞吐量。
- Error Budget 是可靠性目标允许的失败空间，能帮助团队平衡稳定性和迭代速度。
- 好的 SLO/SLI 必须可衡量、可自动化、能反映用户体验，而不是只服务于报表。
定义 SLA、SLO、SLI 和 SRE
什么是 SLA？（承诺）
服务水平协议（SLA）是云提供商和客户或用户之间关于可衡量指标的协议，例如正常运行时间。它通常由公司的法律部门结合业务条款处理，协议中会写清楚要衡量哪些因素，以及未达标的后果，例如服务积分、赔偿或罚款。
SLA 主要适用于付费服务。对 SRE 来说，SLA 不是每天操作的第一层指标，但它定义了服务可靠性的外部承诺边界。
什么是 SLO？（目标）
服务级别目标（SLO）是提供方为了满足客户期望而设定的目标。它通常围绕可用性、延迟、错误率等指标展开。
SLO 更贴近工程团队的日常工作。它回答的是：为了达到服务承诺，我们希望系统在一个时间窗口内表现到什么程度。
什么是 SLI？（我们是怎么做到的？）
服务级别指标（SLI）用于衡量 SLO 的实际达成情况。它提供服务性能的量化视图，例如请求成功率、延迟分位数、错误率或吞吐量。
简单说，SLO 是目标，SLI 是测量方式。
谁是 SRE？
站点可靠性工程师（SRE）关注如何缩小软件开发和运营之间的距离。这个角色与 DevOps 有关联，但更强调用工程化、自动化和可度量的方式管理生产系统可靠性。
SRE 会创建并使用自动化工具来监控、观测和改进生产环境中的软件可靠性。SLO、SLI 和 Error Budget 是 SRE 工作中非常重要的语言。
SLO 和 SLI 的实施
假设我们有一个在生产环境中启动并运行的应用程序服务。第一步是确定 SLO 应该是什么以及它应该涵盖什么。
SLO 示例
SLO = 目标
- 高于此目标，良好
- 低于此目标时，BAD：需要有些改进行动了
设置目标时，不要默认追求 100% 可靠。补丁、部署、停机、依赖故障都可能导致不可用。这就是误差预算 Error Budget 的用武之地。Error Budget 表示服务在不产生合同后果的情况下，可以失败的最长时间或比例。
例如：
SLA = 99.99% 正常运行时间
Error Budget = 每年 55 分 35 秒，或每月 4 分 23 秒。也就是说，在这个口径下，系统可以有这部分不可用时间而不产生 SLA 后果。
接下来要回答的问题是：如何衡量这个 SLO？这就需要 SLI。
SLI 示例
HTTP 请求成功率 = 成功请求数 / 请求总数
常见 SLI 指标
- Durability 可靠性
- Response time 响应时间
- Latency 延迟
- Availability 可用性
- Error rate 错误率
- Throughput 吞吐量
可以通过部署 Prometheus、Grafana 等监控和报告工具，持续检查 SLI 以及 SLO 偏差情况，提高 SLO/SLI 管理的自动化程度。
下面是几个常见映射示例：
- Availability
- SLO: 每月正常运行时间 99.92%
- SLI: 服务可用时间比例
- Latency
- SLO: 92% 的请求其响应时间低于 240 ms
- SLI: 用户请求的平均响应时间
- Error rate
- SLO: 少于 0.8% 的请求会导致错误
- SLI: 失败请求比例
也可以整理成表格：
| 可靠性维度 | SLO 示例 | SLI 示例 |
|---|---|---|
| Availability | 每月正常运行时间 99.92% | 服务可用时间比例 |
| Latency | 92% 的请求响应时间低于 240ms | 用户请求响应时间分布 |
| Error rate | 少于 0.8% 的请求导致错误 | 失败请求数 / 请求总数 |
挑战
- SLA：通常由业务或法律团队编写，如果缺少技术团队参与，可能遗漏关键可衡量指标。
- SLO：目标可能过宽、不可测量，或者无法直接反映用户体验。
- SLI：指标采集和计算口径可能太多，导致 SRE 投入大量精力，但很难形成有效判断。
这些挑战的共同点是：指标没有和真实服务体验对齐。SLO/SLI 不是为了多做几张图，而是为了让团队知道服务是否仍然可靠。
最佳实践
- SLA：业务、法律和技术团队一起参与，确保协议中的指标可以被真实测量。
- SLO：目标要简单、明确、可计算，团队能判断是否达标。
- SLI：定义标准指标和统一口径，帮助 SRE 持续检查服务可靠性和性能。
- Error Budget：用误差预算指导发布节奏。当预算消耗过快时，优先修复稳定性问题。
- 自动化：用监控系统、告警规则和报表持续计算 SLI，而不是依赖人工统计。
落地步骤
- 选择关键用户旅程，例如登录、下单、支付、查询或核心 API。
- 为每个旅程选择 1-3 个真正反映体验的 SLI。
- 设置合理 SLO，不要直接写成 100%。
- 明确统计窗口，例如 7 天、30 天或一个自然月。
- 用 Prometheus、Grafana 等工具自动计算 SLI。
- 根据 SLO 偏差配置告警，并把 Error Budget 消耗纳入发布决策。
总结
SLA、SLO 和 SLI 应该作为系统要求和设计的一部分，而不是上线后才补的一组报表。SRE 需要理解系统如何满足业务需求，并用可衡量指标承担可靠性责任。
好的可靠性管理不是追求所有系统都永远不出错，而是用 SLI 衡量真实体验，用 SLO 定义目标，用 Error Budget 管理取舍，并在影响扩大前采取行动。
本文翻译自：https://dzone.com/articles/implementing-slas-slos-and-slis
在故障处理过程中，能有个地方全局一目了然看到各个服务的健康状况，并且能够关联查询，是非常重要的。因为可观测性数据很多，需要一个良好的呈现方式和查看路径，让 SRE、DEV 使用最低心智即可定位问题。如果您也遇到了类似的问题，欢迎 联系我们，一起交流可观测性的产品和最佳实践。
