SRE（站点可靠性工程）-一种确保Web项目可用性的方法。 它被认为是DevOps的框架，并告诉您如何成功应用DevOps实践。 本文是Google 网站可靠性工程 的服务水平目标第4章的译文。 我自己准备了此翻译，并依靠自己的经验来了解监视过程。 在电报频道monitorim_it和哈布雷的最后一篇文章中，我还出版了同一本书中有关监视分布式系统的第6章的译文。

由猫翻译。 祝您阅读愉快！

如果不了解哪些指标真正重要以及如何衡量和评估它们，就不可能管理服务。 为此，我们定义并向用户提供一定级别的服务，无论他们使用我们的内部API之一还是公共产品。

我们使用直觉和经验，并认识到用户希望对服务水平指标（SLI），服务水平目标（SLO）和服务水平协议（SLA）有所了解。 这些度量描述了我们要控制的主要指标，如果无法提供预期的服务质量，我们将做出响应。 最终，选择正确的指标有助于在出现问题时管理正确的措施，还可以使SRE团队对服务的运行状况充满信心。

本章介绍了我们用于处理度量标准建模，度量标准选择和度量标准分析问题的方法。 大多数解释都是没有示例的，因此我们将使用其实现示例（搜索莎士比亚作品）中描述的莎士比亚服务来说明要点。

服务水平术语

许多读者可能熟悉SLA的概念，但是术语SLI和SLO应该仔细定义，因为通常术语SLA是重载的，并且根据上下文具有多种含义。 为了清楚起见，我们想将这些值分开。

指标

SLI是服务水平的指标-对所提供服务水平的一个方面进行仔细量化的度量。

对于大多数服务，请求中的延迟被视为关键SLI-要求多少时间才能返回对请求的响应。 其他常见的SLI包括错误率（通常表示为收到的所有请求的一部分）和系统吞吐量（通常以每秒请求数衡量）。 度量通常是汇总的：首先收集原始数据，然后将其转换为变化率，平均值或百分位数。

理想情况下，SLI直接测量感兴趣的服务水平，但有时仅相关的度量标准可用于测量，因为原始度量很难获得或解释。 例如，客户端延迟通常是更合适的指标，但是碰巧只能在服务器上测量延迟。

对于SRE重要的另一种SLI类型是可以使用服务的可用性或部分时间。 它通常定义为成功请求的百分比，有时也称为生成。 （预期寿命-数据长时间存储的可能性对数据存储系统也很重要。）尽管可访问性不可能100％，但通常可访问性接近100％，可访问性值表示为数字“九” »可用性百分比。 例如，可用性99％和99.999％可以被称为“ 2个9”和“ 5个9”。 目前，Google Compute Engine的可访问性目标是“三个半九”，即99.95％。

目标

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：我们希望每个人都尽可能有效地使用Search，但我们尚未与全世界签订合同。 但是，如果无法进行搜索，仍然会有后果-无法访问会导致我们的声誉下降，以及广告收入下降。 许多其他Google服务（例如Google for Work）都与用户签订了明确的服务水平协议。 无论特定服务是否具有SLA，确定SLI和SLO并使用它们来管理服务都是很重要的。

如此多的理论-现在可以体验。

实践指标

既然我们得出结论，选择合适的指标来衡量服务水平很重要，那么您现在如何知道哪些指标与服务或系统相关？

您和您的用户关心的是什么

您无需将每个指标都用作SLI，您可以在监控系统中对其进行跟踪。 了解用户希望从系统中获得什么，将帮助您选择一些指标。 选择太多指标使您难以关注重要指标，而选择太多指标则会使系统的重要部分无人值守。 通常，我们使用几个关键指标来评估和了解系统状态。

通常，根据SLI，服务可以分为几个与之相关的部分：

• 定制的前端系统，例如我们示例中的莎士比亚服务搜索界面。 它们应该是可访问的，不应延迟并且具有足够的带宽。 因此，您可以提出问题：我们可以回答请求吗？ 回答请求花了多长时间？ 可以处理多少个请求？
• 存储系统。 低延迟，可用性和耐用性对他们很重要。 相关问题：读取或写入数据需要多长时间？ 我们可以按需访问数据吗？ 在我们需要数据时可用吗？ 请参阅第26章“数据完整性”：对于这些问题的详细讨论，您所读的就是您写下的内容。
• 大数据系统（例如数据处理管道）取决于请求处理的吞吐量和延迟。 相关问题：处理了多少数据？ 数据从接收请求到发出响应需要多长时间？ （系统的某些部分在某些阶段也可能会有延迟。）

指标收集

最自然的是，使用诸如Borgmon（请参见第10章“时间序列警报实践” ）或Prometheus之类的监视系统，在服务器端收集许多服务级别指标，或者只是定期分析日志，以显示状态为500的HTTP响应。某些系统应配备客户端度量收集，因为缺乏客户端监视可能会导致丢失一些影响用户但不影响服务器度量的问题。 例如，由于JavaScript问题，关注测试应用程序后端的延迟响应来搜索莎士比亚的作品可能会导致在用户端处理请求的延迟：在这种情况下，测量页面在浏览器中处理所需的时间是最好的指标。

汇总

为了简化和易于使用，我们经常汇总原始尺寸。 这必须谨慎进行。

有些指标看起来很简单，例如每秒的查询数量，但是即使如此，显而易见的直接测量也隐含了一段时间内的数据聚合。 是每秒专门获取一次测量结果，还是在每分钟的查询数量中求平均值？ 后一个选项可能会隐藏大量瞬时请求，这些请求仅存储几秒钟。 考虑一个系统每秒处理200个请求，偶数个请求，其余时间为0个。 以每秒100个请求的平均值和两倍的即时负载的形式存在的常数不是一回事。 同样，平均请求等待时间可能看起来很吸引人，但它隐藏了一个重要的细节：大多数请求可能很快，但是许多请求却很慢。

最好将大多数指标视为分布而不是平均值。 例如，对于SLI延迟，某些请求将被快速处理，而某些请求将始终花费更长的时间，有时甚至更长。 一个简单的平均值可以掩盖这些漫长的延迟。 该图显示了一个示例：尽管典型请求的处理时间约为50毫秒，但5％的请求速度慢了20倍！ 当某些请求的处理时间实际上发生明显变化时，仅基于平均延迟的监视和警报不会显示白天的行为变化（顶行）。


50、85、95和99％的系统延迟。 Y轴为对数格式。

使用百分位数作为指标可让您查看分布的形状及其特征：高百分位数（例如99或99.9）显示最差的值，而在50％百分位数（也称为中位数）时，您可以看到度量标准的最频繁状态。 响应时间的差异越大，长期查询对用户体验的影响就越大。 在存在队列的情况下，在高负载下效果会得到增强。 用户体验研究表明，人们通常更喜欢速度较慢，响应时间分散性较高的系统，因此，如果假设99.9％的度量标准行为良好，那么大多数用户将不会体验到，因此，一些SRE团队只专注于高百分比值问题。

关于统计错误的注意事项

通常，我们更喜欢使用百分位数，而不是使用一组平均值（算术平均值）。 这使我们可以考虑更多分散的值，这些值通常具有比平均值明显不同（且更有趣）的特征。 由于计算系统的人为特性，度量值通常会失真，例如，没有请求可以在不到0 ms的时间内接收到响应，并且1000 ms的超时意味着没有超过超时值的成功响应。 结果，我们不能接受均值和中位数可以相同或彼此接近！

如果没有初步验证，并且如果不满足某些标准假设和近似值，我们将尽量不得出结论，即我们的数据呈正态分布。 如果分发不符合预期，则解决该问题的自动化流程（例如，当发现异常值超出限制值时，它将以高延迟重启服务器以处理请求）可能过于频繁或不够频繁（这两个选项都不是很好）。

指标标准化

我们建议标准化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 ms的RPC调用计数。

坚持要在100％的情况下执行SLO是不现实和不希望的：这会减慢引入新功能和部署的速度，并需要昂贵的解决方案。 取而代之的是，最好允许预算错误-系统停机时间的一小部分，并每天或每周监视此值。 , . ( — SLO SLO).

SLO (. 3 « » ), , , .

(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 , . SLO ( ) .

SLO —
SLO . ( ) , , , . , , - , , , .

, :

• . SLO, . , . SLO , .
• . , , . , SLO, . , .

, , , . , , , , .

SLA , - . SRE , SLO, SLA. SLO SLA. , , , SLA, .

, . - monitorim_it .