开源项目的 SLE 和 SLA 指南

当没有约束性合同时，设置服务级别预期可以帮助项目成功运行。

服务级别协议 (SLA) 术语是人们熟悉的术语，尤其是在云或托管服务的上下文中。SLA 指的是服务提供商对其客户的合同义务，并且是定义服务允许的性能水平的工具。例如，服务协议可能会确定 99.95% 的正常运行时间的服务级别，对于低于 99.95% 正常运行时间的情况（一年内停机时间超过约 4.5 小时或每季度 1.125 小时）会有处罚。

该术语对于描述围绕服务正常运行时间的要求和期望非常有用，因此已被用于其他不存在或无法存在合同协议的用途。例如，社区 SLA 或免费层级 SLA 可能会描述一种非合同情况，其中期望或期望维持一定的服务水平。

这种用法的问题是一个不太顺畅但很重要的问题。在 SLA 中，“协议”始终意味着合同；该词的语境含义无法翻译到其他语境中。两个人或多人之间的关系本质上是非合同式的。这就是发明合同的原因：提供一种将协议及其条款形式化的方法，使其超出达成协议的那一刻。

误用 SLA 术语至少在两个领域造成特定问题

在云原生站点/系统可靠性工程 (SRE) 中，该实践的两个核心工具是服务级别目标 (SLO)，旨在确保用户体验在可接受的范围内，以及服务级别指标 (SLI)，用于跟踪 SLO 的状态和趋势。在商业情况下，这两者都汇总到 SLA 中，但在非商业情况下，没有好的等效项可以汇总。
在某些情况下，托管云服务交付给用户群，但不存在合同动态，例如，学术环境中的 IT 服务以及作为开源项目一部分交付的开源服务。这些群体需要一种在没有合同要素的情况下构建和讨论服务级别的方法。

这种文字上的不顺畅和书生气对于我在 Operate First 项目上的工作非常重要，因为我们工作的一部分是创建第一个完全开源的 SRE 实践。这不仅包括拥有 SLO/SLI，还包括记录如何编写它们。我们这样做是因为 Operate First 是一个上游开源项目，其中的内容很可能会在具有 SLA 的商业环境中被采用。

作为 Operate First 项目的社区架构师，我提倡采用类似的、使用广泛的术语服务级别预期 (SLE) 作为我们将服务级别目标 (SLO) 汇总到的顶级对象。该术语反映了开源社区的性质。开源社区的成果并非源于社区成员之间的合同协议。相反，社区是通过共同的兴趣和围绕完成工作的共同期望而凝聚在一起的。

换句话说，如果开源项目中的一个团队没有完成另一个团队依赖的组件，则没有 SLA 规定 A 团队欠 B 团队金钱补偿。开源项目运营的服务也是如此：没有人期望 SLA 约束的商业级别服务。社区成员和更广泛的用户群期望团队清楚地说明他们能做什么和不能做什么，并大致坚持这样做。

我将分享我的建议，即可以构建一组 SLO，使其在从 SLE 环境转移到 SLA 环境时保持不变。换句话说，构成 SLO 基础的精心构建的 SLI 在从社区云转移到商业云时将保持不变。

但首先，需要一些关于 SLE 的起源和用途的补充背景知识。

现实世界中的 SLE

实施 SLE 的两个常见场所是大学/研究环境和 Kanban 工作流。下面的结论部分包含使用非常相似的 SLE 的示例组织列表，包括密歇根大学、圣路易斯华盛顿大学和其他机构。在 Kanban 工作流中，SLE 定义了当团队之间存在工作依赖关系时彼此之间的期望。当一个团队需要另一个团队在某个截止日期前完成其工作或在特定时间段内响应请求时，他们可以使用添加到 Kanban 逻辑中的 SLE。

在这些情况下，可能会从相关上下文中提供或理解时间和响应信息。例如，工作人员系统管理员可能会在早上 8 点到晚上 8 点之间轮班，每周五天。发布的预期将是 5x12 用于非关键问题，对于关键的、所有服务和网络中断类型的停机，则有其他一些预期。

在开源项目中，开发人员可能会在开发产品与支持产品服务之间平衡时间。团队可能会提出在周一至周四午餐后清除问题和错误队列。因此，对于非关键情况，SLE 将为 4x4。

我们最喜欢的开源资源

什么是冷切换 SLO？

这里的核心思想是设计一组 SLO，这些 SLO 可以从 SLE 下移动到 SLA 下，而无需更改任何其他内容。

SLE 的重点是预期，通常可以将其视为从低预期环境到高预期环境的范围。因此，编写 SLO/SLI 组合以与 SLE 环境配合使用的行为有助于记录关于如何根据此服务的用途、设置等来调整指标的测量的知识。

建立具有不同服务详细信息的 SLE（如果它们具有不同的正常运行时间目标），并明确边界，例如，“开发团队在工作周的既定时间窗口内响应中断。”
开发人员和运营人员为一个服务建立一到三个 SLO，例如，“正常运行时间，故障单的响应时间为 5x5”，这意味着周一至周五的 UTC 时间 12:00 至 17:00 (5x5)。
创建 SLI 以跟踪目标。在编写 SLI 规范时，尽可能为特定情况和通用情况编写。目标是为读者提供他们使用此软件在其环境中实施该模式所需的大部分内容。

8 个 SLE 示例

虽然 SLE 并非普遍使用，但我发现许多 SLE 的示例出现在学术和研究环境中、一个开源社区示例（Fedora 和 CentOS 社区）中，以及 Kanban 中一个非常相似的概念，即完成从开始到结束的 sprint 的预期。

我将以每个页面的介绍性内容的非详尽列表来结束本文

密歇根大学 ITS 通用 SLE

通用校园服务级别预期 (SLE) 为客户接收 ITS 服务设定了期望。SLE 反映了信息和技术服务 (ITS) 当今的业务方式。此 SLE 描述了事件和请求的响应时间、工作的优先级以及中断通知流程。

特定服务可能具有额外的承诺级别，并将根据基于服务的 SLE 单独定义。

圣路易斯华盛顿大学 (2016) 所有客户的基本 IT 服务的 SLE

本文档代表了华盛顿大学信息技术 (WashU IT) 基本信息技术 (BIT) 捆绑服务的服务级别预期 (SLE)。

本协议的目的是确保此服务满足客户期望，并定义各方的角色/责任。SLE 概述了以下内容

服务概述

服务功能（包含和排除）

服务保证

服务角色与职责

服务报告与指标

服务审查、捆绑与定价

每个部分都提供了特定于 BIT 捆绑服务的服务和支持详细信息，并概述了 WashU IT 针对所有服务和系统的通用支持模型。

罗格斯大学 (2019) 虚拟基础设施托管的 SLE