如何阅读服务级别协议（SLA）

服务级别协议（SLA）是云体系结构中最常引用的文档之一，但它也是最经常被误解的文档之一。 许多工程师将 SLA 视为简单的可用性保证，但它是一份合同文档，其中包含塑造其含义的精确定义、条件和排除项。 如果不仔细阅读 SLA，可以根据不受支持的假设做出体系结构决策。

本文介绍如何以方法方式解释 SLA，以便在设计可复原工作负载时将它们用作工程输入。 本文介绍如何：

• 解释 SLA 实际保证的内容。
• 确定技术服务提供商通常如何定义和衡量可用性。
• 识别影响覆盖范围的条件和排除项。
• 使用 SLA 来通知体系结构决策，而不是取代你设计的复原能力。

大多数 SLA 定义有关运行时间或可用性的承诺，但服务提供商还可以围绕其他要求（例如性能、恢复时间或数据持续性）定义 SLA。

SLA 与 SLO 以及可靠性目标的关系

在阅读 SLA 之前，请了解它与其他可靠性概念相适应的位置：

• SLA 是服务提供商和客户之间的合同承诺，对未满足目标产生明确的后果。

• 服务级别目标（SLO）是为自己的工作负荷设置的内部可靠性目标。

SLA 描述了服务提供商承诺的最低保证。 SLO 反映了 用户 实际需要的可靠性。 参考 SLA 来制定 SLO，但不要简单地采用 SLA 的百分比作为你服务的可靠性目标。 考虑自己的代码、依赖项、操作过程，以及用户对停机时间的容忍度。 有时，需要比服务提供商的 SLA 组合更严格的 SLA。 在其他情况下，工作负荷可以容忍超出服务提供商财务承诺的问题。

有关如何定义 SLA 和可靠性目标的详细信息，请参阅 有关定义可靠性目标的建议。

为何应阅读服务水平协议 (SLA)

SLA 是工程信号，不是严格的可用性保证。 服务提供商承诺达到的定义服务级别条件。 如果服务提供商不履行这些承诺，他们还描述了财务后果。 SLA 不保证应用程序可靠、用户避免停机或服务提供商阻止所有故障。

有关 SLA 的假设会导致体系结构决策不佳。 架构师有时会将 SLA 的运行时间百分比视为服务可靠性的直接指标。 此方法通常忽略关键细节，包括如何定义停机时间、必须满足哪些条件以及排除哪些方案。 生成的工作负荷设计可能不允许 SLA 所暗示的故障模式。

仔细审查 SLA 可发现用于设计可复原系统的重要信号：

• 预计会出现暂时性故障： 服务提供商预计短期故障会发生。 SLA 通过停机时间定义和重试要求明确此期望。 将体系结构设计为将暂时性故障作为正常情况处理，而不是异常故障。

• 服务不相等： 服务在其 SLA 范围、条件和排除项中有所不同。

• 运行时间百分比不统一应用： 对于核心操作，具有 99.99% SLA 的服务可能会针对依赖的特定功能提供较低的 SLA 或根本不提供 SLA。

• SLA 不涵盖所有可靠性因素： 仅 SLA 并不能解决所有可靠性注意事项。 另请查看产品文档中的服务限制、配额、限制行为、已知限制和操作指南。

SLA 是什么，什么不是 SLA

SLA 是一组条件承诺。 它指出，如果 客户满足某些要求，那么 服务提供商承诺提供一个定义的服务级别。 如果 服务提供商未能达到该级别， 则 客户会收到补偿，通常采用服务额度的形式。

SLA 仅适用于满足特定先决条件（例如配置要求、部署拓扑或操作行为）时。 服务水平协议（SLA）明确规定了什么算作故障。 如果问题不符合记录的停机时间定义，SLA 不会涵盖该问题。

不要创建一个将 SLA 百分比相乘的复合 SLA，用于估算多个依赖系统的可用性。 此计算可以提供近似的最大限制，但在实践中是不可靠的。 它假定所有服务都独立失败，这种情况很少发生。 它还会忽略每个 SLA 中的唯一定义、条件和排除项。 复合计算通常使系统看起来比它更可靠，它们不会替换工作负荷的正确 SLO 定义或故障模式分析（FMA）。 有关详细信息，请参阅 定义可靠性目标的建议。

用于读取 SLA 的实用模型

不要全文细读 SLA。 请改用结构化的五步法来提取对您的体系结构重要的信息。

阶段 1：定义

从定义部分开始。 定义控制 SLA 度量可用性的方式以及故障计数。

• 定义与百分比一样重要： 99.99% SLA 听起来令人印象深刻，但其价值完全取决于 SLA 算作故障的内容及其度量单位。 当停机时间的定义较窄时，有效覆盖率比建议的百分比窄。

• 关键术语： 条款（如 有效请求、 停机时间和 计费分钟数 ）定义服务提供商提交的内容。 如果操作不符合 SLA 下的有效请求，则不会影响可用性计算。

  确定 SLA 涵盖哪些操作、显式或隐式排除哪些组件，以及它适用于每个服务实例还是跨实例池。

阶段 2：度量

了解 SLA 如何计算可用性：

• 基于时间与基于请求的度量： 基于时间的度量通常跟踪服务是否在每个时间间隔内可用。 基于请求的度量跟踪成功响应与有效请求总数的比率。 相同的服务中断可能会产生不同的可用性百分比，具体取决于 SLA 使用的方法。

• 重试和聚合： 某些 SLA 要求在指定时间段内重试失败的请求，然后再将其计为失败。 其他 SLA 在整个计费周期内聚合可用性，因此短暂的服务中断可能不会减少足以触发信用额度的计算可用性。

• 聚合范围： 确定 SLA 是衡量每个单个服务实例的可用性，还是跨范围中的所有实例（例如帐户或订阅）的可用性。 当 SLA 计算多个实例的可用性时，正常的实例可以抵消失败的实例。 此计算可能会生成比实际经历的任何单个实例更高的报告可用性。

通道 3：先决条件、变体和排除项

确定 SLA 所需的条件：

• 所需的配置和行为： 许多 SLA 需要特定的部署配置或操作行为，例如实现重试逻辑或保留记录的配额。 例如，仅当使用固态硬盘（SSD）而不是硬盘驱动器（HDD）时，存储 SLA 才适用，因为服务提供商的运行时间承诺取决于该存储类型的性能特征。

• 配置会影响 SLA 条款： 检查服务配置如何更改 SLA。 价格较高的服务级别有时提供不同的 SLA 承诺，但其差异不一定只是更高的可用性百分比。 更高的层可能有不同的定义、不同的度量方法或更少的排除项。 高级层 SLA 可能会更广泛地定义停机时间（更好的覆盖范围），而不是增加运行时间百分比。 不要仅依赖百分比。 另请阅读定义。

  部署模型还会影响 SLA 条款。 对于同一服务，单实例部署的 SLA 可能低于提供冗余的多实例部署。

• 环境和操作排除项： SLA 通常从计划内维护、不可抗力、客户启动的操作、配置错误、超出配额、格式不正确的请求以及预览或不支持的功能中排除停机时间。

阶段 4：设计影响

若要最有效地使用服务，请考虑 SLA 显示服务的行为方式以及如何围绕该服务设计解决方案：

• 预期的失败模式： SLA 的定义和条件指示服务提供商将哪些故障类型视为正常和预期。 体系结构必须容忍这些故障。

• 服务提供商优先级： 服务提供商如何定义可用性、衡量可用性，并排除某些方案会显示其核心承诺以及它认为你的责任。

• 设计决策： 如果 SLA 排除某些故障模式，请决定是否接受风险、添加冗余或使用备用服务。

步骤 5：如何申请服务额度

SLA 将服务额度定义为停机补偿，但服务提供商通常不会自动应用它们。 他们不会主动监视 SLA 违规或为你提出索赔。 必须检测违反 SLA 的中断，记录中断，并在截止时间内提交索赔。 使用以下步骤准备并执行此过程。

步骤 1：了解要监视的内容

在事件发生之前，请确定需要收集哪些数据来证实声明。 查看 SLA 的定义和度量方法以确定：

• 哪些指标映射到 SLA： 如果 SLA 度量请求成功率，请监视 SLA 涵盖的终结点的 HTTP 响应代码。 如果它以分钟为单位度量运行时间，请定期监视服务可用性。

• 哪些实例在范围内： SLA 通常适用于特定层、版本或部署配置。 仅监视符合 SLA 覆盖范围的实例。

• 提供商对失败的定义： 一些 SLA 对停机时间的定义非常狭窄。 例如，SLA 可能要求所有请求连续失败一或多分钟，或者可能要求在公共列表中记录停机事件。 如有必要，请设置监视以捕获 SLA 定义的特定故障条件。

步骤 2：在事件期间和之后保留记录

发生中断或降级时，收集和保留与 SLA 定义一致的证据：

• 时间 戳： 记录事件的开始和结束时间，包括时区。 请注意影响持续时间以及它是连续还是间歇性的。

• 错误详细信息： 捕获观察到的特定错误代码、错误消息或超时行为。 SLA 定义的失败条件应与这些详细信息相对应。

• 请求日志： 如果 SLA 在计算失败之前需要重试尝试，请保留日志以显示你满足该要求。 包括重试次数、退避间隔和每次尝试的结果。

• 配置证据： 如果 SLA 需要特定的部署配置（例如特定数量的冗余或高级层），请记录实例在事件发生时如何满足这些先决条件。

• 服务提供商通信： 保存来自服务提供商确认问题的任何事件通知、状态页更新或支持通信。

步骤 3：确定事件是否违反 SLA

在提交声明之前，请计算事件是否满足额度的阈值：

1. 使用记录的数据应用 SLA 的可用性公式。 使用 SLA 指定的相同单位，例如分钟、请求或其他指标。

2. 减去任何属于已记录排除项的时间，例如计划内的维护窗口、被排除的事件类型，或当配置不符合 SLA 先决条件的时间段。

3. 将结果与 SLA 的承诺百分比进行比较。 如果计算的可用性低于阈值，则可能应用信用额度。

步骤 4：在所需时间范围内提交声明

大多数 SLA 都规定在事件发生后提交索赔的最后期限。 如果错过了截止时间，则不管中断的严重性如何，都会放弃信用额度。

1. 查找索赔窗口： 查阅 SLA 文档以了解提交截止日期。 常见时间范围从事件发生后 30 到 60 天不等，但每个服务提供商设置自己的截止时间。

2. 包括支持证据： 附加在步骤 2 中收集的记录，包括时间戳、错误日志、重试证据和配置详细信息。 服务提供商会更快地处理记录良好的索赔。

3. 通过正确的通道提交： 服务提供商通常需要通过支持门户或正式请求过程提交声明。 按照记录的程序以避免索赔被拒绝。

示例教程：解析虚构的服务级别协议 (SLA)

为了说明如何在实践中阅读 SLA，本部分使用虚构的服务 “鸽子邮政服务”（PPaaS）。 PPaaS 是一种假想的托管消息传递服务，它通过经过训练的运营商鸽子传递消息。 API 接受消息并将其发送到负责释放鸽子并向收件人发送邮件的调度程序。

PPaaS 是故意荒谬的，但其 SLA 的结构反映了许多现实世界的 SLA。 此示例演示了五次通过方法。

PPaaS 服务水平协议

PPaaS SLA 包含以下定义：

• 有效请求： 通过 PPaaS API 调度的消息，该消息符合记录的消息架构。

• 停机 时间： 当所有尝试向预配的 PPaaS 终结点发送 有效请求 失败并出现错误响应或未收到响应的时间段。

• 计费总分钟数： 在计费月份中，尝试至少一次 有效请求 提交操作的总分钟数。

• 每月运行时间百分比，计算为：

  $$ \text{每月运行时间百分比} = \frac{\text{总计费分钟数} - \text{停机时间}}{\text{总计费分钟数}} \times 100 $$

PPaaS SLA 包括以下服务额度。

PPaaS SLA 包括以下条件和排除项：

• SLA 不包括由恶劣天气引起的故障。

• SLA 每周最多排除 15 分钟的计划的合作维护。

• 在将请求计为失败之前，必须实现至少三次重试，并采用指数退避策略。

• SLA 不适用于基本 Coop 层。

根据以下步骤逐步阅读 PPaaS SLA

以下工序采用五步法应用于PPaaS服务级别协议。 每个步骤都会显示应塑造体系结构的信息。

第1步：了解定义

检查每个定义的术语的含义：

• 有效请求： 符合记录架构且不超过大小限制的消息。 可以在产品文档中检查限制。 失败的超大消息不计算在 SLA 内。

• 计费总分钟数： 尝试发送消息的分钟数。 如果不在一个月内发送消息，这些空闲分钟数不会考虑计算，即使服务在此期间出现问题。

• 如何定义可用性： SLA 涵盖对消息进行排队的时间，而不是航班时间、传递确认或返回传输的时间。 如果你的鸽子需要三天才能传达信息，那超出了 SLA 的范围。

第二步：了解如何测量可用性

PPaaS SLA 揭示了以下有关度量的关键观察：

• 重试要求： 只有在使用指数退避方法重试时，故障才会计数。 如果不重试，SLA 不会测量故障。

• 跨计费周期的聚合： SLA 计算整个月份的可用性。 如果服务持续运行本月剩余时间，则 10 分钟的中断可能不会违反 SLA。

阶段 3：识别条件和排除项

多个条件限制了 SLA 的适用性：

• 恶劣天气条件： 检查产品文档或服务提供商以确定它们如何定义恶劣天气条件。 此排除项消除了一系列故障，这些故障经常影响基于鸽子的服务。

• 计划合作维护：SLA 每周最多排除 15 分钟的计划内维护时间。 此维护时段不计入 SLA，即使在此期间服务不可用。 你可能无法控制何时发生维护。 查看产品文档，了解何时发生维护并相应地进行计划。

• 层级特定约定： 基本 Coop 层没有 SLA。 如果使用基本层，则没有合同可用性承诺。

第4阶段：提取体系结构信号

PPaaS SLA 揭示了体系结构的几个重要信号：

• PPaaS 认为失败的原因： 仅完成持续调度失败，该故障至少持续了一个完整分钟计数。 SLA 期望您的工作负荷能够处理短暂中断、缓慢的调度以及单个请求的失败。

• 它不能保证： SLA 仅涵盖是否可以成功将消息提交到 PPaaS API 并接受发送。 它不能保证在您放飞鸽子后传递时间、交付成功或消息的完整性。 确认的交付完全不符合 SLA 的要求。

• 架构师应引入复原能力的位置： 通过实现所需的重试逻辑，应对间歇性调度失败的设计。 为传递保证很重要的情况添加回退机制，因为 SLA 不包括实际交付。 SLA 不包括与天气相关的中断和计划性维护，因此，体系结构必须能够通过替代路径，或对无法控制的计划性不可用情况具备容忍能力，以应对这些情况。

步骤 5：准备申请服务额度

若要准备好在 PPaaS 无法满足其 SLA 的情况下证实声明，请准备以下要求：

• 保留详细日志： 按分钟粒度跟踪调度成功或失败。 保留日志以证明每次失败尝试都包含了所需的三次重试，并采用了指数退避策略。 同时保留部署区域的独立天气数据。 PPaaS 可能会将停机归因于恶劣天气，而不是服务问题。

• 在索赔窗口内提交： 实际 SLA 通常要求在计费月结束后 30 到 60 天内提交索赔。 将截止日期添加到日历，以免失去有效的索赔权。

后续步骤

• 查看您所依赖的服务的服务等级协议。 对于 Azure 服务，请从 在线服务的 SLA 开始。 工作负荷还可能依赖于来自其他服务提供商的服务。 对这些 SLA 应用相同的五阶段步骤。
• 将 SLA 保证与工作负荷的可靠性目标进行比较，以确定差距。
• 了解如何定义超出服务提供商服务水平协议 (SLA) 的服务水平目标 (SLO)。 请参阅 有关定义可靠性目标的建议。