你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关定义可靠性目标的建议
适用于此 Azure 架构良好的框架可靠性清单建议：
| RE：04 | 为组件、流和整体解决方案定义可靠性和恢复目标。 直观显示要协商、达成共识、设定期望并推动行动实现理想状态的目标。 使用定义的目标生成运行状况模型。 运行状况模型定义运行状况、降级和不正常状态的外观。 |
|---|
本指南介绍了为关键工作负荷和流定义可用性和恢复目标指标的建议。 应从与业务利益干系人进行研讨会练习中获取可靠性目标。 然后通过监视和测试工作负荷来优化这些目标。
与内部利益干系人就工作负荷可靠性设置现实预期。 然后，他们可以使用合同协议将这些期望传达给客户。 现实的期望还有助于利益干系人理解和支持你的体系结构设计决策，并知道你正在设计以最佳方式满足你同意的目标。
请考虑使用以下指标来量化业务需求。
| 术语 | 定义 |
|---|---|
| 服务级别目标 （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 和 SLA 之间的差异。 尽管 SLA 和 SLA 可能使用甚至显示类似的数据，但其意图不同。 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）操作。 |
- 发布 过程 是否涉及停机时间？ - 引入 bug 的可能性是多少？ 如果工作负荷与其他系统集成，可能需要考虑集成 bug。 - 例程操作（如修补）如何影响可用性目标？ 你是否考虑了合作伙伴依赖项？ - 你的 人员是否 足以支持持续紧急和紧急备份的呼叫轮换？ - 应用程序是否在控制范围之外具有 干扰邻居 ，这可能会导致中断？ |
确定 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。 它通常以百分位数衡量。 下面是一些常用的百分位数，以及不符合预期可用性的估计时间。
| 目标 | 每周不合规 | 每月不合规 | 每年不合规 |
|---|---|---|---|
| 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 正常 状态时被视为可用。 在该特定上下文和时间范围内，它不涵盖针对简易身份验证或槽切换等功能的可用性提供财务支持的保证。 应考虑协议中未明确提及的区域，因为平台的尽最大努力可用。
因此，如果工作负荷依赖于部署槽位，则无法仅从 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。 确保利益干系人明白，随着工作负荷的更新，恢复目标可能会随时间而变化。 添加客户或采用新技术来改善客户体验时，工作负荷可能会变得更加复杂。 这些更改可能会增加或减少恢复指标。
注意
MTBF 在定义和保证时可能很困难。 平台即服务（PaaS）或 SaaS 模型可以在没有云提供商的任何通知的情况下失败和恢复，并且该过程对你或你的客户完全透明。 如果为此指标定义目标，则仅涵盖你控制下的组件。
定义恢复目标时，请定义启动恢复的阈值。 例如，如果 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 目标和性能度量，它捕获典型的客户体验并排除最坏的情况。
相关链接
可靠性清单
请参阅完整的建议集。