你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关定义可靠性目标的建议
适用于此 Azure 架构良好的框架的可靠性设计清单建议：
| RE：04 | 为工作负荷定义可靠性和恢复目标。 使用目标来指导你的设计，并作为健康模型的基础。 |
|---|
本指南介绍了为关键工作负荷和流定义可用性和恢复目标指标的建议。 应从与业务利益相关者进行的研讨会练习中制定可靠性目标。 然后通过监视和测试工作负荷来优化这些目标。
与内部利益干系人就工作负荷可靠性设置现实预期。 然后，他们可以使用合同协议将这些期望传达给客户。 现实的期望还有助于利益干系人理解和支持你的体系结构设计决策，并知道你正在设计以最佳方式满足你同意的目标。
请考虑使用以下指标来量化业务需求。
| Term | 定义 |
|---|---|
| 服务级别目标 (SLO) | 衡量工作负荷或应用程序的性能和可靠性。 SLO 是针对特定客户交互设置的特定可度量目标。 这是一个目标，你根据客户期望收到的服务质量为工作负荷或应用程序设置。 |
| 服务级别指示器 （SLI） | 对服务性能的特定方面进行定量度量。 可以使用 SLI 来衡量工作负荷与 SLO 的符合性。 |
| 服务级别协议 (SLA) | 服务提供商和服务客户之间的合同协议。 未能满足协议可能会给服务提供商带来财务后果。 |
| 平均恢复时间（MTTR） | 检测到故障后还原组件所需的时间。 |
| 故障之间的平均时间（MTBF） | 工作负荷能够在不中断的情况下执行预期功能的时间长度，直至发生故障。 |
| 恢复时间目标 (RTO) | 事件发生后应用程序不可用的可接受的最长时间。 |
| 恢复点目标 (RPO) | 事件期间数据丢失的最大可接受持续时间。 |
关键设计策略
可靠性目标表示工作负荷所需的质量目标， 正如其用户和业务利益干系人所承诺的那样。 该目标包括工作负荷的可用性和可恢复性。 请记住，可靠性目标与性能目标不同，但应在可靠性目标中包含性能目标。 请考虑以下可靠性目标：
可用性目标 定义了系统保持可访问性和功能的质量标准。 如果不符合这些标准，则系统被视为不可靠。 使用 SLO 来帮助检查系统是否符合这些标准。 业务和技术利益相关者协作制定切实可行的 SLO，并考虑比较分析、用户体验和工作负载特征等因素。
正确性目标 可确保工作负荷以一致的质量正确执行其功能。 若要衡量正确性，请量化工作负荷的指标，以便将它们合并为统一的目标分数。
恢复目标 对应于 RTO、RPO、MTTR 和 MTBF 指标，用于量化计划和测试业务连续性和灾难恢复的有效性。
为了设置可靠性目标，业务利益干系人定义了广泛的要求。 然后，技术专家评估工作负荷的当前状态，并通过监视和警报实现和维护目标。 双方必须就现实目标达成一致。
根据用户对业务需求的重要性确定和评分用户和系统流 。 使用这些分数来指导工作负荷的设计、评审、测试和事件管理。 为这些流设置可靠性目标，并了解未能满足这些目标可能会显著影响业务。
权衡：系统的技术限制与其业务影响之间可能存在差距，例如吞吐量与每秒处理的事务数量。 弥合这种差距可能很艰难。 旨在实现实用且经济高效的解决方案，而不是过度工程。
设置可用性目标
工作负荷的总体 SLO 反映了 整体质量，包括其所有依赖项。 SLO 的成熟声明应指示该工作负荷的总体业务目标，而不仅仅是这些依赖项的组合。 例如，如果客户需要 99.99% 的可用性，则总体 SLO 应面向该目标，即使一部分仅达到 99.80%。
利益干系人评估客户体验，并考虑停机时间如何影响收入。 它们将此损失与设计和运营业务流的成本进行比较。 然后，决策者决定他们是否应该花更多的钱在可靠性上，以避免收入损失并保持他们的声誉。
工作负荷所有者 使用财务目标来确定目标。 业务要求映射到可衡量的指标。 目标是确定一组影响客户体验质量的因素。
工作负荷架构师 根据 SLO 做出许多技术决策。 SLO 可以：
在考虑其他依赖项时，作为体系结构决策的关键输入。
提供近乎实时的视图和对工作负载健康状况的共同理解，以促进客观讨论。 他们还帮助工作负荷团队确定工作优先级，以提高可靠性和开发新功能。
作为部署操作的关键信号，在出现问题时驱动自动回滚，并验证更改是否实现了客户体验的预期改进。
通过专注于目标、向客户发送问题的自动通知以及在你的组织中的团队之间建立信任来加快修正和恢复。
重要
你必须知道 SLA 和 SLO 之间的差异。 尽管 SLA 和 SLO 可能使用甚至显示类似的数据，但其意图不同。 SLA 是组织与其客户之间的正式合同，如果组织未能兑现其承诺，它将对财务和法律产生直接影响。 组织使用 SLO 来评估潜在的停机时间是否处于可容忍的限制范围内。
SLO 和 SLA 具有业务关系，应该独立管理。 如果 SLA 充当业务策略，组织可能会根据业务所有者的目标有意将其设置为高价值。 相反，SLO 可能会更高。 以任务关键型工作负荷为例。 此工作负荷类无法承受长时间的停机时间，因为影响（包括财务损失，甚至对人类安全的威胁）非常重要。 因此，SLO 通常以 99.999% 的正常运行时间为目标，常被称为五个九。 如果 SLO 不符合这些目标，组织必须迅速做出反应，以缓解故障并防止 SLA 失败的结果。
本文中的示例设置高 SLA 以支持业务目标。
云平台和技术提供商在其产品/服务上发布 SLA。 应将 SLA 视为 SLO 计算的一部分，但不应在不了解 SLA 覆盖范围的情况下直接使用它们。 有关详细信息，请参阅 评估Microsoft SLA 的影响。
考虑常见的 SLO 和影响因素
每个 SLO 都针对特定的质量标准。 请考虑这些常见的 SLO，以确保可靠性。 此列表并不详尽。 请根据业务需求添加 SLO。
成功率 衡量请求和进程的成功次数与返回错误或任务失败次数之间的关系。
延迟 测量启动操作请求的时间以及结果可用或进程完成之间的时间。
容量衡量并发使用情况，例如基于限制的响应数量。
可用性 从客户的角度衡量运行时间。
吞吐量 测量一定时间内的最小数据传输速率。 吞吐量测量为数据速率单位，例如每秒事务数（TPS）或每秒请求数（RPS）。
了解 Azure 上工作负荷的方案和容忍度。 Azure 服务和应用程序组件都影响工作负荷 SLO。 合并下表中的响应以得出整体 SLO。 使用这些问题作为示例来评估工作负荷组件的用处。
| 组件特征 | 客户交互 | 其他因素 |
|---|---|---|
| - 它是否公开 请求或响应 API？ - 它是否具有 查询 API？ - 它是 计算机 组件吗？ - 是否是作业处理组件？ |
- 面向公众的 Azure 服务的控制平面和管理平面访问。 - 数据平面访问，例如创建、读取、更新和删除（CRUD）操作。 |
- 发布过程是否涉及停机时间？ - 引入错误的可能性有多大？ 如果工作负荷与其他系统集成，您可能需要考虑集成错误。 - 例程操作（如修补）如何影响可用性目标？ 你是否考虑了合作伙伴依赖项？ - 你的 人员是否 足以支持持续紧急和紧急备份的呼叫轮换？ - 应用程序是否有超出你控制范围的近邻干扰，这可能会导致中断？ |
确定 SLO 范围
可以在各种级别（例如针对系统中的每个应用程序、工作负荷或特定流）设置 SLO。 设置特定级别的 SLO，以便你可以根据每个组件的重要性自定义 SLO。
在软件即服务（SaaS）解决方案中，衡量每个客户的 SLO，以优化每个客户体验。 客户可能在其细分市场中具有不同的基础结构资源。 对于这种情况，在整个系统范围内聚合跨客户细分的所有资源的 SLO 可能没有意义。 相反，衡量与每个客户的特定背景相一致的 SLO。 有关详细信息，请参阅 多租户解决方案的租赁模型。
定义复合 SLO 目标
SLO 必须是可测量的，并在可观测性窗口中进行测量。
SLO 通常是 99.90% 这样的百分比，但它们也可以是语句。 使用这两种方法获取包含所有因素的数值。
SLO 由定义可接受因素的可测量 SLI 组成。 SLI 是具有设定阈值并且可以发出警报的指标。 可以从平台或应用程序收集它们。 不同的组件发出相关的 SLI。 选择 SLI 时，请考虑影响 SLO 的因素。
例如，若要计算使用响应和请求 API 的流的 SLO，请测量服务器延迟和请求处理时间。 吞吐量和错误率不适用于连续计算环境，例如虚拟机（VM）、规模集或 Azure Batch。
对于控制平面访问，请考虑 API 响应的错误率和延迟，以及资源创建等长时间运行的操作。 数据平面访问取决于所使用的 API，每个 API 都有其自己的 SLO 目标。
一个好的 SLI 会告诉你什么时候可能违反 SLO。 它通常以百分位数衡量。 下面是一些常用的百分位数，以及不符合预期可用性的估计时间。
| 目标 | 每周不合规情况 | 每月不合规情况 | 每年不合规情况 |
|---|---|---|---|
| 99% | 1.68 小时 | 7.20 小时 | 3.65 天 |
| 99.90% | 10.10 分钟 | 43.20 分钟 | 8.76 小时 |
| 99.95% | 5 分钟 | 21.60 分钟 | 4.38 小时 |
| 99.99% | 1.01 分钟 | 4.32 分钟 | 52.56 分钟 |
| 99.999% | 6 秒 | 25.90 秒 | 5.26 分钟 |
重要
复合 SLO 值是贡献因素的产品分布。
示例复合 SLO 为 99.95% × 99.99999% = 约 99.95%。
为不同的流创建复合 SLO 时，请考虑其不同的关键性和相关性。 流可能包含被视为非关键性的组件，并且您可以从计算中省略这些组件。 你可以根据它们的短暂不可用性是否影响客户体验来证明遗漏是合理的。 在某些情况下，组件可能与你为 SLO 考虑的用例无关。 也可以从计算中省略这些组件。
相同的原则适用于操作。 某些操作可能会带来风险或影响 SLO，而其他操作则微不足道。 这一决定应明确，并建立在共识的基础上。
有关如何定义和度量 SLO 和 SLA 的演示示例，请参阅“示例”部分。
评估Microsoft SLA 的影响
Microsoft SLA 提供了对 Microsoft 承诺领域可用性的见解。 SLA 不能保证产品/服务的整体。 评估 SLA 时，请充分了解在已发布百分位数基础上所提供的覆盖范围。
请考虑Web 应用，这是Azure App 服务的一项功能。 该功能在给定用例中返回 200 正常 状态时被视为可用。 在特定的背景和时间范围内，它不包括对简易身份验证或插槽切换等功能可用性的财务支持保证。 应该将协议中未明确提及的领域视为平台尽最大努力可用的领域。
因此，如果工作负荷依赖于部署槽位，则不能仅从应用程序服务 SLA 中导出 SLO。 作为工作负载团队，你需要规避风险并预测系统可用性。 然而，这种预测可能是不确定的，这就是为什么将你的 SLO 与平台的 SLA 紧密联系起来可能会有问题。
请考虑另一个示例。 如果 Azure Front Door 具有 99.99% 的可用性，则设计必须遵循协议中发布的特定标准。 例如，后端必须包含存储，需要一个 GET 操作，该操作可以检索大小至少为 50 KB 的文件，并且需要在至少五个不同地理位置的多个位置跨多个位置部署代理。 这种狭窄的 Azure Front Door 用例不能保证缓存、路由规则或 Web 应用程序防火墙等功能。 这些方面超出了 SLA 的范围。
实现多区域目标
从可靠性的角度来看，多区域部署是冗余原则的实现。 目标是降低区域性服务中断或性能下降的风险。 此策略在设计正确时可以改进 SLO，因为它添加了用于故障转移的次要区域。
有两个主要用例：
高可用性模式，可在其中跨区域分配负载，以实现更多容量。 高可用性不会将工作负载用户限制在某个区域，整个系统的性能都会影响 SLO。
隔舱模式，将客户限制在特定区域以对其进行细分。 在这种情况下，将多区域部署视为单独的部署，或者在每个区域中标记。 使用适用于工作负荷的 SLI 单独测量每个标记的运行状况。 根据每个标记的运行状况考虑整体工作负荷的 SLO。 如果可以在标记之间进行故障转移，那么整体工作负荷 SLO 就会更高，因为一个标记中的故障可以通过故障转移到另一个标记来恢复。
请注意你需要多少冗余才能满足高 SLO。 例如，Microsoft保证 Azure Cosmos DB 的多区域部署的 SLA 高于单区域部署保证的 SLA。
定义恢复指标
实际恢复目标的定义（如 RTO、RPO、MTTR 和 MTBF 指标）依赖于 故障模式分析和 计划以及测试业务连续性和 灾难恢复。 定义这些目标时，请考虑平台提供的恢复保证。 Microsoft仅对某些产品（如 Azure SQL 数据库）发布 RTO 和 RPO 保证。
在完成这项工作之前，请与利益相关者讨论愿景目标，并确保您的体系结构设计根据您最大的理解支持恢复目标。 明确地向利益干系人传达，任何未经过彻底恢复指标测试的流或整个工作负荷都不应该有保证的 SLA。 确保利益干系人明白，随着工作负荷的更新，恢复目标可能会随时间而变化。 添加客户或采用新技术来改善客户体验时，工作负荷可能会变得更加复杂。 这些更改可能会增加或减少恢复指标。
注意
定义和保证 MTBF 具有挑战性。 平台即服务（PaaS）或 SaaS 模型可以在没有云提供商的任何通知的情况下失败和恢复，并且该过程对你或你的客户完全透明。 如果为此指标定义目标，则仅涵盖你控制下的组件。
定义恢复目标时，请定义启动恢复的阈值。 例如，如果 Web 节点不可用超过 5 分钟，则会自动向池添加新节点。 定义所有组件的阈值，并考虑特定组件的恢复涉及的内容，包括对其他组件和依赖项的影响。 阈值还应考虑 暂时性故障 ，以确保不会太快地启动恢复操作。 记录并与利益干系人共享恢复操作的潜在风险，例如数据丢失或会话中断。
监视和可视化目标
使用为可靠性目标收集的数据，为每个工作负荷和关联的关键流生成运行状况模型。 运行状况模型定义 流和工作负荷的正常、 降级和 不正常 状态。 状态发生更改时，模型应向相关方发出警报。 有关详细的设计注意事项和建议，请参阅 健康建模指南。
若要使运营团队和工作负荷利益干系人保持知情状态，请创建一个可视化效果，反映工作负荷运行状况模型的实时状态和总体趋势。 与利益干系人讨论可视化解决方案，确保提供它们的价值信息，并且易于使用。 他们可能还希望查看每周、每月或季度生成的报表。
Azure 便利化
Azure 服务级别协议提供了微软的正常运行时间和连接的承诺。 不同的服务具有不同的 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 目标。 他们采用了在影响 SLOs 的因素中描述的策略。 它们旨在定义涵盖核心功能的目标，而无需过度强调补充功能。 它们测量三个关键用户流的运行状况，这些流涉及所有核心云功能，并跨部署执行代码。 但是，这些流并不涵盖所有代码或数据访问。 以下是影响因素。
计算复合 SLO
Azure 可用性 SLO： Azure 的财务承诺 SLA 充当用于评估平台可靠性的代理。
Azure 组件 适用的 SLA 覆盖范围 SLA 未涵盖 调整后的 SLO Azure Front Door（Azure 前端门） 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 每月可用性为 99.90%。
工作负荷团队的法律和财务部门将工作负荷的 SLA 设置为每月 99.90% 的可用性，超过了 SLO 99.45% 的目标。 他们根据有吸引力的 SLA 分析财务支出与预测的客户增长后做出这一决定。 SLA 涵盖两个核心用户流，并包括性能注意事项，而不仅仅是可用性。 这是业务团队为业务带来利益而承担的计算风险，工程团队意识到了这一承诺。
设置正确性 SLO
应用程序的核心用户流必须有且可使用，或者甚至具有竞争力、响应迅速。 团队专门为 API 设置响应时间 SLO，不包括客户端处理时间和 Internet 网络遍历。 他们仅在可用期间评估此 SLO。 选择第 75 百分位作为 SLO 目标和性能度量，它捕获典型的客户体验并排除最坏的情况。
相关链接
可靠性清单
请参阅完整的建议集。