语言 Chinese, Simplified

SEO Title

Google Cloud 架构框架中的这份文档提供了最佳做法，用于定义适当的方法来衡量您的服务的客户体验，以便您可以运行可靠的服务。您将了解如何迭代您定义的服务级别目标 (SLO)，并使用错误预算来了解如果发布其他更新，可靠性可能会受到影响。

选择合适的 SLI

选择适当的服务水平指标 (SLI) 以充分了解您的服务执行情况非常重要。例如，如果您的应用程序具有多租户架构，这是由多个独立客户使用的典型 SaaS 应用程序，请在每个租户级别捕获 SLI。如果您的 SLI 仅在全局聚合级别进行测量，您可能会错过应用程序中影响单个重要客户或少数客户的关键问题。相反，将您的应用程序设计为在每个用户请求中包含一个租户标识符，然后将该标识符传播到堆栈的每一层。此标识符允许您的监控系统在请求路径上的每一层或微服务的每个租户级别汇总统计信息。

您运行的服务类型还决定了要监控的 SLI，如以下示例所示。

服务系统

以下 SLI 在提供数据的系统中是典型的：

可用性告诉您服务可用的时间比例。它通常根据格式良好的请求成功的比例来定义，例如 99%。
延迟告诉您可以以多快的速度满足一定百分比的请求。它通常以第 50 位以外的百分位来定义，例如“300 毫秒时的第 99 个百分位”。
质量告诉你某个反应有多好。质量的定义通常是特定于服务的，并表示对请求的响应内容与理想响应内容的差异程度。响应质量可以是二元的（好或坏）或以 0% 到 100% 的范围表示。

数据处理系统

以下 SLI 在处理数据的系统中是典型的：

覆盖率告诉您已处理的数据比例，例如 99.9%。
正确性告诉您被认为正确的输出数据的比例，例如 99.99%。
新鲜度告诉您源数据或聚合输出数据的新鲜程度。通常，更新越近越好，例如 20 分钟。
吞吐量告诉您正在处理多少数据，例如 500 MiB/秒甚至每秒 1000 个请求 (RPS)。

存储系统

以下 SLI 在存储数据的系统中是典型的：

持久性告诉您写入系统的数据在未来被检索到的可能性有多大，例如 99.9999%。任何永久性数据丢失事件都会降低持久性指标。
吞吐量和延迟也是存储系统的常见 SLI。

根据用户体验选择 SLI 并设置 SLO

本架构框架部分的核心原则之一是可靠性由用户定义。尽可能靠近用户测量可靠性指标，例如以下选项：

如果可能，请检测移动或 Web 客户端。
- 例如，使用 Firebase 性能监控来深入了解您的 iOS、Android 和 Web 应用程序的性能特征。
如果这不可能，请检测负载平衡器。
- 例如，将 Cloud Monitoring 用于外部 HTTP(S) 负载平衡器日志记录和监控。
衡量服务器的可靠性应该是最后的选择。
- 例如，使用 Stackdriver Monitoring 监控 Compute Engine 实例。

将您的 SLO 设置得足够高，以使几乎所有用户都对您的服务感到满意，而不是更高。由于网络连接或其他短暂的客户端问题，您的客户可能不会注意到应用程序中的短暂可靠性问题，从而允许您降低 SLO。

对于正常运行时间和其他重要指标，目标是低于 100% 但接近它。服务所有者应客观地评估使大多数用户满意的最低服务性能和可用性水平，而不仅仅是根据外部合同水平设定目标。

您更改的速率会影响系统的可靠性。但是，频繁进行小幅更改的能力可以帮助您更快、更优质地交付功能。根据客户体验调整的可实现的可靠性目标有助于定义客户可以容忍的最大变化速度和范围（功能速度）。

如果您无法衡量客户体验并围绕它定义目标，您可以运行竞争基准分析。如果没有可比的竞争，衡量客户体验，即使你还不能定义目标。例如，衡量系统可用性或对客户进行有意义且成功的交易的比率。您可以将此数据与业务指标或 KPI 相关联，例如零售订单量或客户支持电话和工单的数量及其严重性。在一段时间内，您可以使用此类关联练习来达到合理的客户满意度阈值。此阈值是您的 SLO。

有关如何选择正确的 SLI 和定义 SLO 的更多信息，请参阅定义 SLO。