服务的风险容忍度

如何辨别服务的风险容忍度？在一个正式的环境或安全关键的系统中，服务的风险容忍度通常是直接根据基本产品或服务的定义建立的。在 Google内部，服务风险容忍度往往定义得没有那么清楚。

为了辨别服务的风险容忍度，SRE必须与产品负责人一起努力，将一组商业目标转化为明确的可以实现的工程目标。这些商业目标会直接影响所提供服务的性能和可靠性目标。在实践中，这种转化说起来比做起来容易得多。消费者类型的服务往往有明确的产品负责人，而对于基础设施服务来说，拥有类似的产品所有权结构是很少见的（例如，存储系统或者通用的HTTP缓存层）。接下来，我们会分别讨论消费者服务和基础设施服务。

辨别消费者服务的风险容忍度

我们的消费者服务通常会有一个对应的产品团队，是该服务的商业所有者。比如说，Search、Google Maps和Google Docs，它们每一个都有自己的产品经理。这些产品经理负责了解用户和业务，在市场上塑造产品的定位。存在产品团队时，我们能够更好地通过这个团队来讨论服务的可靠性要求。在没有专门的产品团队的情况下，建立系统的工程师们经常在知情或不知情的情况下扮演了这个角色。

评价服务风险容忍度时，有许多需要考虑的因素。如下所示：

● 需要的可用性水平是什么？

● 不同类型的失败对服务有不同的影响吗？

● 我们如何使用服务成本来帮助在风险曲线上定位这个服务？

● 有哪些其他重要的服务指标需要考虑？

可用性目标

对于某个Google服务而言，服务的可用性目标通常取决于它提供的功能，以及这项服务在市场上是如何定位的。下面列出了要考虑的一些问题：

● 用户期望的服务水平是什么？

● 这项服务是否直接关系到收入（我们的收入或我们的客户的收入）？

● 这是一个有偿服务，还是免费服务？

● 如果市场上有竞争对手，那些竞争对手提供的服务水平如何？

● 这项服务是针对消费者还是企业的？

例如 Google Apps for Work，这个服务的主要用户是企业类用户，包括大型企业和中小企业。这些企业依靠Google应用程序提供的办公类型的服务（例如Gmail、Calendar、Drive和Docs）让员工进行日常工作。另一方面，一个Google Apps for Work服务的中断不仅会影响Google本身，也会影响到那些在业务上非常依赖于我们的企业。对于这类服务，我们可能会设置季度性的外部可用性目标为99.9%。同时，我们会设置一个更高的内部可用性目标，以及签署一份如果我们未能达到外部目标的处罚性协议。

YouTube则需要截然不同的考虑。当Google收购YouTube后，我们需要为该网站提供一个更恰当的可用性目标。2006年，YouTube比当时的Google更加专注于消费者，并且当时处于一个与Google 非常不同的企业生命周期阶段。尽管当时YouTube已经有了一个很出色的产品，但它仍然在不断变化和快速发展着。因此，我们为YouTube设定了一个相比我们企业的产品更低的可用性目标，因为快速发展更加重要。

故障的类型

对于一项给定的服务的故障预期是另一个需要重点考虑的因素。我们的业务对于服务的停机时间的容忍程度有多高？持续的低故障率或者偶尔发生的全网中断哪一个会更糟糕？这两种类型的故障可能会导致绝对数量上完全相同的错误被返回，但可能对于业务的影响相差很大。

下面这个例子说明了一个提供私人信息的系统中自然发生的完全和部分服务中断的区别。假设有一个联系人管理应用程序，一种情况是导致用户头像显示失败的间歇性故障，另一种情况是将A用户的私人联系列表显示给B用户的故障。第一种情况显然是一个糟糕的用户体验，SRE会努力去快速地解决这个问题。然而，在第二种情况下，暴露私人数据的风险可能会破坏基本的用户信任。因此，在第二种情况下，在进行调试和事后的数据清理时，完全停止该服务更加恰当。

对于Google提供的其他服务，有时候，我们可以接受计划内的常规的服务中断。几年前，Ads前端曾经就是这样的一种服务。它是广告商和网站创建者用来建立、配置、运行和监控他们的广告活动的服务。因为这项工作大部分发生在正常工作时间内，我们认为维修窗口中发生的偶然的、正常的、计划之中的故障是可以接受的，并且我们把这些故障看作计划内停机时间，而不是计划外停机时间。

成本

决定一项服务的合理可用性目标时，成本是很重要的考虑因素。

广告服务就能很好地体现出这种取舍，因为成功与失败直接通过赢利和亏损体现。在为每一项服务确定可用性目标时，可以考虑如下的问题：

● 构建和运维可用性再多一个“9”的系统，收益会增加多少？

● 额外的收入是否能够抵消为了达到这一可靠性水平所付出的成本？为了使这个权衡等式更精确，假设一项业务中每一个请求的价值是一样的，考虑如下的成本与收益：

可用性目标：99.9%→99.99%

增加的可用性：0.09%

服务收入：100万美元

改进可用性后的价值：100万美元×0.0009=900美元

在这种情况下，如果可用性提高一个“9”的成本不到900美元，这就是合理的投资。但是，如果成本超过900美元，那么成本将超过预计增加的收入。

当我们无法简单地解释可靠性和收入的关系时，可能会更难设置这些目标。这时，考虑在互联网中ISP的背景误差率可能是个不错的实用策略。如果从最终用户的角度测算故障，那么让服务的误差率低于背景误差率就是可能的。这些误差将归入给定用户的互联网链路的噪声当中。虽然ISP和各种应用协议之间差距很大（比如，TCP vs.UDP、IPv4 vs.IPv6），但是我们测算的ISP的背景误差率基本在0.01%和1%之间。

其他服务指标

除了可用性，其他指标也可以用来确定服务的风险容忍度。了解哪些指标是重要的，哪些指标是不重要的，可以为我们在讨论风险承受能力时提供帮助。

Google广告系统的服务延迟是一个典型的例子。当Google发布Web搜索服务时，服务的一个很关键的特点就是速度快。AdWords是将广告显示在搜索结果旁边的系统。该系统的一个关键要求就是广告不能拖慢用户的搜索体验。这是每一代AdWords系统的一个不变的目标。

AdSense，允许出版商将JavaScript代码插入到自己的网站中的上下文广告，有一个非常不同的延迟目标。对于AdSense而言，延迟的目标是避免在插入上下文广告时影响到第三方页面。这个特定的延迟目标依赖于给定的发布者的页面呈现速度。这意味着AdSense的广告一般可以比AdWords的广告慢数百毫秒。

这种宽松的服务延迟要求允许我们在构建系统时做出一些明智的权衡（例如，使用的服务资源的数量和位置），这能够帮我们节省大量成本。换句话说，相对延迟不敏感的AdSense服务，使得我们能够通过合并需求较少的地理区域来降低运营开销。

基础设施服务的风险容忍度

构建和运维基础设施组件的要求在许多方面是不同于消费者服务的。一个根本的区别是，基础设施组件有多个客户，而他们通常有很多不同的需求。

可用性目标水平

Bigtable是一个大型结构化数据分布式存储系统，一些面向消费者的服务数据直接通过它服务用户请求。这样的服务需要很低的延迟和较高的可靠性。其他团队则把Bigtable作为离线分析的数据存储使用（例如，MapReduce）。这些团队往往更关注吞吐量而非可靠性。这两个情况的风险容忍度相当不同。

能够同时满足两种情况的要求的一种方法就是将所有基础设施服务做得极为可靠。但在实际情况中，这些基础设施服务往往需要占用大量资源，超高可靠性的代价通常是非常昂贵的。为了更好地了解不同类型用户的不同需求，我们可以分析每个用户对自己Bigtable请求队列的期望。

故障类型

低延迟的用户希望Bigtable的请求队列（几乎总是）为空，这样系统可以立刻处理每个出现的请求。（事实上，效率低下的排队过程往往是导致较高的长尾延迟的原因。）而离线分析的用户更感兴趣的是系统的吞吐量，因此用户希望请求队列永远不为空。为了优化吞吐量，Bigtable系统应该避免处于空闲状态。

这样看来，对于这些用户而言，成功和失败是相反的。低延迟用户的成功是关注离线分析的用户的失败。

成本

一种在符合成本效益条件下满足这些竞争性约束的方式就是将基础设施分割成多个服务，在多个独立的服务水平上提供该服务。

在Bigtable的例子中，我们可以构建两个集群：低延迟集群和高吞吐量集群。低延迟集群是为那些需要延迟较低和可靠性较高的服务而设计的。为了确保队列长度最小和满足更严格的客户端隔离要求，Bigtable系统可以配备更多的冗余资源。另一方面，高吞吐量集群的配置冗余度较低，利用率较高。在实践中，高吞吐量集群只有低延迟集群成本的10%～50%。由于Bigtable是广泛部署的系统，这种成本上的降低非常显著。

基础设施服务运维的关键战略就是明确划分服务水平，从而使客户在构建系统时能够进行正确的风险和成本权衡。通过明确划定的服务水平，基础设施提供者其实就是将服务的成本的一部分转移给了用户。以这种方式暴露成本可以促使客户选择既能够满足他们的需求又能够压缩成本的服务水平。例如，Google+将与保护用户隐私相关的数据放置在一个高可用、全球统一的数据存储中（例如，一个全球复制式的类似于SQL 的系统，Spanner，参见文献[cor12]），可选数据（不重要的但是能够增加用户体验的数据）放在一个价格更低、可靠性更低和最终一致的数据存储中（例如，Bigtable这种仅仅提供“尽力而为”模式的复制模式的NoSQL存储系统）。

这里要注意的是，我们可以使用相同的硬件和软件运行多个级别的服务。可以通过调整服务的各种特性提供不同的服务水平，如资源的数量、冗余程度、资源的地理配置，以及基础设施软件的配置。

例子：前端基础设施

为了解释上文中介绍的这些风险容忍度评估原则不仅仅适用于存储基础设施，我们再来看一下另一大类型的服务：Google 的前端基础设施。这个前端基础设施是由反向代理和运行临近我们网络边缘的负载均衡系统组成的。

这些系统的核心工作是负责直接处理用户连接（例如，接受用户浏览器发出的TCP连接）。由于它们的关键性，这些系统需要具有超高的可靠性，面向消费者的服务通常可以用某种方式掩盖后端的不可用情况，但是这些基础服务一般没法这么做。如果某个请求没有到达应用服务的前端服务器，那么就意味着这个请求完全丢失了。

我们已经探讨了识别消费者服务和基础设施服务风险耐受能力的方法。现在，我们将继续讨论如何运用已知的风险耐受水平来通过错误预算调整系统的不可靠性。