你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

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

适用于此 Azure Well-Architected 框架可靠性清单建议：

RE：04	为组件、流和整体解决方案定义可靠性和恢复目标。 可视化目标，以协商、达成共识、设定期望并推动行动来实现理想状态。 使用定义的目标生成运行状况模型。 运行状况模型定义正常、降级和不正常状态的外观。

本指南介绍有关为关键工作负载和流定义可用性和恢复目标指标的建议。 可靠性目标是通过与业务利益干系人进行研讨会练习得出的。 通过监视和测试来优化目标。

与内部利益干系人一起，为工作负载可靠性设定现实的期望，以便利益干系人可以通过合同协议将这些期望传达给客户。 现实的期望还有助于利益干系人理解和支持你的体系结构设计决策，并知道你正在设计以最佳方式满足你商定的目标。

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

术语	定义
服务级别目标 (SLO)	表示组件和可靠性层运行状况的百分比目标。 层越高，组件越可靠。 复合 SLO 表示整个工作负荷的聚合目标，并考虑组件 SLO。
服务级别指示器 (SLI)	服务发出的指标。 聚合 SLI 指标以量化 SLO 值。
服务级别协议 (SLA)	服务提供商和服务客户之间的合同协议。 协议定义 SLO。 未能履行协议可能会给服务提供商带来财务后果。
(MTTR) 恢复的平均时间	检测到故障后还原组件所花费的时间。
平均故障 (MTBF)	工作负荷可以在不中断的情况下执行预期功能的持续时间，直到它失败为止。
恢复时间目标 (RTO)	发生某个事件后，可接受应用程序不可用的最长时间。
恢复点目标 (RPO)	事件期间数据丢失的最长可接受持续时间。

在用户流和系统流的上下文中为这些指标定义工作负载的目标值。 根据这些流对需求的关键程度来识别这些流并评分。 使用 值在体系结构、评审、测试和事件管理操作方面推动工作负载的设计。 未能达到目标会影响超出容错级别的业务。

关键设计策略

技术讨论不应推动你为关键流定义可靠性目标的方式。 相反，业务利益干系人应在定义工作负载要求时关注客户。 技术专家帮助利益干系人分配与这些要求相关的实际数值。 在分享知识时，技术专家允许就现实的 SLO 进行谈判和共同共识。

假设有一个示例，说明如何将需求映射到可衡量的数值。 利益干系人估计，对于关键用户流，在正常营业时间停机一小时会导致每月收入损失 X 美元。 这一美元金额与设计可用性 SLO 为 99.95% 而不是 99.9% 的流的估计成本进行比较。 决策者必须讨论这种收入损失的风险是否超过增加的成本和管理负担，以防范这种损失。 在检查流并生成目标的完整列表时，请遵循此模式。

请记住，可靠性目标不同于性能目标。 可靠性目标侧重于可用性和恢复。 若要设置可靠性目标，请首先定义最广泛的要求，然后定义更具体的指标以满足高级要求。

最高级别的可靠性和恢复要求以及相关的指标可能包括，例如，所有区域的应用程序可用性为 99.9%，或美洲区域的目标 RTO 为 5 小时。 定义这些目标类型有助于确定这些目标中涉及的关键流。 然后，可以考虑组件级目标。

权衡：工作负载组件的技术限制与对业务的意义之间存在概念上的差距，例如，每秒兆位吞吐量与每秒事务数。 在这两个视图之间创建模型可能具有挑战性。 与其过度制定解决方案，不如尝试以经济但有意义的方式处理它。

可用性指标

SLO 和 SLA

可用性指标与用于定义 SLA 的 SLO 相关联。 工作负荷 SLO 确定在给定时间段内可容忍的停机时间，例如，每月少于 1 小时。 若要确保满足 SLO 目标，请查看每个组件的 Microsoft SLA。 请注意满足高 SLA 所需的冗余量。 例如，Microsoft 保证 Azure Cosmos DB 多区域部署的 SLA 高于单区域部署的 SLA。

注意

Azure SLA 并不总是涵盖服务的各个方面。 例如，Azure 应用程序网关具有可用性 SLA，但 Azure Web 应用程序防火墙功能不提供阻止恶意流量通过的保证。 开发 SLA 和 SLO 时，请考虑此限制。

收集单个工作负荷组件的 SLA 后，计算复合 SLA。 复合 SLA 应与工作负荷的目标 SLO 匹配。 计算复合 SLA 涉及多个因素，具体取决于体系结构设计。 请考虑以下示例。

注意

以下示例中的 SLA 值是假设的，仅用于演示目的。它们不用于表示 Microsoft 支持的当前值。

复合 SLA 涉及多个支持应用程序的服务，可用性级别不同。 例如，假设有一个写入 Azure SQL 数据库的 Azure 应用服务 Web 应用。 假设这些 SLA 可能是：

• App 服务 Web 应用 = 99.95%
• SQL 数据库 = 99.99%

此应用程序预计的最长停机时间是多少？ 如果任一服务发生故障，整个应用程序也会发生故障。 每个服务失败的概率都是独立的，因此此应用程序的复合 SLA 为 99.95%，× 99.99% = 99.94%。 该值低于单个 SLA。 这一结论并不奇怪，因为依赖于多个服务的应用程序具有更多的潜在故障点。

你可以通过创建独立的回退路径来提高复合 SLA。 例如，如果 SQL 数据库不可用，可将事务放入队列供稍后处理：

在此设计中，即使应用程序无法连接到数据库，应用程序也仍然可用。 但是，如果数据库和队列同时失败，则失败。 同时失败的预期时间百分比为 0.0001 × 0.001，因此下面是此组合路径的复合 SLA：

数据库或队列 = 1.0 • (0.0001 × 0.001) = 99.99999%

总复合 SLA：

Web 应用和 (数据库或队列) = 99.95% × 99.99999% = ~99.95%

此方法会产生权衡：

• 应用程序逻辑更为复杂。
• 你为队列付费。
• 需要考虑数据一致性问题。

对于多区域部署，复合 SLA 的计算方式如下：

• N 是部署在一个区域中的应用程序的复合 SLA。

• R 是部署应用程序的区域数。

应用程序在所有区域中同时发生故障的预期几率为 ((1 − N) ^ R)。 例如，如果假设的单区域 SLA 为 99.95%，则为：

• 两个区域的组合 SLA = (1 • (1 ≤ 0.9995) ^ 2) = 99.999975%

• 四个区域的组合 SLA = (1 • (1 ≤ 0.9995) ^ 4) = 99.999999%

定义适当的 SLO 需要时间和仔细考虑。 业务利益干系人应了解关键客户如何使用应用。 他们还应该了解可靠性容忍度。 此反馈应告知目标。

SLA 值

下表定义了常见的 SLA 值。

SLA	每周停机时间	每月故障时间	每年停机时间
99%	1.68 小时	7.2 小时	3.65 天
99.9%	10.1 分钟	43.2 分钟	8.76 小时
99.95%	5 分钟	21.6 分钟	4.38 小时
99.99%	1.01 分钟	4.32 分钟	52.56 分钟
99.999%	6 秒	25.9 秒	5.26 分钟

在考虑流上下文中的复合 SLA 时，请记住，不同的流具有不同的关键性定义。 生成复合 SLA 时，请考虑这些差异。 非关键流可能包含应该从计算中省略的组件，因为它们在短暂不可用时不会影响客户体验。

注意

面向客户的工作负载和内部使用的工作负载具有不同的 SLO。 通常，与面向客户的工作负载相比，内部使用工作负载的可用性 SLO 的限制要小得多。

SLI

将 SLI 视为影响 SLO 的组件级指标。 从客户的角度来看，最重要的 SLI 是影响关键流的 SLI。 对于许多流，SLI 包括延迟、吞吐量、错误率和可用性。 良好的 SLI 可帮助你识别 SLO 何时面临被违反的风险。 尽可能将 SLI 关联到特定客户。

若要避免收集无用指标，请限制每个流的 SLI 数。 如果可能，每个流的目标为三个 SLI。

恢复指标

恢复目标对应于 RTO、RPO、MTTR 和 MTBF 指标。 与可用性目标相比，这些度量的恢复目标并不严重依赖于 Microsoft SLA。 Microsoft 仅对某些产品（如SQL 数据库）发布 RTO 和 RPO 保证。

现实恢复目标的定义依赖于 故障模式分析 以及业务连续性和 灾难恢复的计划与测试。 在完成此工作之前，请与利益干系人讨论期望的目标，并确保体系结构设计支持你最了解的恢复目标。 向利益干系人明确表明，任何未针对恢复指标进行全面测试的流或整个工作负载都不应保证 SLA。 确保利益干系人了解，随着工作负载的更新，恢复目标可能会随时间而变化。 随着客户添加或采用新技术来改善客户体验，工作负载可能会变得更加复杂。 这些更改可能会增加或减少恢复指标。

注意

MTBF 在定义和保证上可能具有挑战性。 平台即服务 (PaaS) 或软件即服务 (SaaS) 可能会失败并恢复，而无需从云提供商处获得任何通知，并且该过程对你或你的客户可能完全透明。 如果为此指标定义目标，请仅涵盖受你控制的组件。

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

生成运行状况模型

使用针对可靠性目标收集的数据，为每个工作负载和关联的关键流生成运行状况模型。 运行状况模型为流和工作负载定义 正常、 降级和 不正常 状态。 状态可确保适当的操作优先级。 此模型也称为 交通灯模型。 该模型为“正常”分配绿色，为“降级”分配黄色，为“不正常”分配红色。 运行状况模型可确保知道流的状态何时从正常更改为降级或不正常。

定义正常、降级和不正常状态的方式取决于可靠性目标。 下面是一些可以定义状态的方法示例：

• 绿色或正常状态表示完全满足关键非功能性要求和目标，并且资源得到最佳利用。 例如，95% 的请求在 =500 毫秒内<处理，Azure Kubernetes 服务 (AKS) 节点的使用量为 X%。

• 黄色或降级状态表示流的一个或多个组件针对其定义的阈值发出警报，但流可正常运行。 例如，检测到存储限制。

• 红色或不正常状态表示降级的持久性超过可靠性目标允许的时间，或者流变得不可用。

注意

运行状况模型不应将所有故障视为相同。 运行状况模型应区分 暂时性 故障 和非过渡 性故障。 其应清楚地区分预期中的暂时性但可恢复的故障和真正的灾难状态。

此模型的工作原理是使用根据持续改进原则开发和运行的监视和警报策略。 随着工作负载的发展，运行状况模型必须随之演变。

有关分层应用程序运行状况模型的详细设计注意事项和建议，请参阅任务关键型工作负载设计区域中的 运行状况建模指南 。 有关监视和警报配置的详细指南，请参阅 运行状况监视 指南。

可视化效果

若要使运营团队和工作负载利益干系人随时了解工作负载运行状况模型的实时状态和总体趋势，请考虑在监视解决方案中创建 仪表板 。 与利益干系人讨论可视化解决方案，以确保提供他们重视且易于使用的信息。 他们可能还希望每周、每月或每季度查看生成的报告。

Azure 简化

Azure SLA 提供 Microsoft 对运行时间和连接的承诺。 不同的服务具有不同的 SLA，有时服务中的 SKU 具有不同的 SLA。 有关详细信息，请参阅联机服务的服务级别协议。

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

相关链接

• 用于运行状况建模的 Well-Architected Framework 任务关键型指南： Azure 上任务关键型工作负载的运行状况建模和可观测性

可靠性清单

请参阅完整的一组建议。

可靠性清单