你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
可靠性权衡
可靠的工作负荷始终满足其定义的可靠性目标。 理想情况下，它应通过规避影响可靠性的事件来达到已建立的复原目标。 但是，实际上，工作负荷必须容忍和控制此类事件的影响，并在活动故障期间保持预先确定级别的操作。 即使在灾难期间，可靠工作负荷也必须在给定时间段内恢复到特定状态，这两者在利益干系人之间都达成一致。 事件响应计划使你能够快速检测和恢复至关重要。
在工作负荷的设计阶段，需要考虑基于 可靠性设计原则 和设计评审清单中 可靠性 建议的决定如何影响其他支柱的目标和优化。 某些决定可能会有利于一些支柱，但对其他人来说是一个权衡。 本文介绍为可靠性设计工作负荷体系结构和操作时工作负荷团队可能会遇到的示例权衡。
安全性的可靠性权衡
权衡：增加工作负荷外围应用。 安全支柱优先考虑减少和包含的外围应用，以最大程度地减少攻击途径并减少安全控制的管理。
可靠性通常通过复制获取。 复制可以在组件级别、数据级别甚至地理级别进行。 根据设计，副本会增加工作负荷的外围应用。 从安全角度来看，减少和包含的外围应用是最小化潜在攻击途径并简化安全控制管理的首选。
同样，灾难恢复解决方案（如备份）会增加工作负荷的外围应用。 但是，它们通常与工作负荷的运行时隔离。 这些解决方案需要实施其他安全控制，这些控制措施可能特定于灾难恢复方法。
为了实现可靠性目标，体系结构可能需要其他组件，这会增加外围应用。 例如，可以添加消息总线，以便通过分离使请求具有复原能力。 这增加了复杂性，增加了工作负载的外围应用，增加了需要保护的新组件，可能采用系统中尚未使用的方式。 通常，这些组件附带其他代码和库来支持其使用或常规可靠性模式，这也增加了应用程序外围应用。
当工作负荷遇到在主动事件响应下解决的可靠性事件时，紧迫性可能会给工作负荷团队造成压力，以绕过针对例行访问进行优化的安全控制。
故障排除活动可能导致团队暂时禁用安全协议，使系统可能面临额外的安全风险。 此外，安全协议不会及时重新建立的风险。
安全控制（如自定义基于角色的访问控制分配或窄防火墙规则）的精细实现引入了配置复杂性和敏感度，增加了配置错误的可能性。 通过使用广泛的规则来缓解这种潜在的可靠性影响，会削弱这三个零信任体系结构原则。
应用安全修补程序或软件更新可能会中断目标组件，从而导致软件更改期间不可用。 延迟或避免修补可能会避免潜在的可靠性风险，但它使系统不受不断演变的威胁的保护。
上述注意事项也适用于工作负荷的代码。 例如，它适用于使用旧库和使用旧基础映像的容器的应用程序代码。 如果更新和部署应用程序代码被视为未明确的可靠性风险，则应用程序会随着时间的推移面临额外的安全风险。
成本优化的可靠性权衡
复制是可靠性的关键策略。 具体而言，策略是有足够的复制来处理给定数量的并发节点故障。 对更多并发节点故障的容忍度需要更高的副本计数，这会导致成本增加。
过度预配是用于在系统（例如故障转移事件期间）吸收意外负载的另一种方法，否则可能会导致可靠性问题。 未使用的任何过剩容量都被视为浪费。
如果工作负荷使用过度满足工作负荷恢复点和时间目标的灾难恢复解决方案，则过多会导致由于浪费而产生更高的成本。
工作负荷部署本身是可靠性影响的潜在来源，这种影响通常通过蓝/绿等部署策略在部署时通过冗余来缓解。 在安全部署期间，这种暂时性资源重复通常会在这些时间段内增加工作负荷的总体成本。 部署频率增加成本。
为了实现可靠性，系统需要可观测性。 监视系统需要可观测性数据传输和收集。 随着监视功能的增加，数据的频率和数量增加，从而导致额外的成本。
工作负载的可靠性保证需要测试和演练。 设计和运行测试需要时间和潜在的专用工具，这会产生成本。
可靠性较高的工作负荷通常具有快速响应过程，要求技术团队成员成为正式呼叫轮换的一部分。 此过程会产生额外的人员成本，并因可能定向到其他地方的注意力而损失机会成本。 它还会产生管理过程的潜在工具成本。
与技术提供商的支持合同是可靠工作负荷的关键组成部分。 由于支持级别过度预配而未使用的支持合同会产生浪费。
与卓越运营的可靠性权衡
可靠性通常会增加工作负荷的复杂性。 随着工作负荷的复杂性增加，工作负荷的操作元素还可以增加，以支持在部署协调和配置外围应用方面添加的组件和流程。
为工作负荷制定全面的监视策略是卓越运营的关键部分。 将其他组件引入体系结构以实现可靠性设计模式会导致更多的数据源进行管理，从而提高实现分布式跟踪和可观测性的复杂性。
使用多个区域克服单区域资源容量约束和/或实现主动/主动体系结构会增加工作负荷的操作管理的复杂性。 由于需要管理多个区域，并且需要管理它们之间的数据复制，因此引入了这种复杂性。
随着工作负荷通过添加可靠性组件和模式变得更加可靠，维护操作过程和项目文档需要更多时间。
随着工作负荷中的组件数的增加，训练变得更加复杂。 这种复杂性会影响载入所需的时间。 复杂性还增加了跟踪产品路线图和最新服务级别指南所需的知识。
性能效率的可靠性权衡
可靠性模式通常包含数据复制，以在副本故障中幸存下来。 复制为可靠的数据写入操作引入了额外的延迟，这消耗了特定用户或数据流的性能预算的一部分。
可靠性有时采用各种形式的资源均衡来将负载分发或重新分发到正常运行的副本。 用于均衡的专用组件通常影响正在均衡的请求或进程的性能。
跨地理边界或可用性区域分布组件，以在范围影响中幸存下来，这会导致跨这些可用性边界的组件之间的通信出现网络延迟。
广泛的进程用于观察工作负荷的运行状况。 尽管监视对于可靠性至关重要，但检测可能会影响系统性能。 随着可观测性的增加，性能可能会降低。
自动缩放操作不是即时的，因此无法可靠地处理无法形成或平滑的需求突然和戏剧性的峰值。 因此，通过较大的实例或更多实例进行过度预配是一种关键的可靠性策略，用于考虑需求信号与供应创建之间的滞后，以帮助吸收突发。 未使用的容量可应对性能效率的目标。
有时，组件无法根据需求进行缩放，并且该需求无法完全预测。 使用大型实例来涵盖最坏的情况会导致在该用例之外的情况下过度预配浪费。
相关链接
探索其他支柱的权衡：