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。

迭代改进 SLO

SLO 不应一成不变。每季度或至少每年重新访问 SLO，并确认它们继续准确反映用户的幸福感并与服务中断密切相关。确保它们涵盖当前的业务需求和新的关键用户旅程。在这些定期审查之后，根据需要修改和增加您的 SLO。

使用严格的内部 SLO

拥有比外部 SLA 更严格的内部 SLO 是一种很好的做法。由于违反 SLA 往往需要签发财务信用或客户退款，因此您希望在问题产生财务影响之前解决问题。

我们建议您将这些更严格的内部 SLO 与无可指责的事后分析流程和事件审查一起使用。有关更多信息，请参阅架构中​​心可靠性类别中的构建协作事件管理流程。

使用错误预算来管理开发速度

错误预算会告诉您您的系统在某个时间窗口内是否比所需的可靠性更高或更低。错误预算按 100% 计算——一段时间内的 SLO，例如 30 天。

当您的错误预算中有剩余容量时，您可以继续快速启动改进或新功能。当错误预算接近于零时，冻结或减慢服务更改并投入工程资源以提高可靠性功能。

Google Cloud 的运营套件包括 SLO 监控，以最大程度地减少设置 SLO 和错误预算的工作量。操作套件包括一个图形用户界面，可帮助您手动配置 SLO，一个用于编程设置 SLO 的 API，以及用于跟踪错误预算消耗率的内置仪表板。有关详细信息，请参阅如何创建 SLO。

建议

要将架构框架中的指南应用到您自己的环境中，请遵循以下建议：

• 定义和衡量以客户为中心的 SLI，例如服务的可用性或延迟。
• 定义比外部 SLA 更严格的以客户为中心的错误预算。包括违规后果，例如生产冻结。
• 设置延迟 SLI 以捕获异常值，例如第 90 或第 99 个百分位数，以检测最慢的响应。
• 至少每年检查一次 SLO，并确认它们与用户满意度和服务中断密切相关。

原文：https://cloud.google.com/architecture/framework/reliability/define-goals

本文：https://jiagoushi.pro/node/2160