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

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

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

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

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

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

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

术语	定义
服务级别目标 （SLO）	衡量工作负荷或应用程序的性能和可靠性。 SLO 是针对特定客户交互设置的特定可度量目标。 它是一个目标，你根据用户预期收到的服务质量为应用程序设置的工作负荷。
服务级别指示器 （SLI）	服务发出的指标。 SLI 指标聚合以量化 SLO 值。
服务级别协议 (SLA)	服务提供商和服务客户之间的合同协议。 未能满足协议可能会给服务提供商带来财务后果。
平均恢复时间（MTTR）	检测到故障后还原组件所需的时间。
故障之间的平均时间（MTBF）	工作负荷可以在不中断的情况下执行预期函数的持续时间，直到失败。
恢复时间目标 (RTO)	发生某个事件后，可接受应用程序不可用的最长时间。
恢复点目标 (RPO)	事件期间数据丢失的最大可接受持续时间。

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

关键设计策略

技术讨论不应推动如何为关键流定义可靠性目标。 相反，业务利益干系人应专注于客户，因为他们定义了工作负荷的要求。 技术专家帮助利益干系人分配与这些要求相关的现实数值。 当他们分享知识时，技术专家允许就现实SLO进行谈判和相互共识。

请考虑如何将要求映射到可度量数值的示例。 利益干系人估计，对于关键用户流，常规工作时间的停机一小时会导致每月收入损失 X 美元。 与设计可用性 SLO 为 99.95% 而不是 99.9% 的流的估计成本进行比较。 决策者必须讨论该收入损失的风险是否超过防止收入损失所需的额外成本和管理负担。 检查流并生成目标的完整列表时，请遵循此模式。

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

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

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

可用性指标

SLA 和 SLA

SLO 是工作负荷或应用程序的性能和可靠性的度量值。 SLO 是针对特定客户交互设置的特定可度量目标。 这是针对用户预期收到的服务质量为工作负荷或应用程序设置的目标。

可以使用各种指标（例如可用性、响应时间、吞吐量、成功率等）来定义 SLO。 例如，Web 服务的 SLO 可能是给定月份用户 99.9% 的时间可用，或者它将在 500 毫秒内响应 95% 的请求。

在为应用程序或工作负荷定义 SLA 之前，请查看托管应用程序或工作负荷的基础服务的已发布 SLA Microsoft。

注意

Microsoft服务 SLA 不是 平台 SLA 或 SLO

查看每个服务的 SLA 时，请注意满足高 SLA 所需的冗余量。 例如，Microsoft保证 Azure Cosmos DB 的多区域部署 SLA 高于单区域部署保证的 SLA。

注意

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

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

注意

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

复合 SLA 涉及多个支持应用程序的服务，其可用性级别不同。 例如，请考虑写入Azure SQL 数据库的 Azure App 服务 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。 通常，内部使用工作负载的可用性 SLA 可能比面向客户的工作负荷要少得多。

SLA

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

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

恢复指标

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

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

注意

MTBF 在定义和保证时可能很困难。 平台即服务（PaaS）或软件即服务（SaaS）可以在没有云提供商的任何通知的情况下失败和恢复，并且该过程对你或客户完全透明。 如果为此指标定义目标，则仅涵盖你控制下的组件。

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

生成运行状况模型

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

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

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

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

• 红色或不正常状态表示降级的保留时间比可靠性目标允许的要长，或者流变得不可用。

注意

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

此模型的工作原理是使用开发和操作持续改进原则的监视和警报策略。 随着工作负载的发展，运行状况模型必须随它们一起发展。

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

可视化效果

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

Azure 便利化

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

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

相关链接

• 运行状况建模的架构完善的框架任务关键型指南： Azure 上任务关键型工作负荷的运行状况建模和可观测性

可靠性清单

请参阅完整的建议集。

可靠性清单