Google 标准做法是通过一个客观的指标来体现一个待优化的系统属性。通过设立这样一个目标，我们可客观地评价目前的系统表现以及追踪一段时间内的改进和退步。对于服务风险而言，将所有的潜在因素缩减为一个单一的性能指标，可能不是一件能够立刻解决的事情。服务故障可能会有很多潜在的影响，包括用户的不满、伤害，或丧失信任;直接或者间接的收入损失;品牌以及口碑上的影响;不良的新闻报道等。很明显，这些因素中的一部分很难被合理地度量。为了使这个问题在我们运行的各种类型的系统中易于处理，并且保持一致，我们选择主要关注计划外停机这个指标。

对于大多数服务而言，最直接的能够代表风险承受能力的指标就是对于计划外停机时间的可接受水平。计划外停机时间是由服务预期的可用性水平所体现的，通常我们愿意用提供的"9"系列的数字来体现，比如可用性为99.9%.99.99%或9999%。每个额外的"9"都对应一个向 100%可用性的数量级上的提高。对于服务系统而言，这个指标通常是基于系统正常运行时间比例的计算得出的（参考公式3-1）。

公式3-1∶ 基于时间的可用性
可用性=系统正常运行时间/（系统正常运行时间＋停机时间）

使用这个公式，我们可以计算出一年内可接受的停机时间，从而可以使可用性达到预期目标。举例来说，一个可用性目标为99.99%的系统最多在一年中停机52.56分钟，就可以达到预计的可用性目标;详情参见附录 A。

然而，在 Google 内部，基于时间的可用性通常是毫无意义的。因为我们需要着眼全球范围内的分布式服务。Google所采用的故障隔离手段使得我们能够保证在任何时候、任何地方对于一个给定的服务，总是可以处理一定的用户流量。（也就是说，我们随时都是部分"在线"的）。因此，我们通过请求成功率来定义服务可用性。公式3-2 体现了这个基于产量的指标是怎样通过滚动窗口计算出来的（比如，一天内成功请求的比率）。

公式3-2∶ 合计可用性
可用性= 成功请求数 /总的请求数

例如，一个每天可用性目标为999%的系统，一天要接受 2.5M 个请求。它每天出现少于 250 个错误即可达到预计的可用性目标。

在一个典型的应用中，不是所有的请求都是平等的∶一个新的用户注册请求失败和一个后台调用的新邮件的轮询请求失败是不同的。然而在许多情况下，从终端用户的角度来看，通过计算全部请求成功率是一个对于计划外停机时间的合理估计。

使用请求成功率指标量化计划外停机时间使得这种指标更适合在不直接服务终端用户的系统中使用。大多数非服务性的系统（比如，批处理、流水线、存储服务以及交易系统等）对成功和非成功的工作单元有明确的定义。事实上，虽然在本章中讨论的系统基本上都是有关消费者类型和基础设施服务类型的系统，但是同样的原则也基本上适用于非服务型系统。

例如，一个批处理进程通过提取、转换，并将客户数据库中的一位客户的数据内容插入数据仓库中，以便进行定期的进一步分析。通过使用某条记录处理成功和处理不成功来定义请求成功率，我们能计算出一个有效的可用性指标，尽管事实上该批处理系统并不是持续运行的。

通常，我们会为一项服务设定季度性的可用性目标，每周甚至每天对性能进行跟踪。我们通过寻找、跟踪和调整重要的、不可避免的偏差来使服务达到一个高层次的可用性目标。详情参见第 4章。

Google 标准做法是通过一个客观的指标来体现一个待优化的系统属性。通过设立这样一个目标，我们可客观地评价目前的系统表现以及追踪一段时间内的改进和退步。对于服务风险而言，将所有的潜在因素缩减为一个单一的性能指标，可能不是一件能够立刻解决的事情。服务故障可能会有很多潜在的影响，包括用户的不满、伤害，或丧失信任;直接或者间接的收入损失;品牌以及口碑上的影响;不良的新闻报道等。很明显，这些因素中的一部分很难被合理地度量。为了使这个问题在我们运行的各种类型的系统中易于处理，并且保持一致，我们选择主要关注计划外停机这个指标。

对于大多数服务而言，最直接的能够代表风险承受能力的指标就是对于计划外停机时间的可接受水平。计划外停机时间是由服务预期的可用性水平所体现的，通常我们愿意用提供的"9"系列的数字来体现，比如可用性为99.9%.99.99%或9999%。每个额外的"9"都对应一个向 100%可用性的数量级上的提高。对于服务系统而言，这个指标通常是基于系统正常运行时间比例的计算得出的（参考公式3-1）。

公式3-1∶ 基于时间的可用性
可用性=系统正常运行时间/（系统正常运行时间＋停机时间）

使用这个公式，我们可以计算出一年内可接受的停机时间，从而可以使可用性达到预期目标。举例来说，一个可用性目标为99.99%的系统最多在一年中停机52.56分钟，就可以达到预计的可用性目标;详情参见附录 A。

然而，在 Google 内部，基于时间的可用性通常是毫无意义的。因为我们需要着眼全球范围内的分布式服务。Google所采用的故障隔离手段使得我们能够保证在任何时候、任何地方对于一个给定的服务，总是可以处理一定的用户流量。（也就是说，我们随时都是部分"在线"的）。因此，我们通过请求成功率来定义服务可用性。公式3-2 体现了这个基于产量的指标是怎样通过滚动窗口计算出来的（比如，一天内成功请求的比率）。

公式3-2∶ 合计可用性
可用性= 成功请求数 /总的请求数

例如，一个每天可用性目标为999%的系统，一天要接受 2.5M 个请求。它每天出现少于 250 个错误即可达到预计的可用性目标。

在一个典型的应用中，不是所有的请求都是平等的∶一个新的用户注册请求失败和一个后台调用的新邮件的轮询请求失败是不同的。然而在许多情况下，从终端用户的角度来看，通过计算全部请求成功率是一个对于计划外停机时间的合理估计。

使用请求成功率指标量化计划外停机时间使得这种指标更适合在不直接服务终端用户的系统中使用。大多数非服务性的系统（比如，批处理、流水线、存储服务以及交易系统等）对成功和非成功的工作单元有明确的定义。事实上，虽然在本章中讨论的系统基本上都是有关消费者类型和基础设施服务类型的系统，但是同样的原则也基本上适用于非服务型系统。

例如，一个批处理进程通过提取、转换，并将客户数据库中的一位客户的数据内容插入数据仓库中，以便进行定期的进一步分析。通过使用某条记录处理成功和处理不成功来定义请求成功率，我们能计算出一个有效的可用性指标，尽管事实上该批处理系统并不是持续运行的。

通常，我们会为一项服务设定季度性的可用性目标，每周甚至每天对性能进行跟踪。我们通过寻找、跟踪和调整重要的、不可避免的偏差来使服务达到一个高层次的可用性目标。详情参见第 4章。