实施 SLA、SLO 和 SLI：SRE 实用指南
在当今的信息技术 （IT） 数字化转型世界中，每天都有许多应用程序托管在云环境中。每天监控和维护这些应用程序非常具有挑战性，我们需要适当的指标来衡量和采取行动。这就是实施 SLA、SLO 和 SLI 的重要性所在，它有助于有效监控和维护系统性能。
定义 SLA、SLO、SLI 和 SRE
什么是 SLA？（承诺）
服务水平协议（SLA）是云提供商和客户端/用户之间关于可衡量指标的协议;例如，正常运行时间检查等。这通常由公司的法律部门根据业务和法律条款处理。它包括要考虑的所有因素以及如果失败的后果；例如，积分、罚款等。它主要适用于付费服务，不适用于免费服务。
什么是 SLO？（目标）
服务级别目标（SLO）是云提供商必须满足的目标，以满足与客户达成的协议。它通常是云提供商必须满足的特定的一些指标，以满足客户的期望（即可用性等）。这将有助于客户提高整体服务质量和可靠性。
什么是 SLI？（我们是怎么做到的？）
服务级别指标（SLI）衡量对 SLO 的遵守情况和 SLI 的实际测量。它提供了服务性能的量化视图（即 99.92% 的延迟等）。
谁是 SRE？
站点可靠性工程师是始终考虑最小化软件开发和运营之间差距的工程师。这个术语与DevOps略有关系，DevOps的重点是识别差距。SRE 创建并使用自动化工具来监视和观察生产环境中的软件可靠性。
在本文中，我们将讨论 SLO/SLI/SLA 的重要性，以及如何由站点可靠性工程师 （SRE） 将它们实施到生产应用程序中。
SLO 和 SLI 的实施
假设我们有一个在生产环境中启动并运行的应用程序服务。第一步是确定 SLO 应该是什么以及它应该涵盖什么。
SLO 示例
SLO = 目标
- 高于此目标，良好
- 低于此目标时，BAD：需要有些改进行动了
- 在设置目标时，请不要认为它是 100% 可靠的。 由于补丁、部署、停机等原因都可能导致不可用。这就是误差预算 Error Budget 的用武之地。Error Budget 是服务在不产生合同后果的情况下可能失败的最长时间。
例如：
SLA = 99.99% 正常运行时间
Error Budget = 每年 55 分 35 秒，或每月 4 分 23 秒，系统可以宕机而不会产生任何后果。一个步骤是如何衡量这个 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: 失败请求比例
挑战
- SLA：通常，SLA 是由业务或法律团队编写的，没有技术团队的投入，这会导致缺少要衡量的关键方面。
- SLO：无法测量或太宽而无法计算
- SLI：在捕获和计算度量值方面存在太多的指标和差异。它导致 SRE 付出很多努力，但效果不佳。
最佳实践
- SLA：当 SLA 由公司的业务/法律团队和提供商编写时，让技术团队参与进来。这将有助于将确切的技术方案反映到协议中。
- SLO：这应该很简单，并且易于衡量，无论我们是否符合目标。
- SLI：定义要监控和衡量的所有标准指标。它将帮助 SRE 检查服务的可靠性和性能。
总结
SLA、SLO 和 SLI 的实现应作为系统要求和设计的一部分包含在内，并且应处于持续改进模式。SRE 需要了解系统如何满足业务需求并承担责任，并采取必要措施将影响降至最低。
本文翻译自：https://dzone.com/articles/implementing-slas-slos-and-slis
在故障处理过程中，能有个地方全局一目了然看到各个服务的健康状况，并且能够关联查询，是非常重要的。因为可观测性数据很多，需要一个良好的呈现方式和查看路径，让 SRE、DEV 使用最低心智即可定位问题。如果您也遇到了类似的问题，欢迎 联系我们，一起交流可观测性的产品和最佳实践。
