你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

安全设计原则

中断和故障是所有工作负载的严重问题。 可靠的工作负载必须经受住这些事件，并继续 一致地提供其预期功能。 它必须 具有复原能力 ，以便它可以在可接受的时间段内检测、承受和从故障中恢复。 它还必须 可用 ，以便用户可以在承诺的时间段内以承诺的质量级别访问工作负荷。

假设不会发生故障是不现实的，尤其是当工作负荷构建为在分布式系统上运行时。 某些组件可能会失败，而另一些组件则继续运行。 在某些时候，用户体验可能会受到影响，从而危及业务目标。

工作负载体系结构应在 应用程序代码、基础结构和操作中具有可靠性保证。 设计选项不应更改业务需求指定的意向。 此类更改应被视为重大权衡。

设计原则旨在提供在整个开发生命周期中应考虑的可靠性方面的指导。 从建议的方法开始，并 证明一组要求的好处。 设置策略后，使用 可靠性清单驱动操作。

如果不将这些原则应用于设计，则工作负荷很可能不会准备好 预测或处理生产中的问题。 结果可能是服务中断导致财务损失。 对于关键工作负荷，不应用这些原则可能会危及安全。

业务需求设计

收集业务要求，重点关注工作负荷的预期效用。

要求必须涵盖工作负载特有的用户体验、数据、工作流和特征。 要求过程的结果必须明确说明预期。 鉴于指定的投资，目标必须是可以实现的，并与团队协商。 必须记录它们，以推动技术选择、实现和操作。

方法	好处
通过在单个组件、系统流和整个系统的指标上设置目标来量化成功。 这些目标是否使用户流更可靠？	指标可量化预期。 它们使你能够 了解复杂性 ，并确定这些复杂性的下游成本是否在投资限制范围内。 目标值表示理想状态。 可以使用这些值作为测试阈值，以帮助检测与该状态 的偏差 以及返回到目标状态所需的时间。 合规性要求还必须对范围内流具有可预测的结果。 确定这些流的优先级 会使人们对最敏感的区域进行关注。
了解平台承诺。 请考虑服务的限制、配额、区域和容量约束 。	服务级别协议 (SLA) 因服务而异。 并非所有服务和功能都受到同等的保障。 并非所有服务或功能在所有区域中都可用。 大多数订阅资源限制是按区域设置的。 充分 了解覆盖范围和限制 有助于检测偏移，并构建复原能力和恢复机制。
确定依赖项 及其对复原能力的影响。	跟踪其他团队或第三方开发的依赖基础结构、服务、API 和功能有助于确定 工作负载是否可以在没有这些依赖项的情况下运行。 它还有助于 了解级联故障 并 改进下游操作。 使用可能容易受到故障影响的外部服务时，开发人员可以实现 可复原设计模式 来处理潜在的故障。

针对复原能力进行设计

工作负荷必须继续以完整或减少的功能运行。

应该会出现组件故障、平台中断、性能下降、资源可用性受限和其他故障。 在系统中构建复原能力，使其 具有容错能力并可以正常降级。

方法	好处
将位于关键路径上的组件 与可在降级状态下运行的组件区分开来。	并非所有工作负载组件都需要同样可靠。 确定关键性有助于根据 每个组件的关键性进行设计。 对于可能会稍微恶化用户体验 的组件，你不会过度制造复原能力 ，而组件在发生故障时会导致端到端问题。 该设计可以有效地将资源分配给关键组件。 还可以实现故障隔离策略，以便在非关键组件发生故障或进入降级状态时，可以隔离该组件以防止级联故障。
确定系统中的潜在故障点（尤其是关键组件），并确定对用户流的影响。	可以 分析故障情况、爆炸半径和故障强度：完全或部分中断。 此分析会影响组件级别的错误处理功能的设计。
正确使用设计模式并模块化设计以隔离故障，从而构建自我保留功能。	系统将能够 防止问题影响下游组件。 系统将能够缓解暂时性故障和永久性故障、性能瓶颈以及可能影响可靠性的其他问题。 还可以 最大程度地减少爆炸半径。
通过考虑受支持区域中服务的容量限制，添加向外扩展关键组件 (应用程序和基础结构) 的功能。	工作负荷将能够 处理可变容量峰值和波动。 当系统上出现意外负载（例如有效使用量激增）时，此功能至关重要。 如果工作负荷旨在横向扩展多个区域，它甚至可以克服潜在的临时资源容量限制或影响单个区域的其他问题。
在层中构建冗余，并在各种应用层上实现复原能力。 旨在实现物理实用工具的冗余和即时数据复制。 还旨在实现涵盖服务、运营和人员的功能层的冗余。	冗余有助于 最大程度地减少单一故障点。 例如，如果发生组件、区域性或区域性中断，则主动-主动或主动-被动) 中的冗余部署 (使你能够满足运行时间目标。 添加中介可防止组件之间的直接依赖关系，并改进缓冲。 这两个优点都强化了系统的复原能力。
过度预配可立即缓解冗余实例的单个故障 ，并缓冲资源消耗失控的情况。	过度预配的更高投资 可提高复原能力。 在活动故障期间，系统将继续以完全实用工具运行，甚至在缩放操作可以开始 修正故障之前。 同样，可以在发生系统故障或主动缩放之前降低意外失控资源消耗的风险，从而声明计划缓冲区，获得关键的会审时间。

针对恢复的设计

工作负荷必须能够预测和恢复大多数故障，同时对用户体验和业务目标的中断降到最低。

即使是高度可复原的系统，在体系结构设计和工作负载操作中也需要 灾难准备方法。 在数据层上，应该有可以在损坏时修复工作负载状态的策略。

方法	好处
已构建、测试和记录与协商恢复 目标一致的恢复计划。 除了整个系统之外，计划还必须涵盖所有组件。	定义完善的流程可 快速恢复 ，防止对企业的财务和声誉产生负面影响。 定期执行恢复演练会测试恢复系统组件、数据、故障转移和故障回复步骤的过程， 以避免在时间和数据完整性是 关键成功指标时混淆。
确保可以修复恢复目标中所有有状态组件 的数据 。	备份对于使用受信任的恢复点（如上一个已知正常状态）使 系统恢复工作 状态至关重要。 不可变且事务一致的备份可确保无法更改数据，并且还原的数据不会损坏。
在设计中实现 自动自我修复功能 。	这种自动化 可降低人为干预等外部因素的风险，并缩短中断修复周期。
将无状态组件替换为 不可变的临时单位。	构建可按需启动和销毁的临时单元可提供 可重复性和一致性。 使用并行部署模型以增量方式过渡到新单元，从而最大程度地减少中断。

运营设计

在操作中左移以预测故障情况。

在开发生命周期中尽早测试失败，并且经常在开发生命周期中测试失败，并确定性能对可靠性的影响。 为了进行根本原因分析和事后分析，需要跨团队共享依赖项状态和持续失败的可见性。 来自可观测系统的见解、诊断和警报是有效事件管理和持续改进的基础。

方法	好处
构建可关联遥测的可观测系统。	监视和诊断是关键操作。 如果某个故障，你需要知道它失败、 失败时间以及 失败的原因。 组件级别的可观测性至关重要，但组件和相关用户流的聚合可观测性提供了运行状况的整体视图。 需要此数据才能使站点可靠性工程师确定修正工作的优先级。
预测潜在的故障和异常行为。 通过使用优先级和可操作的警报，使活动可靠性故障可见。 投资可靠的流程和基础结构，加快会审速度。	站点可靠性工程师可以立即收到通知，以便他们可以 缓解正在进行的实时站点事件 ，并主动缓解预测警报识别出的潜在故障，然后再成为实时事件。
在生产和预生产环境中模拟故障并运行测试。	在生产环境中遇到故障是有益的，因此你可以 为恢复设置现实的预期。 这样，你就可以做出对故障做出适当响应的设计选择。 此外，它还可用于测试为业务指标设置的阈值。
构建考虑到 自动化的组件，并尽可能自动执行。	自动化 最大程度地降低了人为错误的可能性，使测试、部署和操作 保持一致 。
考虑 日常操作及其对 系统稳定性的影响。	工作负荷可能会受到持续操作的约束，例如应用程序修订、安全性和合规性审核、组件升级以及备份过程。 仔细检查这些更改可确保 系统的稳定性。
持续 从生产中的事件中学习。	根据事件，可以确定设计和操作中在预生产中可能被忽略的影响和疏忽。 最终，你将能够根据实际事件 推动改进 。

保持简单

避免过度设计体系结构设计、应用程序代码和操作。

它通常是你删除的内容，而不是你添加的内容，这会导致最可靠的解决方案。 简单性可减少控制外围应用，最大限度地减少效率低下和潜在的配置错误或意外交互。 另一方面，过度简化可能会导致单一故障点。 保持平衡的方法。

方法	好处
仅当组件有助于实现目标业务价值时，才向体系结构添加组件。 保持关键路径精简。	根据业务需求进行设计可以生成一个 易于实现和管理的简单解决方案。 避免使用过多的关键组件，因为每个组件都是一个重要的故障点。
在代码实现、部署和流程中建立标准，并记录这些标准。 确定使用自动验证强制执行这些标准的机会。	标准提供 一致性并最大程度地减少人为错误。 标准命名约定和代码样式指南等方法可以帮助你保持质量，并使资产在故障排除期间易于识别。
评估理论方法是否转换为适用于用例的 实用设计 。	过于精细的应用程序代码可能会导致不必要的相互依赖、额外的操作和 难以维护。
开发足够多的代码。	你将能够防止 由于实现效率低下而导致的问题，例如意外的资源消耗、用户或数据流故障以及代码 bug。 相反，可靠性问题应导致代码评审，以确保代码具有足够的弹性来处理问题。
利用平台提供的功能和 预生成资产，帮助你有效地实现业务目标。	此方法 可最大程度地缩短开发时间。 它还使你能够依赖于已用于类似工作负载的 经过试验和测试的做法 。

后续步骤

可靠性清单