2019年1月21日
第16卷，第6期

重要的指标

每个SRE和产品负责人应该关心的关键但常被忽视的服务指标

Benjamin Treynor Sloss、Shylaja Nukala和Vivek Rau

站点可靠性工程（SRE）是一种软件工程专业，专注于大型系统的可靠性和可维护性。凭借在该领域的经验，谷歌发现了一些关键但常被忽视的指标，这些指标对于运行可靠的服务至关重要。

本文基于Ben Treynor在2017年谷歌云Next大会上的演讲⁷，针对产品开发和SRE团队、此类团队的经理以及任何关心Web产品或基础设施可靠性的人员，探讨了这些指标。为了进一步解释其产品可靠性方法，谷歌发布了站点可靠性工程：谷歌如何运行生产系统¹（以下简称SRE书籍）和站点可靠性工作手册：实施SRE的实用方法²（以下简称SRE工作手册）。

为什么指标重要

在提供服务时，最重要的选择之一是衡量哪些服务指标以及如何评估它们。伟大、良好和糟糕的指标以及指标阈值选择之间的差异，通常决定了一个服务是会以其卓越的性能让用户感到惊喜和愉悦，还是对大多数用户来说可以接受，还是会积极地赶走用户——无论该服务实际提供什么。

例如，测量Web或API服务器接收到的QPS（每秒查询数）并评估该指标是否表明良好的服务健康状况并不罕见，如果（a）该指标随时间变化的曲线具有平滑的正弦日变化曲线，没有意外的峰值或低谷，并且（b）曲线的峰值随时间上升，表明用户增长。然而，这是一个糟糕的指标选择——充其量它只会为运营商提供大规模问题的滞后指标。它错过了许多真实、常见的问题，包括部分不可达性、0.1-3%范围内的错误率、高延迟以及不良结果的时间间隔。

这些问题会导致用户不满意并放弃服务——然而，纵观这一切，QPS接收图仍然显示其令人愉悦的正弦曲线，并提供一切安好的舒缓感觉。关于QPS接收指标，最好的一点是它相对容易实现——即使这本身也是一个问题，因为它通常很早就被实现，因此取代了更复杂和有用的指标，而这些指标本可以为运营商提供关于服务的更准确和有用的数据。

以下是谷歌SRE团队为谷歌服务采用的指标类型。这些指标并非特别容易实现，可能需要更改服务才能正确地进行检测。然而，在谷歌，我们始终如一的经验是，每个实施这些指标的服务团队事后都对所做的努力感到满意。与构建和启动服务的总体工作相比，指标投入很小，而用户满意度和使用增长方面的及时回报相对于所需的努力来说是巨大的。我们相信您也会发现您的服务也是如此。

教训 1：衡量实际用户体验

SRE书籍强调，速度对用户很重要，正如谷歌关于用户在Web服务响应延迟时行为变化的研究所证明的那样。³ 当服务变得太慢时，用户开始脱离，当服务变得更慢时，用户就会离开。“速度很重要”是SRE在思考是什么让服务对用户有吸引力时应应用的一个良好公理。

一个很好的后续问题是，“速度对谁而言？” 工程师通常会考虑衡量服务器端的速度，因为检测服务器以导出所需的指标相对容易，并且标准监控工具旨在从仪表板中的服务器捕获此类指标，并通过警报突出显示异常情况。这种标准设置正在衡量的是用户请求进入数据中心的时间点与对该请求的响应离开数据中心的时间点之间的时间间隔。换句话说，捕获的指标是服务器端延迟。测量服务器端延迟是不够的，尽管它比完全不测量延迟要好。在解决更困难的测量客户端延迟问题时，测量和报告服务器端延迟可能是一个有用的权宜之计。

问题在于，用户对这个服务器端指标不感兴趣。用户关心的是应用程序在响应他们的操作时有多快或多慢，不幸的是，这与服务器端延迟的相关性可能很小。也许这些用户有一部廉价手机，使用缓慢的2G网络，位于远离您的服务器的国家/地区；如果您的产品不适用于他们，那么您构建出色功能的所有辛勤工作都将白费，因为用户会不满意并使用不同的产品。如果您仅测量服务器端延迟，问题将会更加复杂，因为您将完全不知道产品对用户来说很慢。即使您收到关于速度缓慢的轶事报告并尝试跟进，您也无法确定哪些用户子集正在经历速度缓慢以及何时经历速度缓慢。

为了衡量实际用户体验，您必须测量和记录客户端延迟。检测客户端代码以捕获此延迟指标，然后将客户端指标运回数据中心进行分析可能是一项艰苦的工作。处理断开的网络连接（通过存储数据并在稍后上传）的需求可能会使工作更加复杂。

尽管困难，客户端指标是必不可少的并且可以实现的。

对于浏览器应用程序，您可以编写额外的JavaScript，收集不同平台、不同国家/地区用户的这些统计信息，并将这些统计信息发送回服务器。对于胖客户端，路径更明显，但仍然重要的是测量从用户与客户端交互到交付响应的时间。无论哪种方式，检测用户体验所花费的精力仅占先前编写整个应用程序的精力的一小部分，而这种增量努力的回报很高。

以谷歌自身的历史为例，当Gmail推出时，大多数用户通过Web浏览器（而不是移动客户端）访问它，并且谷歌的Web客户端代码没有检测来捕获客户端延迟。因此，我们依赖服务器端延迟数据，响应时间似乎相当可以接受。当谷歌最终推出检测过的JavaScript客户端时，起初我们不相信它发回的数据——用户体验竟然如此糟糕，这似乎不可能。我们经历了一段时间的否认阶段，然后是愤怒，最终达到了讨价还价的阶段。⁴ 我们对Gmail服务器及其客户端的工作方式进行了一些重大更改，以改善我们的客户端延迟，回报是Gmail的增长在用户体验改善后出现了明显的拐点。我们监控仪表板中的长期趋势表明，用户对改进的产品体验做出了回应。对于编写和运行Gmail约百分之三的努力，Gmail的采用率和用户满意度大幅提高。

应用程序开发人员可以使用许多技术来改善客户端响应时间，并非所有技术都需要大量的工程投入。谷歌的PageSpeed项目旨在与世界分享公司在客户端响应优化方面的见解，并附带工具，帮助工程师将这些见解应用于他们自己的产品和网页。⁵ 一个明显的规则是尽可能缩短服务器响应时间。PageSpeed分析工具还推荐各种众所周知的客户端优化技术，包括静态内容压缩、使用预处理器通过删除不必要的和冗余的文本来“缩小”代码（HTML、CSS和JavaScript）、正确设置缓存控制标头、压缩或内联图像等。

总而言之，通过衡量用户在对您的产品执行操作后必须等待响应多长时间来衡量实际用户体验。即使这通常不容易，也要这样做。经验表明，这将是非常值得的努力。

教训 2：以第95和第99百分位数衡量速度

虽然“速度很重要”是思考用户（不）满意度的良好公理，但这仍然留下了一个关于如何最好地量化服务速度的开放性问题。换句话说，即使您理解并接受延迟指标（响应用户请求的时间）的值应足够低以使用户满意，您是否确切知道该指标是什么？您应该测量平均延迟、中位数延迟还是第n百分位数延迟？

在谷歌SRE组织的早期，当我们管理的除了搜索和广告之外的产品相对较少时，速度的SLO（服务级别目标）是根据中位数延迟设置的。（SLO是给定指标的目标值，用于传达服务的期望性能水平。当达到目标时，该服务的该方面被认为是表现足够的。在SLO的上下文中，被评估的指标称为SLI，或服务级别指标。）

多年来，特别是随着搜索的使用扩展到其他大洲，我们了解到，即使我们正在实现并超越我们的SLO目标，用户也可能不满意。然后，我们进行了研究，以确定响应时间略微退化对用户行为的影响，并发现当遇到小至200毫秒的增量延迟时，用户进行的搜索次数会显着减少。³ 基于这些和其他发现，我们已经学会了衡量“长尾”延迟——也就是说，必须在第95和第99百分位数测量延迟，以准确捕获用户体验。毕竟，如果百分之五的用户对获得正确结果所需的时间不满意，那么产品在99.999%的时间内提供正确的结果也没有关系。

曾经有一段时间，谷歌过去只衡量原始可用性。事实上，即使在今天，大多数SLO也是围绕可用性制定的：有多少请求返回良好结果，有多少请求返回错误。可用性的计算方式如下

% 可用性 = 1 - % 错误响应

假设您有一个用户服务，通常在半秒内响应，这对于智能手机上的用户来说听起来足够好，考虑到典型的无线网络延迟。现在假设每30个请求中有一个请求存在内部问题，导致延迟，从而导致移动客户端应用程序在10秒后重试请求。现在进一步假设重试几乎总是成功。可用性指标（如上计算）将显示“100%可用性”。用户会说“97%可用”——因为如果他们习惯于在500毫秒内收到响应，那么在三到五秒后，他们会点击重试或切换应用程序。用户文档是否说“应用程序可能需要长达10秒才能响应”并不重要；一旦用户群习惯于在大多数时间在500毫秒内获得答案，这就是他们的期望，并且他们会像10秒响应延迟是中断一样表现。与此同时，SRE（不正确地）会感到高兴，至少在目前是这样，因为他们的测量结果表明该服务是100%可用的。可以通过如下更正可用性计算来避免这种脱节

% 可用性 = 1 - % （错误响应 + 慢响应）

因此，当为长尾延迟定义SLO时，您必须选择一个不会使服务实际上不可用的目标响应时间。第99百分位数延迟应使用户体验该延迟不会发现相对于他们的期望完全不可接受。请注意，他们的期望可能是由中位数延迟设定的。您确实需要知道您的用户认为的最低可接受程度。一个好的做法是进行实验，测量当延迟人为增加时实际损失了多少用户。这些实验应不频繁地进行，使用极小一部分随机抽样的用户，以最大限度地减少对您的产品品牌和声誉的风险。

从谷歌的这些实验中学到的一个好的实用经验法则是，第99百分位数延迟不应超过中位数延迟的三到五倍。这意味着，如果一个假设的服务的平均延迟为400毫秒，但最慢的百分之一的请求开始表现出超过两秒的响应时间，这是不可取的。我们调整我们的生产系统，以便如果这种不良行为持续一段时间（预定义），则会触发警报或采取一些自动纠正措施（例如转移流量或配置更多服务器）。我们发现服务的第50、95和99百分位数延迟测量值各自都很有价值，理想情况下，我们将围绕它们中的每一个设置SLO。

如何定义基于百分位数的SLO

有一种技术可以最佳地措辞SLO定义——这是一个语言学观点，这里用一个有趣的谜题来说明。考虑以下两个针对给定Web服务的替代SLO定义，在每个定义中使用略微不同的语言

1. 用户请求的第99百分位数延迟，在过去五分钟的时间窗口内平均，将小于800毫秒。

2. 百分之九十九的用户请求，在过去五分钟的时间窗口内平均，将在不到800毫秒的时间内完成。

假设在两种情况下，SLO都将每10秒测量一次，并且如果N个连续测量值超出范围，则将触发警报。在进一步阅读之前，思考哪个SLO定义更好，以及为什么。

答案是从用户满意度的角度来看，这两个SLO实际上是等效的；然而，从计算角度来看，替代方案2明显更优。

为了理解这一点，考虑一个假设的Web服务，在峰值负载条件下，平均每秒接收10,000个用户请求。使用SLO定义1，测量算法实际上必须每10秒计算一次百分位数。这种计算的朴素方法如下

• 将10,000✕300 = 300万个查询的响应时间存储在内存中，以捕获五分钟的数据（这将使用>11MB的内存来存储300万个32位整数，每个整数代表一个查询的响应时间，以毫秒为单位）。

• 对这300万个整数值进行排序。

• 读取第99百分位数（即，排序列表中第30,000个延迟值，从最大值向下计数）。

肯定有更高效的算法可用，例如使用16位短整数表示延迟值，并使用两个堆而不是每10秒对线性列表进行排序，但即使是这些改进的方法也涉及显着的开销。

相比之下，SLO定义2只需要在内存中存储两个整数：完成时间大于800毫秒的用户请求计数，以及用户请求总数。然后，确定SLO合规性是一个简单的除法运算，您根本不必记住延迟值。

务必使用格式2定义您的长尾延迟SLO。

我们对延迟指标的建议可以同样好地应用于其他类型的SLI，其中一些适用于非Web服务的系统。正如SRE书籍中所讨论的那样，存储系统也关心持久性（数据在需要时是否可用），数据处理管道关心吞吐量和新鲜度（数据从摄取到完成需要多长时间）。

有关如何为服务创建SLO的更多建议，请阅读SRE工作手册中的第2章“实施SLO”。

教训 3：衡量未来负载

需求预测或量化服务的未来负载不同于典型的SLO测量，因为它不是您监控的指标，也不是生成警报的原因。需求预测通过提供配置服务所需的信息来使服务可靠，以便它可以处理其未来负载，同时继续满足其SLO。您在生成良好需求预测方面投入的精力越多，您就越不需要在最后一刻匆忙为服务添加更多计算资源，因为它在面对无法预料的流量增加时正在崩溃。

服务的负载使用不同指标的组合来衡量，具体取决于所讨论的服务类型，但许多服务的通用分母单位是QPS。在QPS之上，可能还有其他服务相关的指标，例如存储大小（千兆字节或太字节）、内存使用率、网络带宽或I/O带宽（千兆比特每秒）。

将需求增长分解为自然增长和非自然增长是有用的。自然增长是您可以通过外推历史流量趋势来预测的增长，并且预测问题通常可以使用统计工具来解决。非自然增长是您针对一次性事件（例如产品发布、服务性能变化或用户行为的预期变化等因素）预测的增长，并且这种增长无法从历史数据中外推。非自然增长的预测不太适合统计工具，并且通常依赖于经验法则和从过去类似事件中得出的估计。在服务发布之前的这段时间里，当没有足够的历史数据可用于进行自然增长预测时，团队会使用适用于非自然增长的技术来估计需求。

预测自然增长

对于已经运行了几年的成熟产品，您可以使用统计方法预测自然增长。请注意，线性回归在大多数情况下不是一个有用的工具，因为它没有捕获季节性流量波动；如果增长不是线性的，它也不起作用。许多Web服务看到流量显着下降（“夏季低迷”），这是由于年中假期季节，相反，在年底购物季期间看到流量大幅飙升，随后是一年中最后一周的“假日骤降”，然后在新年初出现“重返工作岗位反弹”（参见图1）。在谷歌，我们甚至考虑了由国际足联世界杯等事件引起的几年周期时间的可预测变化。

谷歌使用各种预测模型，试图捕获每月或每年的季节性。预测存在不确定性，并且它们暗示了置信水平，因此我们预测的不是一条线，而是一个锥形。任何给定的统计模型都有其优点和缺点，因此许多谷歌产品使用从大型模型集合生成的输出⁶，其中包括许多众所周知的方法的变体，例如Bass扩散模型；Theta模型；逻辑模型；贝叶斯结构时间序列；STL（使用Loess的季节性和趋势分解）；Holt-Winters和其他指数平滑模型；季节性和其他基于ARIMA（自回归积分移动平均）的模型；逐年增长模型；自定义模型等等。

在从集合中的每个模型生成独立估计后，我们然后计算它们的平均值，在应用可配置的“修剪”参数以消除异常值估计后，此调整后的平均值用作最终预测。根据服务的规模和全球覆盖范围及其在世界不同地区的采用程度，生成洲级或国家级预测并汇总它们可能比尝试在全球层面进行预测更准确。

将预测与实际流量定期进行比较非常重要，以便随着时间的推移调整模型参数并提高模型的准确性。经验表明，与任何单个模型相比，模型集合的修剪平均值可提供卓越的准确性。

谷歌搜索监控看到的皇家婚礼

每日流量波动对于容量规划来说远没有每月或每年的增长重要，但它们为外部世界事件对Web服务负载的影响提供了一个有趣的例证。图2中的图表由监控谷歌搜索产品负载的系统生成，代表了2011年4月29日威廉王子和凯特·米德尔顿婚礼期间的搜索QPS数量。Y轴上的时间值位于太平洋时区（比英国时间晚八小时），流量模式简洁地捕获了仪式期间的关键事件。从这样的图表中可以明显看出，当世界上发生真正有趣的事情时，人们会短暂停止在网络上搜索，而当该事件结束后，他们会立即恢复搜索。

预测非自然增长

非自然增长是由没有周期性的一次性事件产生的，例如新产品、新功能或营销促销的发布，或由某些外部因素触发的用户行为变化，这些因素的时间是可预测的，但由此产生的峰值流量具有高度不确定性（如国际足联世界杯或皇家婚礼）等等。非自然增长涉及流量的突然变化，并且本质上是不可预测的，因为它是由以前从未发生过或无法直接从过去外推的事件触发的。当产品负责人和SRE提前收到此类增长的通知时，例如在计划新功能发布时，他们需要应用直觉和经验法则来估计发布后的流量，并理解他们的预测将具有更高的不确定性。

用于预测产品/功能发布非自然增长的一般规则包括以下内容

• 检查过去类似或类似功能发布的历史流量变化。

• 对于国家或市场特定的发布，请考虑过去该市场的用户行为。

• 考虑围绕发布的宣传和推广程度。

• 在可能的情况下，为预测添加不确定性余量，方法是配置预测所暗示的资源的三到五倍。

• 虽然全新产品的流量更难预测，但它通常也很小，因此您可以为这种流量过度配置，而不会产生太大的成本。

谷歌分析的经验教训

谷歌分析的首次发布是一个有趣的非自然增长案例研究，它不是由任何工程变更产生的，而且规模不小。谷歌收购了Urchin Software Corporation，以获取其Web分析产品，该产品为付费客户提供流量收集和分析仪表板。当该产品以谷歌品牌免费提供时，非自然流量增长事件发生了，允许任何网站所有者免费注册。谷歌根据之前免费发布Keyhole（后来称为谷歌地球）订阅产品的经验，正确地预测了新用户的涌入。因此，我们仔细地对产品进行了负载测试和配置，以应对预期的流量增加。

我们对核心产品使用情况的预测表现相当不错，但我们忘记考虑注册页面的流量！新用户注册的页面由一个单线程SQL数据库支持，该数据库的事务容量有限，对每秒注册数量施加了严格的且以前未知的限制，导致用户不断公开抱怨网站速度缓慢和不可用。我们很好地吸取了这个教训，此后我们的产品发布清单中包含以下问题：“新用户是否必须注册您的服务？如果是，您是否已估计和测试了注册页面的负载？”

教训 4：衡量服务效率

SRE团队应定期衡量他们运行的每项服务的效率，使用负载测试和基准测试程序来确定在给定一定数量的计算资源（CPU、内存、磁盘I/O、网络带宽等）的情况下，可以处理多少每秒用户请求，并保持可接受的响应时间。虽然性能测试可能看起来是显而易见的最佳实践，但在现实生活中，团队经常忘记服务效率。他们可能每年或在主要版本发布之前对服务进行一次基准测试，然后不自觉地假设服务的性能在基准测试之间保持不变。实际上，即使是对代码或用户行为的看似微小的更改，也可能会影响为给定流量提供服务所需的资源量。

发现服务效率降低的常见方法是通过产品中断。SRE团队可能认为他们有足够的容量来服务峰值流量，即使关闭两个数据中心的资源进行维护或紧急维修，但当罕见事件发生，即两个数据中心在峰值流量时段实际宕机时，服务的性能会急剧下降，并导致部分中断或变得如此缓慢以至于服务无法使用。在最坏的情况下，这可能会演变成“级联故障”，其中所有服务集群像多米诺骨牌一样倒塌，从而导致全局产品中断。

具有讽刺意味的是，这种类型的大规模故障是由系统尝试从较小的故障中恢复触发的。一个服务器集群碰巧由于地理位置和/或用户行为而获得了更高的负载，并且此负载足以导致所有服务器崩溃。流量负载均衡系统观察到这些服务器离线并执行故障转移操作，转移以前发送到崩溃集群的所有流量，并将其发送到附近的集群。结果，这些附近的服务器中的每一个现在都变得更加过载并也崩溃，导致更多的流量被发送到更少的活动服务器。循环重复，直到每台服务器都死机，并且服务在全球范围内不可用。

服务可以使用丢弃过载技术来避免级联故障。在这里，服务器代码被设计为检测到何时过载，并在这些情况下随机丢弃一些传入请求，而不是尝试处理所有请求并最终崩溃。这会导致请求被丢弃的用户的客户体验下降，但这可以通过让客户端重试请求在很大程度上得到缓解；在任何情况下，对一小部分用户来说，响应速度较慢或完全错误响应都比全局服务故障要好得多。

当然，最好完全避免这种情况，而做到这一点的唯一方法是定期测量服务效率，以确认SRE团队关于有多少服务容量可用的假设。对于每天或更频繁地发布版本的服务，每日基准测试不是一种极端的做法——基准测试可以构建到自动化发布测试程序中。当及早检测到新引入的性能下降时，团队可以在短期内配置更多资源，然后在长期内修复性能错误，以使资源成本恢复正常。

如果您在云平台上运行服务，一些云提供商会提供自动扩容服务，该服务会在您的服务负载增加时自动配置更多资源。这种设置可能比在本地或具有固定硬件资源的数据中心运行产品更好，但它仍然不能让您摆脱定期基准测试的责任。即使完全中断的风险较低，您也可能会为时已晚地发现您的每月云账单大幅增加，仅仅是因为有人修改了用于压缩数据的编码方案，或者进行了其他看似无害的代码更改。由于这些原因，定期测量服务效率是一种最佳实践。

有关更多详细信息，请参阅SRE工作手册中的第11章“管理负载”。本章包含两个管理过载的案例研究。

结论

本文中讨论的指标对于那些运行服务并关心可靠性的人员应该是有用的。如果您衡量这些指标，设置正确的目标，并努力准确地衡量指标，而不是近似值，您应该会发现：（1）您的服务运行得更好；（2）您遇到的中断更少；并且（3）您会看到更多的用户采用。我们大多数人都喜欢这三个属性。

参考文献

1. Beyer, B., Jones, C., Petoff, J., Murphy, N. R. 2016. 站点可靠性工程：谷歌如何运行生产系统。 O'Reilly Media.

2. Beyer, B., Murphy, N. R., Rensin, D. K., Kawahara, K., Thorne, S. 2018. 站点可靠性工作手册：实施SRE的实用方法。 O'Reilly Media.

3. Brutlag, J. 2009. 速度很重要。 Google AI Blog; https://research.googleblog.com/2009/06/speed-matters.html.

4. Kübler-Ross“悲伤的五个阶段”模型； https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model.

5. 使用PageSpeed工具分析和优化您的网站； https://developers.google.com/speed/

6. Tassone, E, Rohani, F. 2017. 我们在规模上寻求稳健的时间序列预测。 The Unofficial Google Data Science Blog; http://www.unofficialgoogledatascience.com/2017/04/our-quest-for-robust-time-series.html.

7. Treynor, B. 2017. 重要的指标 (Google Cloud Next); https://youtu.be/iF9NoqYBb4U.

专用全球网络：谷歌向SDN的转变
与Amin Vahdat、David Clark和Jennifer Rexford的讨论
https://queue.org.cn/detail.cfm?id=2856460

从这里到那里，SOA之路
Terry Coatta
SOA不再像之前的那些方法那样是万能药。
https://queue.org.cn/detail.cfm?id=1388788

敏捷模因丛林之旅
Philippe Kruchten
在敏捷开发的世界中，上下文是关键。
https://queue.org.cn/detail.cfm?id=1281893

Benjamin Treynor Sloss 从6岁开始编程，17岁加入Oracle担任软件工程师。他曾在Oracle和Versant担任软件工程师，然后在E.piphany、SEVEN以及最终的谷歌（2003年至今）担任工程管理职务。他在谷歌目前的团队约有4,700人，负责全球的站点可靠性工程、网络和数据中心。

Shylaja Nukala 是谷歌站点可靠性工程的技术写作主管。她领导SRE、云和谷歌工程师的文档、信息管理和精选培训工作。她拥有罗格斯大学传播学博士学位。

Vivek Rau 是谷歌的站点可靠性工程师，从事CRE（客户可靠性工程）工作。CRE团队向客户讲授核心SRE原则，使他们能够在谷歌云平台上构建和运营高度可靠的产品。Rau拥有IIT-马德拉斯计算机科学学士学位。

最初发表于 Queue vol. 16, no. 6—
在数字图书馆中评论本文

更多相关文章

Niklas Blum, Serge Lachapelle, Harald Alvestrand - WebRTC - 开放Web平台的实时通信
在这场疫情期间，世界比以往任何时候都更依赖于基于互联网的 RTC（实时通信）。在过去十年中，RTC 产品的数量激增，这在很大程度上是由于更便宜的高速网络接入和更强大的设备，同时也归功于一个名为 WebRTC 的开放、免版税的平台。WebRTC 的作用日益重要，它不仅能提供有用的体验，更能让数十亿人在疫情期间继续工作和学习，并保持至关重要的人际联系。WebRTC 未来的机遇和影响确实令人着迷。

Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖关系
如果你曾经把钥匙锁在家里或车里，你就会对依赖循环很熟悉。没有钥匙你打不开锁，但打不开锁你就拿不到钥匙。有些循环是显而易见的，但在更复杂的依赖循环导致故障之前，找到它们可能具有挑战性。跟踪和控制依赖关系的策略对于维护可靠的系统是必要的。

Diptanu Gon Choudhury, Timothy Perrett - 为互联网规模的服务设计集群调度器
工程师在构建调度系统时，应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的操作员如何配置补救策略，同时帮助租户系统在租户系统所有者进行故障排除期间尽可能保持稳定。

Štěpán Davidovič, Betsy Beyer - 金丝雀分析服务
指望从事产品开发或可靠性工作的工程师具备统计学知识是不合理的；消除这一障碍导致了 CAS 的广泛采用。CAS 已被证明即使对于不需要配置的基本情况也很有用，并显着提高了 Google 的发布可靠性。影响分析表明，CAS 可能已经防止了数百起值得事后分析的故障，并且不使用 CAS 的团队的事后分析率明显更高。