SLA 和 SLO

  • 5 分钟

本单元讨论服务级别协议 (SLA) 和服务级别目标 (SLO)。

服务级别协议 (SLA)

由于 SaaS 并不仅仅是一个软件，而主要是一项服务，因此 SaaS 和传统软件产品之间的一个区别是 SLA。 SLA 是 SaaS 提供商与客户之间的协议，用于描述提供商在运行时间和连接方面的承诺。 如果 SaaS 提供商未能实现并维持 SLA 中所述的每个服务的服务级别，则客户可能可以获得补偿。

软件提供商的 SLA 补偿和处罚取决于行业和业务类型。 最常见的两种方案是罚款和服务抵扣费。 对于服务抵扣费，客户可能可以获得针对其每月服务费的抵扣费。

你虽然可以为服务定义 100% 的运行时间，但复杂系统很难实现 100% 的可用性。 大多数 SLA 都与它们可以提供的可用性相关联。

指定 100% 运行时间的 SLA 可能无法保证 100% 的可用性。 100% 的运行时间可能意味着，如果发生中断，客户会根据协议获得补偿。 构建高度可用的系统是一项工程任务，而 SLA 是一种通过法律方式保护公司免受中断影响的方式。

有关 Microsoft SLA 的示例，请参阅联机服务的服务级别协议 (SLA)。

服务级别目标 (SLO)

SLO 是针对以客户为中心的关键服务级别指标 (SLI) 设定的可衡量目标。 SLO 衡量客户对业务或基础结构工作负载的体验。

SLA 确定 SaaS 提供商是否履行了在正式协商的 SLA 中做出的承诺。 所有云业务或基础结构工作负载都应在设计的早期定义 SLO 和 SLI。

服务所有者的重点是确定：

  • 从客户的角度来看，哪些场景是服务运行状况的关键指标。
  • 如何收集 SLI，以使其尽可能接近客户体验。
  • SLI 的 SLO 应该是什么。

软件行业有两种类型的 SLO：

  • 以服务为中心的 SLO 是团队定义的战术目标，旨在随着时间的推移逐步提高服务质量。

    这些 SLO 是一个工程里程碑中可实现的务实目标。 例如，如果某个服务当前实现 99.7% 的可用性，团队可以设定一个目标，在下一季度达到 99.9% 的可用性。

  • 以客户为中心的 SLO 定义理想的未来状态或目标，不需要再超过该状态或目标进行进一步的质量投资，因为客户的期望已得到充分满足。

SLO 在云工作负载开发和运营中非常重要，且与 SLA 的作用不同。 SLO 指示技术团队的状态和方向，而 SLA 是与客户签订的关于所提供服务和补偿条款的合同。

在 Azure 中，服务级别管理是轻量级的，因为 Microsoft 预定义了接口、功能和指标。 使用者需要在使用云工作负载时管理其服务交付预期。

Contoso 场景

Contoso 与其用户之间的简单 SLA 协议首先定义了保证的服务级别和 SLI，例如：

  • 用户可以访问和登录系统、生成设计，并在系统中使用其他可用功能。
  • Contoso 将为涵盖上述场景的服务提供 99.99% 的可用性。
  • 过去 5 分钟内的请求将在 1,000 毫秒内以 99% 的概率送达。

SLI 是时序数据的聚合。 收集 SLA 的方式非常重要。 如果客户使用 API 与服务交互，那么测量系统延迟和处理请求的时间就是准确的 SLI。 但是，如果客户使用 Web 门户与服务交互，则为请求提供服务的总时间还应包括网页的 JavaScript 性能。

SLA 还必须定义故障时间以及对遭遇故障的客户的补偿。 例如，可能会有一个基于运行时间百分比（该百分比与收到的每月抵扣费百分比相关）的补偿结构，或者针对每分钟故障时间的固定补偿系统。

关于 SLO，Contoso 可以首先定义：

  • 服务质量 (QoS)：AI 模型应在用户请求后 3 分钟内生成新的设计灵感。
  • 可用性：每月 99.99%。
  • 容量：CPU、存储、内存、延迟、吞吐量和缩放的目标百分比利用率。
  • 产品采用：建议设计灵感的接受率应高于 20%。