对于某个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前端曾经就是这样的一种服务。它是 商和网站创建者用来建立、配置、运行和监控他们的 活动的服务。因为这项工作大部分发生在正常工作时间内，我们认为维修窗口中发生的偶然的、正常的、计划之中的故障是可以接受的，并且我们把这些故障看作计划内停机时间，而不是计划外停机时间。

对于某个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前端曾经就是这样的一种服务。它是 商和网站创建者用来建立、配置、运行和监控他们的 活动的服务。因为这项工作大部分发生在正常工作时间内，我们认为维修窗口中发生的偶然的、正常的、计划之中的故障是可以接受的，并且我们把这些故障看作计划内停机时间，而不是计划外停机时间。