定义可靠性目标的建议
适用于此 Power Platform Well-Architected 可靠性检查表建议：
| 回复：04 | 为组件、流和整体解决方案定义可靠性和恢复目标。 将谈判目标可视化、达成共识、设定期望、推动操作以达到理想状态。 使用定义的目标生成运行状况模型。 运行状况模型定义正常、降级和不正常状态的外观。 |
|---|
本指南介绍为关键工作负荷定义可用性和恢复目标指标的建议。 可靠性目标通过与业务利益干系人进行研讨会练习得出。
通过监视和测试对目标进行改进。 与内部利益干系人一起建立对可靠性的现实期望。 此练习还将帮助利益干系人支持您的架构设计选择，并了解您的设计是为了最好地实现你们商定的目标。
Microsoft Power Platform 为您处理大多数基础结构级别的可用性和可靠性问题。 但是，您构建的工作负荷的可用性是一项共同责任。 重要的是要了解，即使 Microsoft 致力于高可用性，系统停机的风险也永远不会为零。
考虑使用以下指标来量化业务要求
| 术语 | 定义 |
|---|---|
| 服务级别目标 (SLO) | 表示组件运行状况和可靠性级别的百分比目标。 级别越高，组件越可靠。 复合 SLO 表示整个工作负载的聚合目标，并考虑组件 SLO。 |
| 服务级别指标 (SLI) | 服务发出的指标。 聚合 SLI 指标来量化 SLO 值。 |
| 服务级别协议 (SLA) | 服务提供商和服务客户之间的合同协议。 此协议定义 SLO。 未能履行协议可能会给服务提供商带来财务影响。 |
| 平均恢复时间 (MTTR) | 检测到故障后恢复组件所花费的时间。 |
| 故障平均间隔时间 (MTBF) | 工作负荷在失败之前可以在不中断的情况下执行预期功能的持续时间。 |
| 恢复时间目标 (RTO) | 事件发生后应用程序不可用的最长可接受时间。 |
| 恢复点目标 (RPO) | 事件期间数据丢失的最大可接受持续时间。 |
在用户和系统流的上下文中为这些指标定义工作负荷的目标值。 根据这些流对您的需求的重要性来识别这些流 并对其进行评分。 使用这些值在体系结构、审查、测试和事件管理操作方面推动工作负荷的设计。 未能达到目标将对业务造成超出容忍水平的影响。
关键设计策略
技术讨论不应推动您如何定义关键流的可靠性目标。 业务利益干系人应该关注他们的要求和工作负荷最终用户的期望。 技术专家可帮助利益干系人分配符合这些要求的实际数值。 通过交换信息，技术专家能够就可行的 SLO 进行讨论并达成一致。
考虑一个如何将要求映射到可度量数值的示例。 利益干系人估计，对于关键用户流，在正常工作时间内停机一小时会导致月收入损失 X 美元。 将该美元金额与设计可用性 SLO 为 99.95% 而非 99.9% 的流的估计成本进行比较。 决策者必须讨论收入损失的风险是否超过了防范收入损失所需的额外成本和管理负担。
在检查流和构建完整的目标列表时采取此模式。
记住可靠性目标和性能目标不同。 可靠性目标侧重于可用性和恢复。 要设置可靠性目标，首先定义最广泛的要求，然后定义更具体的指标来满足高级要求。
最高级别的可靠性和恢复要求以及相关指标可能包括，例如，所有区域 99.9% 的应用程序可用性，或美洲地区 5 小时的目标 RTO。 定义这些类型的目标可帮助您确定这些目标涉及哪些关键流。 然后可以考虑组件级别的目标。
可用性指标
可用性目标对应于 SLO、SLA 和 SLI 指标。
SLO 和 SLA
可用性指标与用于定义 SLA 的 SLO 相关。 工作负荷 SLO 确定在给定时间段内可容忍的停机时间；例如，每月少于 1 小时。 要确保您可以满足 SLO 目标，请查看 Microsoft 每个组件的 SLA。
要建立 SLO，考虑：
未来 1-2 年内您的工作负荷的非功能性要求（例如，峰值请求率、并发用户）。
在特定时间段内您可以用来进行度量的可用指标。 此数据将告知要指定的 SLI。
收集各个工作负荷组件的 SLA 后，计算复合 SLA。 复合 SLA 应与工作负荷的目标 SLO 匹配。 计算复合 SLA 涉及多个因素，具体取决于您的体系结构设计。
定义适当的 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 时考虑这些差异。 非关键流可能有一些组件应该从计算中省略，因为如果这些组件暂时不可用，不会影响客户体验。
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) 可能会在没有云提供商任何通知的情况下发生故障和恢复，此过程对于您会完全透明。 如果您定义此指标的目标，仅包含您所控制的组件。
构建运行状况模型
使用您为可靠性目标收集的数据，为每个工作负荷和相关的关键流构建运行状况模型。 运行状况模型为流和工作负荷定义正常、降级和*不正常*状态。 这些状态确保适当的操作优先级。 此模型也称为交通灯模型。 此模型将绿色指定为正常，黄色为降级，红色为不正常。 运行状况模型可确保您知道流的状态何时从正常变为降级或不正常。
如何定义正常、降级和不正常状态取决于您的可靠性目标。 以下是定义状态的一些方法示例：
绿色或正常状态表示关键的非功能要求和目标已完全满足，资源得到最佳使用。
黄色或降级状态表示流的一个或多个组件在针对其定义的阈值发出警报，但流可以操作。 例如，检测到存储限制。
红色或不正常状态表示降级持续时间超过可靠性目标允许的时间，或者流不可用。
备注
运行状况模型不应该对所有故障一视同仁。 Health 模型应区分 瞬态 故障和非 瞬态 故障。 它应该清楚地区分预期暂时但可恢复的故障和真正的灾难状态。
此模型使用基于持续改进原则制定和运行的监视和警报策略工作。 随着工作负荷的发展，您的运行状况模型也必须随之发展。
有关监视和警报配置的详细指导，请参阅运行状况监视指南。
可视化效果
要让您的运营团队和工作负荷利益干系人了解工作负荷运行状况模型的实时状态和总体趋势，考虑在您的监视解决方案中创建仪表板。 与利益干系人讨论可视化解决方案，确保您提供他们重视且易于使用的信息。 他们可能还希望每周、每月或每季度看到生成的报告。
Power Platform 便利化
Power Platform SLA 提供 Microsoft 正常运行时间和连接性的承诺。 不同的服务具有不同的 SLA，有时服务中的 SKUS 具有不同的 SLA。 有关详细信息，请参阅联机服务的服务级别协议。
Power Platform SLA 包括在不符合 SLA 的情况下获得服务积分的过程，以及每项服务的可用性定义。 SLA 的这一方面起到了强制策略的作用。
Microsoft 业务应用程序为 Dynamics 365 和 SaaS 应用程序中的所有生产类型 环境提供业务连续性和灾难恢复（BCDR）功能 Power Platform 。 Microsoft 了解如何确保您的生产数据在区域性中断期间具有弹性。
组织一致性
云采用框架为与整个组织的监视相关的 SLO 和 SLI 建议提供指导。
有关详细信息，请参阅云监视 SLO。
可靠性清单
请参考整套建议。