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

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

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

评价服务风险容忍度时，有许多需要考虑的因素。如下所示∶
● 需要的可用性水平是什么?
● 不同类型的失败对服务有不同的影响吗?
● 我们如何使用服务成本来帮助在风险曲线上定位这个服务?
● 有哪些其他重要的服务指标需要考虑?

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

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

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

评价服务风险容忍度时，有许多需要考虑的因素。如下所示∶
● 需要的可用性水平是什么?
● 不同类型的失败对服务有不同的影响吗?
● 我们如何使用服务成本来帮助在风险曲线上定位这个服务?
● 有哪些其他重要的服务指标需要考虑?