工作负载的 Power Platform 可靠性权衡
可靠的工作负荷始终满足其定义的可靠性目标。 它应达到已建立的复原目标，最好是绕过影响可靠性的事件。 但是，实际上，工作负荷必须容忍和控制此类事件的影响，并在主动故障期间将操作维持在预定的级别。 即使在发生灾难期间，可靠的工作负荷也必须在给定时间段内恢复到特定状态，这两种状态都由利益干系人达成一致。 使您能够实现快速检测和恢复的事件响应计划至关重要。
在工作负荷的设计阶段期间，需要考虑基于可靠性设计原则的决策以及可靠性设计评审清单中的建议如何影响其他支柱的目标和优化。 某些决策可能有利于某些支柱，但对其他支柱构成权衡。 本文介绍工作负荷团队在设计工作负荷体系结构和操作以实现可靠性时可能遇到的权衡示例。
可靠性与安全性的权衡
权衡：增加工作负载外围应用。 安全支柱优先考虑减少和包含的外围应用，以最大程度地减少攻击途径并减少安全控制的管理。
可靠性通常通过复制获得。 复制可以在组件级别、数据级别甚至地理级别发生。 根据设计，副本会增加工作负荷的外围应用。 从安全角度来看，首选缩小和包含的外围应用，以最大程度地减少潜在攻击途径并简化安全控制的管理。
同样，灾难恢复解决方案（例如备份）会增加工作负荷的外围应用。 但是，它们通常与工作负荷的运行时隔离。 这需要实现其他安全控制，这些控制可能特定于灾难恢复解决方案。
为了达到可靠性目标，体系结构可能需要其他组件，从而增加外围应用。 这种增加的复杂性通过添加需要保护的新组件（可能采用系统中尚未使用的方式）来增加工作负荷的外围应用。 通常，这些组件附带额外的代码和库，以支持它们的使用或常规可靠性模式，这也增加了应用程序的外围应用。
当工作负荷遇到在活动事件响应下处理的可靠性事件时，紧急性可能会给工作负荷团队带来压力，迫使他们绕过针对常规访问进行优化的安全控制。
故障排除活动可能会导致团队暂时禁用安全协议，使已紧张的系统可能面临额外的安全风险。 还有一种风险，即安全协议不会立即重新建立。
安全控制的精细实现（例如基于角色的访问控制分配或防火墙规则）会引入配置复杂性和敏感度，从而增加错误配置的可能性。 通过使用广泛的规则来缓解这种潜在的可靠性影响会削弱全部三个零信任体系结构原则。
应用版本波次更新或对供应商库（例如第三方组件或解决方案）的更新可能会中断目标组件，导致在更改期间不可用。 延迟或避免修补可能会避免潜在的可靠性风险，但会使系统不受不断演变的威胁的保护。
上述注意事项也适用于工作负荷的代码。 例如，它适用于使用旧库和组件的应用程序代码。 如果更新和部署应用程序代码被视为未加考虑的可靠性风险，则随着时间的推移，应用程序会面临其他安全风险。
可靠性与卓越运营的权衡
为工作负荷制定全面的监视策略是卓越运营的关键部分。 在体系结构中引入其他组件以实现可靠性设计模式，可以管理更多数据源，从而增加实现分布式跟踪和可观测性的复杂性。
使用多个区域来克服单区域资源容量限制和/或实现主动/主动体系结构会增加工作负荷运营管理的复杂性。 这种复杂性由管理多个区域以及管理它们之间的数据复制的需要造成。
随着工作负荷通过添加可靠性组件和模式变得更加可靠，维护运营过程和项目文档需要更多时间。
随着工作负荷中的组件数的增加，训练变得更加复杂。 这种复杂性会影响加入所需的时间，并增加跟踪产品路线图和服务级别指导所需的知识。
可靠性与体验优化的权衡
强调严格的测试可能会延迟对采用至关重要的体验功能的发布。
优化可靠性可能会过度强调最大程度地减少复杂性，这会降低功能的优先级以获得更具吸引力的用户体验，例如自定义组件和集成。
可靠性与性能效率的权衡
可靠性模式通常包含数据复制，以便在副本故障中幸存下来。 复制会为可靠的数据写入操作带来额外的延迟，这会消耗特定用户或数据流的部分性能预算。
可靠性有时采用各种形式的资源平衡来将负载分配或重新分配到 healthy 副本。 用于均衡的专用组件通常会影响正在均衡的请求或进程的性能。
跨地理边界或可用区分发组件以承受范围影响会在跨越这些可用性边界的组件之间的通信中引入网络延迟。
使用广泛的进程来观察工作负载的 health。 Although 监控对于可靠性至关重要，检测可能会影响系统性能。 随着可观测性的提高，性能可能会降低。
自动扩展操作不是即时的，因此无法可靠地处理无法调整或平滑的突然急剧需求高峰。 因此，通过更大的实例或更多的实例进行超额预置是一种关键的可靠性策略，可以解决需求信号和供应创建之间的滞后问题。 未使用的容量与性能效率的目标背道而驰。
有时，组件无法根据需求进行扩展，而这种需求是不完全可预测的。 使用大型实例来覆盖最坏的情况会导致在该使用案例之外的情况下过度预置浪费。