第三章 SLO工程案例学习

作者：Ben McCormack (Evernote)，William Bonnell (The Home Depot)，Garrett Plasky (Evernote)，Alex Hidalgo，Betsy Beyer和Dave Rensin
翻译：樊帅宇
校验：妙晓光 王运祥 王文勤 徐梦茹 齐凯华 郭晓东 张翔

---

尽管SRE的许多原则都是在Google内部形成的，但它的原则早已存在于Google之外。许多Google SRE的标准已被业内多个组织实践应用。

SLO是SRE模型的基础。自从我们组建了客户可靠性工程（CRE）团队——这是一组帮助Google Cloud Platform（GCP）客户构建更可靠的服务的经验丰富的SRE——几乎与每个客户交互都以SLO开始以SLO结束。

我们在这里介绍了两个不同行业的公司事迹，概述了他们在与Google CRE团队合作时采纳SLO和基于错误预算的方法的过程。有关SLO和错误预算的讨论，请参阅本书的第2章和第一本书的第3章。

Evernote的SLO故事

Evernote是一款跨平台的APP，可帮助个人和团队创建、整合和共享信息。在全球拥有超过2.2亿用户，我们在平台内存储了超过120亿条信息——包括文本笔记、文件和附件/图像。在后台，Evernote服务由750个以上的MySQL实例支持。

我们向Evernote引入了SLO的概念，并将其作为更广泛的技术改造的一部分，旨在提高工程速度，同时保持服务质量。我们的目标包括：

• 将工程重点从数据中心中冗余的繁重工作转移到客户实际关心的产品工程工作上。为此，我们停止运行物理数据中心并转移到公有云。
• 调整运维和软件工程师的工作模式，旨在保持整体服务质量的同时提高变更速度。
• 改进我们对SLA的看法，以确保我们更加关注故障对庞大的客户群所造成的的影响。

这些目标对许多行业的组织而言可能都很熟悉。虽然没有一种方法可以全面实现这些类型的变更，但希望我们分享的经验可以为面临类似挑战的人提供有价值的参考意见。

为什么Evernote采用SRE模型？

过渡开始阶段的Evernote的特点是传统的运维和开发分离：运维团队维护生产环境的稳定性，而开发团队的任务是为客户开发新的产品功能。这些目标通常是冲突的：开发团队 感觉被繁琐的流程所束缚，而运维团队又会因新代码在生产环境中引入新的问题变得不满。 当我们在这两个目标之间不断动摇时，运维和开发团队之间蔓延了一种不满和紧张的关系。我们希望达到一个双方都满意的节点，更好地平衡所涉及团队的不同需求。

在五年多的时间里，我们尝试了各种方式解决这种传统二分法中的差距。在尝试了“你编码，你运行”的开发模式，以及“你编码，我们为你运行”的运维模式之后，我们转向了以SLO为中心的SRE方法。

那么是什么促使Evernote向这个方向发展呢？

在Evernote，我们将运维和开发的核心目标视为工程师专业化的独立发展方向。一个方向关注的是近乎7*24小时地持续为客户提供服务。另一个关注的是服务的扩展和发展，以满足客户未来的需求。近年来，这两个方向已经越来越接近，例如SRE和DevOps强调将软件开发应用于运维。（数据中心自动化和公有云的发展进一步推动了这种融合，这两者都为我们提供了一个可以完全由软件控制的数据中心。）另一方面，全栈所有权和持续部署也越来越多地应用于软件开发。

SRE模型完全接受并包容了运维和开发间的差异，同时鼓励团队朝着共同的目标努力。它并不试图将运维工程师转变为应用程序开发人员，反之亦然。相反，它给出了一个共同的参考框架。根据我们的经验，由于使用错误预算/SLO方法的两个团队在交流时很少带着主观感情，所以在面对同样的情况时通常会做出类似的决定。

SLO简介：正在进行的旅程

旅程的第一步是从物理数据中心迁移到Google云平台。当Evernote服务在GCP上稳定运行后，我们就引入了SLO。我们的目标有两个：

• 确保所有团队都在Evernote SLO的新框架内工作。
• 将Evernote的SLO纳入我们与Google 云团队的合作中，他们现在负责我们的底层基础架构。由于在整体模型中加入了新的合作伙伴，因此我们需要确保迁移到GCP不会影响我们对用户的承诺。

在使用SLO约9个月后，Evernote已经开始实践使用其SLO的第3版了！

在深入了解SLO的技术细节之前，要先从客户的角度开始提问： 你可以提供哪些承诺？与大多数服务类似，Evernote具有许多功能和选项，用户可以通过各种创造性方式使用这些功能和选项。我们希望在一开始就关注最重要和最常见的客户需求：Evernote服务的可用性，以便用户能够访问和同步多个客户端的内容。我们的SLO之旅从这个目标开始。通过关注服务正常运行时间， 我们完成了接入SLO的第一步。使用这种方法，我们可以清楚地表达我们衡量的内容以及衡量方法。

我们的第一份SLO文件包含以下内容：

SLO的定义

这是一个（服务、系统）可用时间的计算方法：为某些服务或者是方法，在月级别的统计周期内设定了99.95%的可用性。这个数据是我们基于内部客户支持团队、产品团队，尤其重要的是用户共同讨论得来的。我们特意选择将SLO和日历月而不是与滚动的时期进行关联，就是为了使我们在进行服务复查时保持专注有序。

度量什么，如何度量

度量什么

我们指定了一个服务终点，我们可以调用它来测试服务是否按预期运行。在我们的例子中，我们在服务中内置了一个状态页面，它可以运行我们的大部分堆栈并返回200状态代码（如果一切正常）。

如何度量

我们想要一个定期调用状态页面的探测器。我们希望探测器完全位于我们的环境之外并独立于我们的环境，因此我们可以测试所有组件，包括负载均衡。我们的目标是确保我们可以统计到GCP服务以及evernote应用任何、所有异常。但是，我们不希望随机网络问题触发误报。我们选择使用专门建立和运行此类探测器的第三方公司。我们选择了Pingdom，但市场上还有很多其他产品。我们按如下方式进行衡量：

如何从监控数据计算SLO

最后，我们仔细记录了我们如何根据从Pingdom收到的原始数据计算SLO。例如，我们指定了如何考虑维护窗口：我们无法假设我们所有的数亿用户都知道我们发布的维护窗口。因此，不知情的用户会将这些窗口视为通用和无法解释的停机时间，因此我们的SLO计算将维护视为停机时间。

一旦我们定义了SLO，我们就必须使它发挥最大的价值。 我们希望SLO能够推动软件和运维方面的变革，让我们的客户更快乐并让他们满意。 怎么做到最好？

• 探测频率：我们每分钟轮询一次前端节点。
• 探测器的位置：此设置是可配置的; 我们目前在北美和欧洲使用多个探测器
• “down”的定义：如果一个探测器检测结果为失败，那么这个节点会被标记为疑似宕机，然后第二个基于不同地理位置独立部署的探测机会进行第二次确认。如果第二次检查同样也失败了，出于计算SLO的目的这个节点会被标记为宕机。只要探测请求持续显示错误，那么这个节点会被持续标记为宕机。

我们用SLO中有关错误预算的思维为方法来分配下一步工作的需要的资源。举例来说，如果我们没有达成上个月的SLO，这会促使我们高优（对系统、服务）进行目标明确的加固、改进和修复。我们制定最简原则：evernote团队以及google团队共同进行月级别 的SLO目标复查。在这个会议上，我们复核SLO的表现并对所有服务中断行为进行深入研究。基于针对上个月的上述分析而不是根因分析，我们制定了一些改进措施。

在整个过程中，我们的指导原则是“过犹不及”。即使在SLO还没有达到完美的时候，它也足以在此期间指导我们进行改进。一个“完美”的SLO应该可以衡量每一个与我们服务有关的潜在用户交互设计并且解释所有的边界行为。虽然字面上看起来这是个好主意，但是如果要实现起来却要花费数月的时间去改进服务（如果真的可以这到完美）。相反，我们选择了一个初始SLO，涵盖了大多数（但不是全部）用户交互，这是服务质量的良好代理。

自从我们开始执行SLO以来，根据从服务复盘以及响应客户有感的宕机事件中得到的启示，我们对SLO做了两次修改。因为我们一开始就没有追求完美SLO，为了适应业务的发展我们乐于做出改变。除了evernote团队与google进行月级别SLO复盘之外，我们也设定了一个6个月的SLO复盘周期，这个周期可以使SLO的维护达到一个平衡：既不会频繁更新，也不会使之过时。在不断修订SLO的过程中，我们也意识到了，期望的衡量标准和可以达到的衡量标准之间的平衡是很重要的。

自引入SLO以来，我们的运维和开发团队之间的关系有了微妙但显着的改善。现在团队对成功有了共同的衡量标准，那就是：取消对服务质量的人为解释使两个团队达成了共同的观点和标准。在此我们试着举一个例子，2017年当我们不得不在短期内推动多个版本的发布任务时，SLO为我们提供了共同基础。当我们发现一个复杂的bug时，产品开发团队要求我们将常规的周级别发布任务分配到多个独立的发布窗口，每个发布窗口都会对客户产生潜在的影响。通过对问题进行有针对性的SLO计算以及消除方案中的人为主观因素，我们可以更好的量化客户感受并且通过把发布窗口由5个降为2个从而达到了减少了客户痛点的目的。

打破客户与云服务商之间的隔阂

介于客户和云服务商之间的隔阂看起来是在所难免的。虽然google已经为运行evernote的GCP平台设定了SLO和SLA（服务等级协议），但是evernote有自己的SLO和SLA。期望两个技术团队会将彼此的SLA告知对方看起来是不现实的。

evernote不希望存在这样的隔阂。当然我们也可以基于自己的SLO和底层的GCP平台的SLA建立起隔离域，相反从一开始我们就希望google可以理解性能表现对我们来说是多重要以及为什么这么重要。我们期望google和我们在目标上达成一致，让两家公司把evernote在可靠性方向的成败当作共同的职责。为了实现这一目标，我们需要一种方法可以：

大多数服务商都为自己的云服务发布了SLO/SLAs。虽然服务运行在此框架下很重要，但这并不能全面的反映我们的服务在云服务商的环境中运行的状况。

例如，一个给定的云服务商可能在全球运行了数十万台虚拟机，他们为这些虚机的正常运行和可靠性负责。GCP承诺计算引擎（也就是虚机）可以达到99.95%的可靠性。即使当GCP SLO指标显示为绿色的时候（即可靠性高于99.95%），evernote的监控视图的表现可能完全不同：因为我们的虚机在GCP全球总量虚机中仅占有很小的比例，会使导致我们（服务所在）区域成为孤岛（或由于其他原因导致成为孤岛）的故障最终在全球级别的汇总中被忽略。

为了修正这样的情况，我们将我们的SLO和未达成SLO的实时性能与goolge进行共享。因此，Google CRE团队和Evernote团队基于同样的性能仪表盘展开合作。这看起来似乎是一个很简单的观点，但最终被证明是一种相当有效的、可以形成真正以客户为中心的工作方法。因此，google会向我们提供更明确的环境运行情况通知，而不是那种泛泛的“x服务当前运行缓慢”的通知。举例来说，除了那种泛泛的“今天GCP负载均衡环境运行缓慢”之外，我们还会被告知这个问题已经对evernote的SLO造成了5%的影响。这种关系也有助于google内部团队了解他们的行为和决策是如何影响用户的。

这种双向关系也为我们提供了一个非常有效的框架来应对重大事件。大多数情况下，P1-P5级别的工单和常规的支持渠道配合使用，产生了很好的效果，使我们能够提供稳定的服务，并与谷歌保持良好的合作关系。但众所周知，当你整个在线服务面临着拓展业务增长的压力的时候，P1级别的工单是不能满足要求的。

这时，我们与CRE团队共享的SLO和（合作）关系得以实现。我们达成共识，如果SLO影响足够高，双方都会将该问题视为P1级别进行特殊处理。这就意味着evernote和google的cre团队经常要快速组织起一个可以共享的沟通渠道。Google CRE团队监控（管理）我们共同定义和商定的SLO，使我们在优先级和恰当响应方面保持同步。

当前状态

• 协调目标
• 确保我们的合作伙伴（在本例中为Google）真正了解对我们重要的内容
• 分享成功和失败

在积极使用SLO大约九个月之后，Evernote已经在使用SLO实践的第三版了。下一个版本的SLO会以我们当前简单正常运行时间的SLO为基础进行改进。我们将关注单个API调用和客户端的指标/性能视图，以便更好地表示用户QoS。

通过提供标准定义的QoS测量方法，SLO使Evernote更关注我们的服务是如何运行的。我们内部或者和谷歌进行以数据为驱动的对话，了解服务中断的影响，这能够推动服务改进，最终建立更强大的支持团队，使客户更满意。

Home Depot的SLO故事

Home Depot（THD）是全球最大的家居装饰零售商：我们在北美拥有2,200多家商店，每家商店都拥有超过35,000种产品（网站上有超过150万种产品）。 我们的基础架构托管各种软件应用程序，支持了近400,000名员工每年处理超过15亿的客户交易。这些商店由全球供应链和每年访问量超过20亿次电子商务网站紧密组成。

最近为了提高我们软件开发的速度和质量，THD转向敏捷软件开发并改变了我们设计和管理软件的方式。我们从支持大型软件包开发的团队转变为小型独立的微服务架构开发团队。因此，我们的系统现在由一系列的不断变更的微服务组成, 这些微服务也是通过堆栈整合而成。

我们向微服务转变的过程中，全栈所有权获得了新的“自由和责任文化”的补充。这种方法使开发人员可以自由地在需要时推送代码，同时也使他们为他们对服务的操作负责。对于这种共同所有权工作模式，运维和开发团队需要达成一种共识，即促进责任制和减少复杂性：SLO。相互依赖的服务需要知道如下信息：

如果每项服务都能为这些问题提供明确的和一致的答案，那么团队就可以清楚地了解服务的依赖关系，从而达到更好地沟通，增强团队之间的信任和责任感。

SLO文化项目

在我们的服务模式开始转变之前，Home Depot没有SLO文化。监控工具和仪表盘特别多，但都分布在各处，并且不会随着时间的推移记录数据。我们并不总能查出服务中断的根因。我们通常从遇到的服务问题开始排查，直到我们发现问题为止，这浪费了无数个小时。如果服务需要计划停机时间，其依赖服务就会受不了。如果一个团队需要构建一个99.95%的服务，他们不确定有严格依赖的服务能否达到99.99%的标准。这些未知导致我们的软件开发团队和运维团队之间的疑惑和失望。

我们需要通过建立SLO的共同文化来解决这些问题。因此，需要一个影响人员、流程和技术的总体战略。 我们的努力跨越了四个方面：

内部名词规定：

在THD（Home Depot）公司内部定义SLOs。 来说明如何以一致的方式来进行度量。

福音主义

在整个公司传播这个词。

• 通过给销售提供培训资料，在公司进行路演、内部博客、宣传资料比如T恤和贴纸等方式，传播为什么SLO很重要。
• 争取一些早期采用者来实施SLO并向其他人展示其价值。
• 建立一个感兴趣的首字母缩略词（VALET;稍后讨论）以帮助传播这个想法。
• 创建培训计划（FiRE学院：可靠性工程基础），对开发人员进行培训使其了解SLO和其他可靠性概念。

自动化

为了降低指标收集的难度，用一个指标收集平台去自动收集生产环境中的服务的服务等级指标。这些SLI以后可以更容易地转换为SLO。

激励

为所有开发经理制定年度目标，为其服务设置和衡量SLO。

每个人达成共识很重要。我们还希望保持这个框架尽可能简单，以帮助这个想法更快地传播。为了开始，我们仔细研究了我们在各种服务中监控的指标，并发现了一些模式。每项服务都会监控某种形式的流量、延迟、错误和利用率指标，这些指标与Google SRE的四个黄金信号密切相关。此外，许多服务都可以从错误中明显监控正常运行时间或可用性。不幸的是，所有类别的指标都受到不一致的监控，命名不同或数据不足。

我们的服务都没有SLO。我们的生产系统与面向客户的SLO最接近的指标是支持票据。我们测量部署到我们商店的应用程序可靠性的主要（通常也是唯一）方式是跟踪内部支持台接收的支持呼叫数量。

我们的第一套SLO

我们不能对一个可度量系统的每个方面都创建SLOs，因此我们必须确定系统的哪些指标或SLIS应该具有SLOs。

API调用的可用性和延迟
我们决定对微服务之间的API调用设置可用性和延迟SLOs。例如，Cart微服务调用Inventory微服务。针对那些API调用，Inventory微服务发布了SLOs，Cart微服务（以及需要Inventory的其他微服务）可以获取这些SLOs并以此决定Inventory微服务是否能满足可靠性要求 基础设施利用/基础设施利用率。

基础设施利用率
THD团队通过不同的方式来衡量基础设施利用率，而最典型的衡量标准是分钟级别的实时基础设施利用率。我们基于某些原因并不会设置这种利用率SLOs。首先，微服务并非十分关注这个指标-只要服务可以承载流量，服务器正常运行、响应速度很快、不抛错误，且并不会耗尽容量，那么你的用户就不会真正关心利用率。此外，计划迁移服务到云端意味着资源利用率不是重点，这时我们要关注的是成本规划，而不是容量规划。（我们仍然需要监控利用率并执行容量规划，但不需要将其包括在我们的SLO框架内。）

流量
由于THD没有进行容量规划的传统，因此我们需要一种机制，该机制能让开发和运维团队就其服务可以承载的流量进行沟通。流量通常被定义为对服务的请求，但我们需要确定是否应该跟踪平均每秒请求数，每秒峰值请求数或报告时间段内的请求数。最终我们决定跟踪这三项，并给每项服务选择最合适的指标。我们讨论是否为流量设置SLO的原因在于这个指标是由用户行为决定的，而非我们可控的内部因素决定。我们要讨论是否为流量设置SLO，因为流量的衡量跟用户行为密切相关，我们可控的内部因素无法发挥决定作用。 最终我们认为，作为零售商，我们需要为应对黑色星期五这样的活动流量峰值增加服务的规模，并根据预期的峰值流量设置SLO。

延迟
我们给每个服务定义了延迟SLO并确定其最佳的衡量方式。这里我们只要求服务应该通过黑盒监控来补充我们常见的白盒性能监控，以捕获由网络或诸如缓存以及微服务外部代理失效等层面的问题。并且，我们认为，采用百分位数比算术平均值更合适。服务最少需要达到90％的目标，而面向用户的服务则最好达到95%或99%的目标。

错误
错误解释起来有点复杂。由于我们主要处理Web服务，因此我们必须将错误内容以及返回结果标准化。如果Web服务发生错误，我们自然会对HTTP响应代码进行
标准化：

• 在服务的返回内容中，不应该用2xx来标记错误; 相反，一个错误应该抛出4xx或5xx。
• 由服务端问题（如内存不足）引起的错误应该抛出5xx错误。
• 客户端错误（如发送错误格式的请求）应该抛出4xx错误.

一番考虑后，我们决定跟踪4xx和5xx错误，但仅使用5xx错误来设置SLOs。与定义其他相关SLO的方法类似，我们采用通用形式来定义错误SLO，以便不同环境中的不同应用都可以使用该SLO。例如，除HTTP错误外，定义一个批处理服务的错误，可能是该服务无法处理记录的个数。

工单
正如前面提到的，工单最初是我们评估大多数生产软件的主要方式。由于历史原因，在我们其他的SLOs中，我们决定继续跟踪工单。你可以将该指标视为类似于“软件操作级别”的指标。

VALET
我们将新的SLOs概括为一个更简易的缩略词：VALET。

容量（流量）

服务可以处理多少业务量？

可用性

需要的时候服务是否正在运行？

延迟

使用时服务是否快速响应？

错误

使用时服务是否会抛出错误？

工单

服务是否需要人为干预才能完成请求？

推广SLO

凭借这样一个易于记忆的缩略词，我们开始在企业内部推广SLOs：

• 为何SLOs如此重要
• SLOs是怎样与我们的“自由和责任”文化相契合的
• 应该衡量什么
• 如何处理结果

因为开发人员现在要负责维护他们自己的软件，因此他们需要建立SLOs以体现他们开发和维护软件可靠性的能力，针对面向用户的服务，他们需要同服务使用者和产品经理进行交流。然而，他们中多数人并不熟悉诸如SLAs和SLOs这样的概念，因此他们需要接受VALET框架方面的培训。

由于我们需要获得强有力的支持来推广SLOs，因此一开始我们可以面向高级领导者进行SLOs的推广讲解。然后逐个向开发团队讲述SLOs的价值观。我们鼓励团队从他们自定义的度量跟踪机制（通常是人为制定）转向VALET框架。为了保持这种推广态势，我们每周发送一份VALET格式的SLO报告给高层领导，这份报告结合了可靠性理念和从内部事件中吸取的经验。这也有助于构建业务指标，例如在VALET框架下，创建的采购订单（流量）或支付订单失败（错误）。

我们还以多种方式扩展了我们的推广渠道：

• 我们建立了一个内部WordPress网站来托管有关VALET和可靠性的博客，并将其链接到相关资源。
• 我们组织内部技术讲座（包括Google SRE演讲嘉宾），讨论了通用可靠性概念以及如何使用VALET进行度量。
• 我们开展了一系列VALET培训研讨会（之后将演变为FiRE学院），并向所有想参加的人开放，这些研讨会持续了好几个月。
• 我们甚至制作了VALET笔记本电脑贴纸和文化衫，用来支持全面的内部推广活动。
  很快，公司里的每个人都知道了VALET这一概念，并且我们的SLOs新文化开始在公司占据主流。对开发负责人来讲，实施SLO甚至已正式成为其年度绩效评估指标。虽然大约有50项服务正在按周级别获取并报告其SLOs，但我们会将这些指标存储在电子表格中。虽然VALET的思想已经非常流行，但为了让其更广泛地被接纳，我们仍然需要自动化技术来进行数据的收集。

自动化VALET数据收集

虽然我们的SLO文化现在有了强大的立足点，但自动化VALET数据收集将加速SLO的应用。

TPS报告
我们构建了一个框架来自动捕获部署到新GCP环境的任何服务的VALET数据。我们将此框架称为TPS报告，这是我们用于数量和性能测试的术语（每秒交易次数），当然，也是为了满足多个管理者想要查看这些数据的想法。 我们在GCP的BigQuery数据库平台之上构建了TPS Reports框架。我们的Web服务前端生成的所有日志都被输入BigQuery以供TPS Reports处理。当然也包括来自各种监控系统的指标，例如Stackdriver的可用性指标。

TPS报告将这些数据转换为任何人都可以查询的每小时VALET指标。新创建的服务自动注册到TPS报告中，因此可以立即查询。由于数据全部存储在BigQuery中，因此我们可以跨时间帧有效地报告VALET指标。我们使用此数据构建了各种自动报告和警报。 最有趣的集成是一个聊天机器人，让我们直接在商业聊天平台上报告服务的VALET。例如，任何服务都可以显示过去一小时的VALET，前一周的VALET，未达成SLO的服务以及聊天频道内的各种其他值得引起关注的数据。

VALET服务
我们的下一步是创建一个VALET应用程序来存储和报告SLO数据。因为SLO最适合用作趋势工具，所以该服务以每日、每周和每月粒度跟踪SLO。请注意，我们的SLO是一种趋势工具，我们可以将其用于错误预估，但不直接连接到我们的监控系统。相反，我们有各种不同的监控平台，每个平台都有自己的警报。这些监控系统每天汇总其SLO并发布到VALET服务以进行趋势分析。此设置的缺点是监控系统中设置的警报阈值未与SLO集成。 但是，我们可以根据需要灵活地更换监控系统。

预计需要将VALET与未在GCP中运行的其他应用程序集成，我们创建了一个VALET集成层，该层提供API来收集聚合的VALET数据以生成服务日报。TPS Reports是第一个与VALET服务集成的系统，我们最终集成了各种本地应用程序平台（占在VALET中注册的服务的一半以上）。

VALTE 仪表盘
VALET仪表板（如图3-1所示）是我们用于可视化和报告此数据的UI，并且相对简单。 它允许用户：

图3-1 VALET仪表盘图3-1 VALET仪表盘

• 注册新服务。 这通常意味着将服务分配给一个或多个URL，这些URL可能已经收集了VALET数据。
• 为五个VALET类别中的任何一个设置SLO目标。
• 在每个VALET类别下添加新的指标类型。 例如，一个服务采集99%的请求所用的延迟，而另一个服务采集90%的请求所用（或两者之间）的延迟。或者，后端处理系统可以跟踪每日总量（一天内创建的采购订单），而客户服务的前端可以跟踪每秒交易的峰值。

VALET仪表盘允许用户一次报告许多服务的SLO，并以多种方式对数据进行切片和切块。例如，团队可以查看过去一周未达到SLO的所有服务的统计信息。负责复盘服务性能的团队可以查看其所有服务及其所依赖的服务的延迟。VALET仪表盘将数据存储在一个简单的Cloud SQL数据库中，开发人员使用流行的商业报告工具来构建报告。

这些报告成为开发人员新的最佳实践的基础：定期对其服务进行SLO审核（通常是每周或每月）。基于这些，开发人员可以创建操作项以使服务回归SLO，或者可能按照需要调整不符合实际的SLO。

SLOs的扩散
一旦SLOs融入到组织的集体思想中，并且具备了有效的自动化技术和报表，那么新的SLOs就可以快速实施。在年初跟踪了约50项服务的SLOs之后，到今年年底我们正在跟踪800项服务的SLOs，每月约有50项新服务在VALET注册。

由于VALET允许我们在THD中推广SLO的应用，因此自动化开发这项工作是非常有意义的。但是，不具备这种自动化开发能力的公司也不用担心采用SLO会带来的麻烦。虽然自动化为THD提供了额外的收益，但一开始就编写SLO也收益颇多。

将VALET应用于批处理应用程序

当我们围绕SLO开发强大的报表时，我们发现了VALET的一些其他用途。 经过一些调整，批处理应用程序可以适用此框架，如下所示：

数量

已处理的记录数量

可用性

在一定时间内完成工作的频率（百分比）

等待时间

作业运行所需的时间

错误

程序运行失败的记录

工单

操作员必须手动修复数据和重新处理作业的次数

在测试中使用VALET

由于在发展SRE文化的同时，我们发现在临时环境中，VALET可以支持我们的破坏性测试（混沌工程）自动化。有了TPS Reports框架，我们就可以自动进行破坏性测试并记录对service’s VALET data造成的影响（希望没有影响）。

未来展望

通过800个（并且不断增长）服务来收集VALET数据，我们可以拥有大量有用的运营数据。我们对未来有几个期望。

既然我们正在有效地收集SLO，我们希望使用这些数据来采取行动。我们的下一步是类似于Google的错误预算文化，当服务不在SLO时，团队停止推送新功能（除了提高可靠性相关的）。为了满足业务增长的需求，需要平衡SLO报告的生成频率（周级别或月级别）和SLO标准的更新频率。和许多采用错误预算的公司一样，我们正在权衡滚动窗口与固定窗口的优缺点。

我们希望进一步优化VALET以跟踪详细的节点和服务的使用者。目前，即使特定服务具有多个节点，我们也只在整个服务中跟踪VALET。因此，很难区分不同的操作（例如，对目录的写入与对目录的读取；虽然我们对这些操作添加了单独的监控和报警，但不跟踪SLO）。同样，我们也很乐意为服务的不同消费者提供对应的VALET结果。

虽然我们目前在Web服务层跟踪延迟SLO，但我们还希望跟踪最终用户的延迟SLO。此度量将捕获网络延迟和CDN缓存等因素如何影响页面开始呈现和完成呈现所需的时间。

我们还想将VALET数据扩展到应用程序部署。具体来说，在将更改推广到下一个服务器、域或区域之前，我们希望自动化验证VALET是否在容差范围内。

我们已经开始收集有关服务依赖性的信息，并且制作了一个可视化图表原型，该图表显示了我们在调用树中未触及到VALET指标的位置。 新兴的网格服务平台将简化这种分析。

最后，我们坚信服务的SLO应该由服务的业务所有者（通常称为产品经理）根据其业务的重要性来设置。至少，我们希望业务所有者设置服务正常运行时间的最低要求，并将SLO用作产品管理和开发之间的共享目标。虽然技术人员发现VALET很直观，但对于产品经理来说，这个概念并不那么直观。我们正在努力使用与它们相关的术语来简化VALET的概念：我们既简化了正常运行时间的选择数量又提供了示例指标。我们还强调从一个级别转移到另一个级别所需的大量投入。以下是我们可能提供的简化VALET指标的示例：

• 99.5％：商店员工使用次数很少的应用程序或新服务。

• 99.9％：适用于THD的大多数非销售系统

• 99.95％：销售系统（或支持销售系统的服务）

• 99.99％：共享的基础设施服务

以业务术语来衡量指标并在产品和开发之间共享可见目标（SLO！），这种行为将大量减少公司常见的对可靠性的错误预期。

概要

向大公司介绍一个新流程，都需要一个好的策略、高管的支持、强大的传播、简单的采用模式以及最重要的耐心，更不用说是一个新文化了。像SLO这样的重大变革可能需要数年才能在公司中牢固地建立起来。我们想强调的是，Home Depot是一家传统企业;如果我们能够成功地引入这么大的变化，那么你也可以。你也不必一次完成这个任务。虽然我们逐步实施SLO，但制定全面的传播策略和明确的激励结构促进了快速转型：我们在不到一年的时间内获得了从0到800的SLO服务支持。

结论

SLO和错误预算为解决许多不同问题提供了强大的理论支持。这些来自Evernote和Home Depot的案例研究提供了非常真实的例子，说明如何实施SLO文化可以使产品开发和运维更紧密地结合在一起。这样做可以促进沟通并更好地为制定决策提供信息。它最终将为你的客户带来更好的体验 – 无论这些客户是内部、外部、人类还是其他服务。

这两个案例研究强调实现SLO文化是一个持续的过程，而不是一次性修复或解决方案。虽然它们共享哲学基础，但THD和Evernote的度量风格、SLIs、SLOs和实现细节明显不同。这两个案例都补充了谷歌对SLOs的看法，说明了SLO实现不一定是Google所特有的。正如这些公司为自己独特的环境量身定制SLO一样，其他公司和组织也可以这样做。