有关定义可靠性目标的建议

适用于此 Azure 架构良好的框架可靠性清单建议：

本指南介绍了为关键工作负荷和流定义可用性和恢复目标指标的建议。 应从与业务利益干系人进行研讨会练习中获取可靠性目标。 然后通过监视和测试工作负荷来优化这些目标。

与内部利益干系人就工作负荷可靠性设置现实预期。 然后，他们可以使用合同协议将这些期望传达给客户。 现实的期望还有助于利益干系人理解和支持你的体系结构设计决策，并知道你正在设计以最佳方式满足你同意的目标。

请考虑使用以下指标来量化业务需求。

关键设计策略

可靠性目标表示工作负荷所需的质量目标， 正如其用户和业务利益干系人所承诺的那样。 该目标包括工作负荷的可用性和可恢复性。 请记住，可靠性目标与性能目标不同，但应在可靠性目标中包含性能目标。 请考虑以下可靠性目标：

• 可用性目标 定义了系统保持可访问性和功能的质量标准。 如果不符合这些标准，则系统被视为不可靠。 使用 SLO 来帮助检查系统是否符合这些标准。 业务和技术利益干系人协作设置真实的 SLO，并考虑比较分析、用户体验和工作负载配置文件等因素。

• 正确性目标 可确保工作负荷以一致的质量正确执行其功能。 若要衡量正确性，请量化工作负荷的指标，以便将它们合并为统一的目标分数。

• 恢复目标 对应于 RTO、RPO、MTTR 和 MTBF 指标，用于量化计划和测试业务连续性和灾难恢复的有效性。

为了设置可靠性目标，业务利益干系人定义了广泛的要求。 然后，技术专家评估工作负荷的当前状态，并通过监视和警报实现和维护目标。 双方必须就现实目标达成一致。

根据用户对业务需求的重要性确定和评分用户和系统流 。 使用这些分数来指导工作负荷的设计、评审、测试和事件管理。 为这些流设置可靠性目标，并了解未能满足这些目标可能会显著影响业务。

权衡：系统的技术限制与其业务影响之间可能存在差距，例如吞吐量与每秒事务。 弥合这种差距可能很艰难。 旨在实现实用且经济高效的解决方案，而不是过度工程。

设置可用性目标

工作负荷的总体 SLO 反映了 整体质量，包括其所有依赖项。 SLO 的成熟声明应指示该工作负荷的总体业务目标，而不仅仅是这些依赖项的组合。 例如，如果客户需要 99.99% 的可用性，则总体 SLO 应面向该目标，即使一部分仅达到 99.80%。

利益干系人评估客户体验，并考虑停机时间如何影响收入。 它们将此损失与设计和运营业务流的成本进行比较。 然后，决策者决定他们是否应该花更多的钱在可靠性上，以避免收入损失并保持他们的声誉。

工作负荷所有者 使用财务目标来确定目标。 业务要求映射到可衡量的指标。 目标是确定一组影响客户体验质量的因素。

工作负荷架构师 根据 SLO 做出许多技术决策。 SLO 可以：

• 在考虑其他依赖项时，充当体系结构决策的关键输入。

• 提供近乎实时的视图和对工作负荷运行状况的共享了解，以实现目标讨论。 他们还帮助工作负荷团队确定工作优先级，以提高可靠性和开发新功能。

• 充当部署操作的主要信号，在发生问题时推动自动回滚，并提供更改实现客户体验预期改进的验证。

• 通过专注于目标、向客户发送问题的自动通知以及在你的组织中的团队之间建立信任来加快修正和恢复。

考虑常见的 SLO 和影响因素

每个 SLO 都针对特定的质量标准。 请考虑这些常见的 SLO，以确保可靠性。 此列表并不详尽。 根据业务需求添加 SLO。

• 成功率 衡量相对于返回错误或失败其任务的请求和进程的成功。

• 延迟 测量启动操作请求的时间以及结果可用或进程完成之间的时间。

• 容量 度量并发使用率，例如基于限制的响应数。

• 可用性 从客户的角度衡量运行时间。

• 吞吐量 测量一定时间内的最小数据传输速率。 吞吐量测量为数据速率单位，例如每秒事务数（TPS）或每秒请求数（RPS）。

了解 Azure 上工作负荷的方案和容忍度。 Azure 服务和应用程序组件都影响工作负荷 SLO。 合并下表中的响应以派生整体 SLO。 使用这些问题作为示例来评估工作负荷组件的实用工具。

确定 SLO 范围

可以在各种级别（例如针对系统中的每个应用程序、工作负荷或特定流）设置 SLO。 设置特定于级别的 SLO，以便可以根据每个组件的重要性自定义 SLO。

在软件即服务（SaaS）解决方案中，衡量每个客户的 SLO，以优化每个客户体验。 客户可能在其细分市场中具有不同的基础结构资源。 在这种情况下，跨客户细分聚合所有资源的系统范围的 SLO 可能没有意义。 相反，测量符合每个客户特定上下文的 SLA。 有关详细信息，请参阅 多租户解决方案的租赁模型。

定义复合 SLO 目标

SLA 必须在可观测性窗口中进行测量和测量。

SLO 通常是 99.90% 等百分比，但它们也可以是语句。 使用这两种方法获取包含所有因素的数值。

SLO 由可衡量的 SLA 组成，用于定义可接受的因素。 SLA 是具有可发出警报的设定阈值的指标。 可以从平台或应用程序收集它们。 不同的组件发出相关的 SLA。 选择 SLA 时，请考虑影响 SLO 的因素。

例如，若要计算使用响应和请求 API 的流的 SLO，请测量服务器延迟和请求处理时间。 吞吐量和错误率不适用于连续计算环境，例如虚拟机（VM）、规模集或 Azure Batch。

对于控制平面访问，请考虑 API 响应的错误率和延迟，以及资源创建等长时间运行的操作。 数据平面访问取决于所使用的 API，每个 API 都有其自己的 SLO 目标。

良好的 SLI 显示何时可能会违反 SLO。 它通常以百分位数衡量。 下面是一些常用的百分位数，以及不符合预期可用性的估计时间。

评估Microsoft SLA 的影响

Microsoft SLA 提供对Microsoft提交区域可用性的见解。 SLA 不能保证整体产品/服务。 评估 SLA 时，请充分了解围绕已发布百分位数提供的覆盖率。

请考虑Web 应用，这是Azure App 服务的一项功能。 该功能在给定用例中返回 200 正常 状态时被视为可用。 在该特定上下文和时间范围内，它不涵盖针对简易身份验证或槽切换等功能的可用性提供财务支持的保证。 应考虑协议中未明确提及的区域，因为平台的尽最大努力可用。

因此，如果工作负荷依赖于部署槽位，则无法仅从 App 服务 SLA 派生 SLO。 作为工作负荷团队，你需要对冲和预测运行时间可用性。 但是，这种预测可能不确定，这就是为什么将 SLO 紧密绑定到平台的 SLA 可能会有问题。

请考虑另一个示例。 如果 Azure Front Door 具有 99.99% 的可用性，则设计必须遵循协议中发布的特定标准。 例如，后端必须包含存储，需要一个 GET 操作，该操作可以检索大小至少为 50 KB 的文件，并且需要在至少五个不同地理位置的多个位置跨多个位置部署代理。 这种狭窄的 Azure Front Door 用例不能保证缓存、路由规则或 Web 应用程序防火墙等功能。 这些方面超出了 SLA 的范围。

实现多区域目标

从可靠性的角度来看，多区域部署是冗余原则的实现。 目标是降低区域性服务中断或性能下降的风险。 此策略在设计正确时可以改进 SLO，因为它添加了用于故障转移的次要区域。

有两个主要用例：

• 高可用性模式，可在其中跨区域分配负载，以实现更多容量。 高可用性不会将工作负荷用户限制为区域，整个系统的性能都会导致 SLO。

• 批量模式，可在其中将客户限制为特定区域来细分这些区域。 在这种情况下，将多区域部署视为每个区域中的单独部署或 标记。 使用适用于工作负荷的 SLA 单独测量每个标记的运行状况。 根据每个标记的运行状况考虑总体工作负荷的 SLO。 如果可以在标记之间故障转移，则整个工作负荷 SLO 会更高，因为一个标记中的故障可通过故障转移到另一个标记进行恢复。

权衡：确定风险降低是否值得增加的复杂性。 多区域目标还引入了操作复杂性，例如协调部署、确保数据一致性和处理延迟。 这些操作在恢复期间非常重要。 你的团队应根据增强的复原能力来权衡这些复杂性。

请注意满足高 SLO 所需的冗余量。 例如，Microsoft保证 Azure Cosmos DB 的多区域部署的 SLA 高于单区域部署保证的 SLA。

定义恢复指标

实际恢复目标的定义（如 RTO、RPO、MTTR 和 MTBF 指标）依赖于 故障模式分析和 计划以及测试业务连续性和 灾难恢复。 定义这些目标时，请考虑平台提供的恢复保证。 Microsoft仅对某些产品（如 Azure SQL 数据库）发布 RTO 和 RPO 保证。

在完成这项工作之前，请与利益干系人讨论理想目标，并确保体系结构设计支持最充分地了解恢复目标。 清楚地向利益干系人传达，任何未全面测试恢复指标的流或整个工作负荷都不应保证 SLA。 确保利益干系人明白，随着工作负荷的更新，恢复目标可能会随时间而变化。 添加客户或采用新技术来改善客户体验时，工作负荷可能会变得更加复杂。 这些更改可能会增加或减少恢复指标。

定义恢复目标时，请定义启动恢复的阈值。 例如，如果 Web 节点不可用超过 5 分钟，则会自动向池添加新节点。 定义所有组件的阈值，并考虑特定组件的恢复涉及的内容，包括对其他组件和依赖项的影响。 阈值还应考虑 暂时性故障 ，以确保不会太快地启动恢复操作。 记录并与利益干系人共享恢复操作的潜在风险，例如数据丢失或会话中断。

监视和可视化目标

使用为可靠性目标收集的数据，为每个工作负荷和关联的关键流生成运行状况模型。 运行状况模型定义 流和工作负荷的正常、 降级和 不正常 状态。 状态发生更改时，模型应向相关方发出警报。 有关详细的设计注意事项和建议，请参阅 运行状况建模指南。

若要使运营团队和工作负荷利益干系人保持知情状态，请创建一个可视化效果，反映工作负荷运行状况模型的实时状态和总体趋势。 与利益干系人讨论可视化解决方案，确保提供它们的价值信息，并且易于使用。 他们可能还希望查看每周、每月或季度生成的报表。

Azure 便利化

Azure SLA 为运行时间和连接提供Microsoft承诺。 不同的服务具有不同的 SLA，有时服务中的产品具有不同的 SLA。 有关详细信息，请参阅联机服务的 SLA。

Azure SLA 包括获取服务额度的过程（如果工作负荷不满足 SLA），以及每个服务的可用性定义。 SLA 的此项规定充当强制策略。

浏览可视化系统的 Azure Monitor 仪表板 。

示例

Contoso， Ltd. 正在为其活动票证系统设计新的移动体验。 下面是高级体系结构。

Grafana 徽标是其对应公司的商标。 使用此标志并不意味着认可。

组件

下面是说明 SLO 定义概念的一些组件。 此体系结构中有一些组件未包含在以下列表中。 例如，即使密钥库是关键请求流的一部分，但它不是响应用例的一部分。 如果密钥库不可用，应用程序将继续使用启动期间加载的机密来运行。 但是，如果应用程序需要缩放，密钥库可用性变得至关重要，因为需要使用机密加载新节点。 在此示例中，不考虑缩放操作。 为简洁起见，省略其他组件。

• Azure Front Door 是公开客户用于发送请求的 API 的单一入口点。

• Azure 容器应用 是工作负荷团队拥有并用于为应用程序运行业务逻辑的环境。

• SQL 托管实例由另一个团队拥有和管理，并且是工作负荷的关键依赖项。

• Azure 专用链接提供 Azure Front Door 和容器应用部署之间的专用连接。 SQL 托管实例还通过专用终结点向应用程序公开。

在此体系结构中，API 团队为应用程序中的关键流定义初始 SLO 目标。 他们采用影响 SLO 的因素中所述的策略。 它们旨在定义涵盖核心功能的目标，而无需过度强调补充功能。 它们测量三个关键用户流的运行状况，这些流涉及所有核心云功能，并跨部署执行代码。 但是，这些流并不涵盖所有代码或数据访问。 以下是影响因素。

计算复合 SLO

• Azure 可用性 SLO： Azure 的财务承诺 SLA 充当用于评估平台可靠性的代理。

  Azure 组件	适用的 SLA 覆盖范围	SLA 未涵盖	调整后的 SLO
  Azure Front Door	成功执行 HTTP GET 操作时为 99.99%	缓存，规则引擎	99.98%
  容器应用	99.95% 基于内置入口可访问的已部署应用	自动缩放、令牌存储功能	99.95%
  SQL 托管实例	99.99% 基于与 SQL Server 实例的连接	性能、数据保留	99.80%
  专用链接	99.99% 基于专用终结点网络不接受流量或终结点与专用链接服务之间流动的流量的整分钟数	持续不到一分钟的单个失败	99.99%

  调整基于多个因素，具体取决于工作负荷团队对其目标的承诺。 一个因素可能是基于先前经验对平台功能的信心。 例如，对于容器应用和专用链接，团队会按原样接受 SLA 值。

  还有细微差别的因素。 例如，团队将SQL 托管实例的 SLO 值降低到 99.80%，以考虑其数据操作中的潜在故障，例如架构更改和备份。

  该团队通过计算单个调整后的 SLO 值的影响来设置复合 SLO。 此值为 99.72%。

  还有其他因素。 该体系结构依赖于没有已发布 SLA 的 Azure 网络组件，例如虚拟网络和网络安全组（NSG）。 工作负荷团队决定考虑每个组件可用性为 99.99% 的因素。

  基于预测平台可用性的复合 SLO：每月 99.68%。

• 应用程序代码 SLO： 团队确认其应用程序代码或存储过程中的 bug 可能会影响系统可用性，并分配每月一小时的停机时间来考虑与代码相关的错误。

  它们使用常见的 停机时间百分位数 来估算 SLO 的各个因素，例如代码缺陷、缩放问题和其他与代码相关的注意事项。

  基于代码和数据可用性的复合 SLO：每月 99.86%。

• 资源和应用程序配置 SLO： 团队认识到必须正确配置云资源和应用程序代码。 此目标包括设置自动缩放规则、部署 NSG 规则和选择正确的 SKU 大小。 为了考虑配置错误，他们每月预算 10 分钟的停机时间，即大约 99.98% 的可用性。

  基于配置可用性的复合 SLO：每月 99.95%。

• 运营 SLO： 工作负荷团队遵循卓越运营架构良好的框架原则，开发良好的 DevOps 文化。 部署云资源、配置和代码每个冲刺。

  团队认为部署是一种风险，因为它们可能会破坏正在运行的系统稳定。 TLS 证书更新、DNS 更改或工具错误可能会导致错误。 团队还考虑了紧急修复造成的潜在停机时间。 它们共预算每月停机 20 分钟，大约为 99.95% 的可用性。

  维护时段是指定在系统维护或更新期间发生的时间段。 API 通常每天大约四小时未使用。 为了降低不可用的风险，团队可以在那些不太活跃的时间内计划维护任务。 此方法会导致更高的 SLO，但团队决定不将其作为 SLO 的一部分包含维护时段。

  基于操作可用性的复合 SLO：每月 99.95%。

• 外部依赖项 SLO：团队将SQL 托管实例视为主要依赖项，该依赖项已将 99.80% 的可用性考虑在整体平台可用性中。 不会考虑其他外部依赖项。

  基于外部依赖项的复合 SLO：不适用。

确定总体复合 SLO 结果

总体复合 SLO 目标设置为 99.45%，相当于每月大约 4 小时的停机时间。

为了满足每月仅四个小时不可用的 SLO 目标，工作负荷团队将建立一个呼叫轮换。 客户支持和综合事务监视都可以调用呼叫现场可靠性工程（SRE）支持，以及时启动恢复步骤来解决 SLO 问题。

设置工作负荷 SLA

工作负荷的 SLA 每月可用性为 99.90%。

工作负荷团队的法律和财务部门将工作负荷的 SLA 设置为每月 99.90% 的可用性，超过了 SLO 99.45% 的目标。 他们根据有吸引力的 SLA 分析财务支出与预测的客户增长后做出这一决定。 SLA 涵盖两个核心用户流，并包括性能注意事项，而不仅仅是可用性。 这是业务团队为业务带来利益而承担的计算风险，工程团队意识到了这一承诺。

设置正确性 SLO

应用程序的核心用户流必须可用且具有竞争力，甚至具有竞争力的响应能力。 团队专门为 API 设置响应时间 SLO，不包括客户端处理时间和 Internet 网络遍历。 它们仅在可用性期间评估此 SLO。 选择第 75 百分位作为 SLO 目标和性能度量，它捕获典型的客户体验并排除最坏的情况。

相关链接

Azure 上任务关键型工作负荷的运行状况建模和可观测性

可靠性清单

请参阅完整的建议集。