SRE（站点可靠性工程）是一种确保 Web 项目可用性的方法。 它被认为是 DevOps 的框架，讨论如何在应用 DevOps 实践中取得成功。 本文的翻译 书籍 来自谷歌。 我自己准备了这个翻译，并依靠自己在理解监控流程方面的经验。 在电报频道 и 我还出版了同一本书中有关服务级别目标的第 6 章的翻译。
猫翻译。 享受阅读！
如果不了解哪些指标真正重要以及如何衡量和评估它们，就不可能管理服务。 为此，我们为用户定义并提供一定级别的服务，无论他们使用我们的内部 API 还是公共产品。
我们利用我们的直觉、经验和对用户愿望的理解来了解服务级别指标 (SLI)、服务级别目标 (SLO) 和服务级别协议 (SLA)。 这些维度描述了我们想要监控的主要指标，以及如果我们无法提供预期的服务质量我们将做出反应的主要指标。 最终，选择正确的指标有助于在出现问题时指导正确的操作，并且还可以让 SRE 团队对服务的健康状况充满信心。
本章描述了我们用来解决度量建模、度量选择和度量分析问题的方法。 大多数解释都没有示例，因此我们将使用其实现示例（搜索莎士比亚作品）中描述的莎士比亚服务来说明要点。
服务级别术语
许多读者可能熟悉 SLA 的概念，但术语 SLI 和 SLO 值得仔细定义，因为一般来说，术语 SLA 的含义过多，并且根据上下文具有多种含义。 为了清楚起见，我们希望将这些值分开。
指标
SLI 是一种服务水平指标，是对所提供服务水平的某个方面精心定义的定量衡量标准。
对于大多数服务，关键的 SLI 被认为是请求延迟 - 返回请求响应所需的时间。 其他常见的 SLI 包括错误率（通常表示为收到的所有请求的一部分）和系统吞吐量（通常以每秒请求数来衡量）。 测量结果通常是聚合的：首先收集原始数据，然后转换为变化率、平均值或百分位数。
理想情况下，SLI 直接测量感兴趣的服务水平，但有时只有相关指标可用于测量，因为原始指标难以获取或解释。 例如，客户端延迟通常是更合适的指标，但有时只能在服务器上测量延迟。
对 SRE 来说重要的另一种 SLI 是可用性，或者可以使用服务的时间部分。 通常定义为成功请求的比率，有时称为产量。 （生命周期——数据长期保留的可能性——对于数据存储系统也很重要。）虽然不可能实现 100% 的可用性，但接近 100% 的可用性通常是可以实现的；可用性值表示为“99”的数量 » 可用性百分比。 例如，99,999% 和 2% 可用性可能被标记为“5 个 99,95”和“XNUMX 个 XNUMX”。 Google Compute Engine 当前规定的可用性目标是“三个半九”或 XNUMX%。
目标
SLO 是服务级别目标：由 SLI 衡量的服务级别的目标值或值范围。 SLO 的正常值为“SLI ≤ 目标”或“下限 ≤ SLI ≤ 上限”。 例如，我们可能决定通过将 SLO 设置为小于 100 毫秒的平均搜索查询延迟来“快速”返回莎士比亚搜索结果。
选择正确的 SLO 是一个复杂的过程。 首先，您不能总是选择特定值。 对于对您的服务的外部传入 HTTP 请求，每秒查询 (QPS) 指标主要由用户访问您的服务的愿望决定，您无法为此设置 SLO。
另一方面，您可以说您希望每个请求的平均延迟小于 100 毫秒。 设置这样的目标可能会迫使您以低延迟编写前端或购买提供此类延迟的设备。 （100毫秒显然是一个任意数字，但最好有更低的延迟数字。有证据表明，快的速度比慢的速度更好，并且处理用户请求的延迟高于特定值实际上会迫使人们远离来自您的服务。）
同样，这比乍一看更加模糊：您不应该将 QPS 完全排除在计算之外。 事实上，QPS 和延迟密切相关：较高的 QPS 往往会导致较高的延迟，并且当服务达到某个负载阈值时，性能通常会急剧下降。
选择和发布 SLO 会设定用户对服务如何工作的期望。 此策略可以减少对服务所有者的毫无根据的投诉，例如性能缓慢。 如果没有明确的 SLO，用户通常会创建自己对所需性能的期望，这可能与设计和管理服务的人员的意见无关。 当用户错误地认为服务比实际更容易访问时，这种情况可能会导致对服务的期望过高；当用户认为系统不如实际可靠时，会导致不信任。
协议
服务级别协议是与用户签订的显式或隐式合同，其中包括满足（或不满足）其所包含的 SLO 的后果。 当后果是财务方面的（折扣或罚款）时，最容易被识别，但它们也可以采取其他形式。 讨论 SLO 和 SLA 之间差异的一个简单方法是问“如果不满足 SLO 会发生什么？” 如果没有明显的后果，您几乎肯定会考虑 SLO。
SRE 通常不参与创建 SLA，因为 SLA 与业务和产品决策密切相关。 然而，SRE 参与帮助减轻失败的 SLO 的后果。 它们还可以帮助确定 SLI：显然，协议中必须有一种客观的方法来衡量 SLO，否则就会出现分歧。
Google 搜索是没有公共 SLA 的重要服务的一个示例：我们希望每个人都尽可能高效地使用搜索，但我们尚未与全世界签署合同。 然而，如果搜索不可用，仍然会产生后果 - 不可用会导致我们的声誉下降以及广告收入减少。 许多其他 Google 服务（例如 Google for Work）与用户都有明确的服务级别协议。 无论特定服务是否具有 SLA，定义 SLI 和 SLO 并使用它们来管理服务都很重要。
这么多理论 - 现在来体验。
实践中的指标
鉴于我们已经得出结论，选择适当的指标来衡量服务水平非常重要，那么您现在如何知道哪些指标对于服务或系统很重要？
您和您的用户关心什么？
您无需将每个指标都用作可在监控系统中跟踪的 SLI； 了解用户想要从系统中获得什么将有助于您选择多个指标。 选择过多的指标会导致难以关注重要的指标，而选择较少的指标则会导致系统的大部分内容无人关注。 我们通常使用几个关键指标来评估和了解系统的健康状况。
服务通常可以根据与其相关的 SLI 分为几个部分：
- 自定义前端系统，例如我们示例中莎士比亚服务的搜索界面。 它们必须可用、没有延迟并且有足够的带宽。 因此，可以提出问题：我们可以回应该请求吗？ 响应请求需要多长时间？ 可以处理多少个请求？
- 存储系统。 他们看重低响应延迟、可用性和耐用性。 相关问题：读取或写入数据需要多长时间？ 我们可以根据要求访问数据吗？ 当我们需要时，数据是否可用？ 有关这些问题的详细讨论，请参阅第 26 章数据完整性：所读即所写。
- 数据处理管道等大数据系统依赖于吞吐量和查询处理延迟。 相关问题：处理了多少数据？ 数据从收到请求到发出响应需要多长时间？ （系统的某些部分也可能在某些阶段出现延迟。）
指标收集
许多服务水平指标最自然地在服务器端收集，使用 Borgmon 等监控系统（见下文）。 ）或 Prometheus，或者只是定期分析日志，识别状态为 500 的 HTTP 响应。但是，有些系统应该配备客户端指标收集，因为缺乏客户端监控可能会导致遗漏一些影响性能的问题。用户，但不影响服务器端指标。 例如，关注莎士比亚搜索测试应用程序的后端响应延迟可能会因 JavaScript 问题而导致用户端出现延迟：在这种情况下，测量浏览器处理页面所需的时间是一个更好的指标。
聚合
为了简单和易于使用，我们经常汇总原始测量结果。 这必须仔细完成。
有些指标看起来很简单，例如每秒的请求数，但即使这种看似简单的测量也会随着时间的推移隐式地聚合数据。 测量值是每秒专门接收一次还是测量值是每分钟请求数的平均值？ 后一个选项可以隐藏大量仅持续几秒钟的瞬时请求。 考虑一个每秒处理 200 个请求的系统，其中偶数个请求，其余时间为 0。 每秒 100 个请求的平均值形式的常量和两倍瞬时负载不是一回事。 同样，平均查询延迟可能看起来很有吸引力，但它隐藏了一个重要的细节：大多数查询可能很快，但也有许多查询很慢。
大多数指标最好被视为分布而不是平均值。 例如，对于 SLI 延迟，有些请求会很快得到处理，而有些请求总是需要更长的时间，有时甚至更长。 简单的平均值可以隐藏这些长时间的延迟。 该图显示了一个示例：虽然一个典型的请求需要大约 50 毫秒来处理，但 5% 的请求慢了 20 倍！ 仅基于平均延迟的监视和警报不会显示全天行为的变化，而实际上某些请求的处理时间（最上面一行）有明显的变化。
50、85、95 和 99 个百分点的系统延迟。 Y 轴采用对数格式。
使用百分位数作为指标可以让您了解分布的形状及其特征：高百分位数水平（例如 99 或 99,9）显示最差值，而 50 百分位数（也称为中位数）显示最常见的状态指标。 响应时间离散度越大，长时间运行的请求对用户体验的影响就越大。 在高负载和存在队列的情况下效果会增强。 用户体验研究表明，人们通常更喜欢响应时间方差较大的较慢系统，因此一些 SRE 团队仅关注高百分位数分数，因为如果某个指标在 99,9 百分位数处的行为良好，则大多数用户不会遇到问题。
统计误差注意事项
我们通常更喜欢使用百分位数而不是一组值的平均值（算术平均值）。 这使我们能够考虑更分散的值，这些值通常具有与平均值显着不同（且更有趣）的特征。 由于计算系统的人为特性，指标值常常存在偏差，例如，任何请求都无法在小于 0 毫秒的时间内收到响应，超时 1000 毫秒意味着无法成功响应大于该值的值比超时。 因此，我们不能接受平均值和中位数可以相同或接近！
如果没有事先测试，并且除非某些标准假设和近似成立，否则我们会小心不要得出数据呈正态分布的结论。 如果分布不符合预期，则修复问题的自动化过程（例如，当它看到异常值时，它会以较高的请求处理延迟重新启动服务器）可能会执行得太频繁或不够频繁（这两者都不是非常好）。
标准化指标
我们建议标准化 SLI 的一般特性，这样您就不必每次都对它们进行推测。 任何满足标准模式的功能都可能被排除在单个 SLI 的规范之外，例如：
- 聚合间隔：“平均超过 1 分钟”
- 聚合区域：“集群中的所有任务”
- 测量频率：“每 10 秒”
- 包含哪些请求：“来自黑盒监控作业的 HTTP GET”
- 数据如何获取：“感谢我们在服务器上测得的监控”
- 数据访问延迟：“到最后一个字节的时间”
为了节省精力，为每个常用指标创建一组可重用的 SLI 模板； 它们还使每个人都更容易理解某个 SLI 的含义。
实践中的目标
首先思考（或找出！）您的用户关心什么，而不是您可以衡量的内容。 通常，用户关心的内容很难或无法衡量，因此您最终会更接近他们的需求。 但是，如果您只是从易于衡量的内容开始，最终会得到不太有用的 SLO。 因此，我们有时发现，首先确定预期目标，然后使用具体指标，比选择指标然后实现目标效果更好。
定义目标
为了最大程度地清晰起见，应定义 SLO 的测量方式及其有效条件。 例如，我们可以说以下内容（第二行与第一行相同，但使用 SLI 默认值）：
- 99%（平均超过 1 分钟）的 Get RPC 调用将在 100 毫秒内完成（在所有后端服务器上测量）。
- 99% 的 Get RPC 调用将在 100 毫秒内完成。
如果性能曲线的形状很重要，您可以指定多个 SLO：
- 90% 的 Get RPC 调用在 1 毫秒内完成。
- 99% 的 Get RPC 调用在 10 毫秒内完成。
- 99.9% 的 Get RPC 调用在 100 毫秒内完成。
如果您的用户生成异构工作负载：批量处理（吞吐量很重要）和交互式处理（延迟很重要），则可能值得为每个负载类定义单独的目标：
- 95% 的客户请求需要吞吐量。 设置执行的 RPC 调用的计数 <1 秒。
- 99% 的客户关心延迟。 设置流量 <1 KB 且运行时间 <10 毫秒的 RPC 调用计数。
坚持 100% 满足 SLO 是不现实且不可取的：这会降低引入新功能和部署的速度，并且需要昂贵的解决方案。 相反，最好允许错误预算（允许的系统停机时间的百分比）并每天或每周监控该值。 高级管理层可能需要每月或每季度进行评估。 （错误预算只是一个 SLO，用于与另一个 SLO 进行比较。）
SLO 违规的百分比可以与错误预算进行比较（参见第 3 章和第 XNUMX 章） ），并将差值用作决定何时部署新版本的流程的输入。
选择目标值
选择规划值 (SLO) 并不是纯粹的技术活动，因为产品和业务利益必须反映在所选的 SLI、SLO（以及可能的 SLA）中。 同样，可能需要就人员配备、上市时间、设备可用性和融资等问题交换信息。 SRE 应该成为这种对话的一部分，并帮助了解不同选项的风险和可行性。 我们提出了一些可能有助于确保更富有成效的讨论的问题：
不要根据当前表现来选择目标。
虽然了解系统的优势和局限性很重要，但不经过推理就调整指标可能会妨碍您维护系统：需要付出巨大的努力才能实现不进行重大重新设计就无法实现的目标。
把事情简单化
复杂的 SLI 计算可能会隐藏系统性能的变化，并使查找问题原因变得更加困难。
避免绝对化
虽然拥有一个能够处理无限增长的负载而不增加延迟的系统很诱人，但这种要求是不现实的。 一个接近这种理想的系统可能需要大量的时间来设计和构建，操作起来会很昂贵，而且对于那些愿意做更少的事情的用户来说，它的期望太高了。
使用尽可能少的 SLO
选择足够数量的SLO以确保系统属性的良好覆盖。 保护您选择的 SLO：如果您永远无法通过指定特定的 SLO 来赢得有关优先级的争论，那么可能不值得考虑该 SLO。 然而，并非所有系统属性都适合 SLO：很难使用 SLO 来计算用户满意度。
不要追求完美
随着您对系统在负载下的行为有了更多了解，您始终可以不断完善 SLO 的定义和目标。 最好从一个浮动目标开始，随着时间的推移不断完善，而不是选择一个过于严格的目标，当你发现它无法实现时就必须放松。
SLO 可以而且应该成为 SRE 和产品开发人员优先工作的关键驱动因素，因为它们反映了对用户的关注。 好的 SLO 对于开发团队来说是一个有用的执行工具。 但是，如果团队为实现过于激进的 SLO 付出了巨大的努力，那么设计不当的 SLO 可能会导致工作浪费；如果 SLO 太低，则可能会导致产品很差。 SLO 是一个强大的杠杆，明智地使用它。
控制您的测量
SLI 和 SLO 是用于管理系统的关键元素：
- 监控和测量 SLI 系统。
- 比较 SLI 和 SLO 并决定是否需要采取措施。
- 如果需要采取行动，请弄清楚需要采取什么措施才能实现目标。
- 完成这个动作。
例如，如果步骤 2 显示请求超时，并且如果不采取任何措施，将在几个小时内破坏 SLO，则步骤 3 可能涉及测试服务器受 CPU 限制的假设，并且添加更多服务器将分配负载。 如果没有 SLO，您将不知道是否（或何时）采取行动。
设置 SLO - 然后将设置用户期望
发布 SLO 设置用户对系统行为的期望。 用户（和潜在用户）通常想知道对服务有何期望，以了解该服务是否适合使用。 例如，想要使用照片共享网站的人们可能希望避免使用承诺长寿和低成本的服务，以换取稍低的可用性，即使相同的服务可能非常适合档案记录管理系统。
要为用户设定切合实际的期望，请使用以下一种或两种策略：
- 保持安全边际。 使用比向用户公布的更严格的内部 SLO。 这将使您有机会在问题变得明显之前对其做出反应。 SLO 缓冲区还允许您在安装影响系统性能的版本时拥有安全裕度，并确保系统易于维护，而不必因停机而让用户感到沮丧。
- 不要超出用户的期望。 用户基于您提供的内容，而不是您所说的内容。 如果您的服务的实际性能比规定的 SLO 好得多，用户将依赖当前的性能。 您可以通过有意关闭系统或限制轻负载下的性能来避免过度依赖。
了解系统满足期望的程度有助于决定是否投资于加速系统并使其更易于访问和恢复。 或者，如果服务表现太好，则应将一些员工时间花在其他优先事项上，例如偿还技术债务、添加新功能或推出新产品。
实践中的协议
创建 SLA 需要业务和法律团队定义违反 SLA 的后果和处罚。 SRE 的作用是帮助他们了解在满足 SLA 中包含的 SLO 时可能遇到的挑战。 大多数创建 SLO 的建议也适用于 SLA。 在向用户承诺的内容上保持保守是明智的，因为您拥有的内容越多，更改或删除看似不合理或难以满足的 SLA 就越困难。
感谢您将翻译读到最后。 订阅我的关于监控的电报频道 и .
来源： habr.com