通过

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

可靠性设计原则

中断和故障是所有工作负荷面临的严重问题。 可靠的工作负荷必须能够幸存这些事件，并继续 持续提供其预期功能。 它必须具有复原能力，以便其能够检测并承受故障，同时继续运行。 它必须 可恢复 ，这样，如果中断超过复原措施，则可以在商定的恢复目标内还原工作负荷。 它还必须 可用 ，以便用户可以在承诺的时间段内以承诺的质量级别访问工作负载。

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

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

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

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

为满足业务要求进行设计

目标图标 明确工作负荷的范围、用户增长，最重要的是团队向外部客户和内部利益干系人承诺。

设计不是基于未定义或模糊的结果的猜测。 可靠性需要有针对性的活动，以在可接受的用户体验、设计约束以及成功表现及其衡量方式上达成一致。

制定明确的、可实现和记录的目标，与业务利益干系人协商，并立足于现实的投资和预测。 这些要求将直接影响您的架构选择，从弹性策略到可观测工具和扩展计划。

方法 益处
专注于收集定义 解决方案的范围和深度所需的信息。 阐明影响业务目标的约束。 从高级问题开始，例如：

- 需要哪种级别的复原、恢复、可观测性和简单性？
- 是否存在与成本、合规性、地理位置或延迟相关的定义约束？

根据这些信息，记录足够好且易于实现的内容。		 了解目标和边界将阻止猜测。 否则，你可能会陷入迭代设计循环，从而导致浪费工作量和不必要的成本。
通过将业务目标转化为 对实际约束中的体系结构权衡的共享理解来指导决策。 给出影响的选项：

- 财务成本
- 工程复杂性
- 安全注意事项
-运营开销		 这将有助于利益干系人了解其请求的成本、复杂性和运营影响，并指导他们实现现实、一致的结果。
优先定义每个关键用户流的可靠性结果 ，而不是仅依赖于通用度量，例如正常运行时间。

确定面向用户的功能和流经系统，并针对每个功能评估其业务价值、使用模式和复原要求。 在流级别推动共识，以确保设计决策与业务目标保持一致。		 此对话有助于将利益相关者从不可持续的陈述中移开，例如“网站必须始终保持在线”，转向与实际功能和结果相关的实际、可实现的期望。 这些结果有助于确定使用技术解决的内容，以及可以通过其他业务连续性计划解决哪些问题。
围绕时间跨度定位设计决策。

使用实际预测定义使用预期。 例如，启动时预期的用户负载是什么？ 用户增长预期为线性、指数或不确定。		 此信息将帮助您设计一个架构，以满足短期的可靠性需求，同时避免那些会导致未来需要大量返工的设计决策。 此方法会影响如何考虑弹性、事件驱动的工作流，并允许你围绕要产生或避免的技术债务做出战略选择。
考虑 可能限制设计自治的依赖项，例如组织约束。

请注意集中式基础结构、安全授权、网络路由策略或平台决策，这些决策直接影响到复原能力、可用性和恢复方面可以承诺的内容。		 了解您对无法控制的服务的依赖性，有助于在设计时拥有对于可靠性的实际期望。 它确保 RTO/RPO 目标和 SLO 可实现并清晰沟通，避免过度承诺和减少意外。

为获得复原能力进行设计

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

应预期组件故障、平台中断、性能下降、资源可用性有限和其他故障将发生。 在系统中构建复原能力，使其 容错且可正常降级。

方法 益处
将关键路径上的组件 与处于降级状态的组件区分开来。 并非所有工作负荷的组件都需要同样可靠。 确定关键性有助于根据 每个组件的关键性进行设计。 对于可能会稍微恶化用户体验的组件来说，你 不会过度设计组件的复原能力，而不是那些在故障时会导致端到端问题的组件。

在将资源分配给关键组件时，设计可能高效。 还可以实现故障隔离策略，以便如果非关键组件发生故障或进入降级状态，则可以隔离它以防止级联故障。
确定系统中的潜在故障点，尤其是对于关键组件，并确定对用户流的影响。 可以 分析故障案例、爆破半径和故障强度：完全或部分中断。 此分析会影响组件级别的错误处理功能的设计。
使用设计模式正确构建自我保存功能，并将设计模块化以隔离故障。 系统将能够 防止问题影响下游组件。 系统将能够缓解暂时性故障和永久性故障、性能瓶颈以及可能影响可靠性的其他问题。

你还将能够 最大程度地减少爆炸半径。
通过考虑受支持区域中服务的容量约束，添加扩展关键组件（应用程序和基础结构）的功能。 工作负荷将能够 处理可变容量峰值和波动。 当系统上出现意外负载（例如有效使用量激增）时，此功能至关重要。 如果工作负荷旨在横向扩展到多个区域，则甚至可以克服潜在的临时资源容量约束或影响单个区域的其他问题。
在层中生成冗余，并在各种应用程序层上建立复原能力。

旨在实现物理实用工具和即时数据复制的冗余。 此外，还确保涵盖服务、操作和人员的功能层的冗余。		 冗余有助于 最大程度地减少单一故障点。 例如，如果遇到组件、区域或地区性的中断，冗余部署（在主动-主动或主动-备用配置中）允许您满足正常运行时间的目标。

添加中介可防止组件之间的直接依赖关系并提高缓冲。 这两个优势都强化了系统的复原能力。
过度预配可立即缓解 冗余实例的单个故障，并针对资源消耗不足进行缓冲。 过度预配方面的投资 增加复原能力。

即使在扩展操作开始进行故障修复之前，系统也会在正在发生的故障期间继续以最大效能运行。 同样，你可以降低意外的资源过量消耗占用计划缓冲区的风险，争取关键的故障排查时间，以便在系统故障或激进扩展发生前做好准备。

为恢复进行设计

目标图标 工作负载必须能够预测大部分故障，并从所有规模的故障中恢复，对用户体验和业务目标的干扰最小。

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

方法 益处
已构建、测试和记录了 与协商恢复目标一致的恢复计划。 除了整个系统之外，计划还必须涵盖所有组件。 明确定义的流程可 快速恢复 ，从而防止对业务财务和声誉产生负面影响。 通过定期进行恢复演练来测试恢复系统组件、数据，以及故障转移和故障恢复步骤的过程，以免在时间和数据完整性作为成功的重要标准时造成混淆。
确保可以修复所有有状态组件的数据，以实现恢复目标。 备份对于使用受信任的恢复点（如上次已知良好 状态）将系统恢复为工作状态 至关重要。

不可变和事务一致的备份可确保无法更改数据，并且还原的数据不会损坏。
在设计中实现 自动自我修复功能 。 这种自动化 可降低外部因素（如人工干预）的风险，并缩短中断修复周期。
将无状态组件替换为 不可变的临时单位。 构建可按需启动和销毁的临时单元可提供 可重复性和一致性。 在向新单位过渡时，使用并行部署方式以逐步进行，将中断降至最低。

运营设计

目标图标 在作中向左移动，以预测故障情况。

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

方法 益处
构建可观察的系统 ，这些系统可以关联遥测数据。 监视和诊断是至关重要的操作。 如果某些内容失败，您需要知道它是如何失败的、何时失败的以及失败的原因。 组件级别的可观测性是基本的，但组件和相关用户流的聚合可观测性提供了运行状况的整体视图。 若要使站点可靠性工程师能够确定修正工作的优先级，则需要此数据。
预测潜在的故障和异常行为。 使用优先级和可作的警报使活动可靠性失败可见。

投资可靠的流程和基础结构，以便更快地进行会审。		 站点可靠性工程师可以立即收到通知，以便他们可以 减轻正在发生的实时站点事件，并在它们成为实时事件之前主动减轻预测警报确定的可能出现的故障。
模拟故障并在 生产和预生产环境中运行测试。 经历生产中的失败是有益的，以便可以设置对恢复的实际预期。 这样，你就可以做出设计选择，以正常地响应故障。 此外，它还允许测试为业务指标设置的阈值。
在考虑自动化的情况下构建组件，并尽量实现自动化。 自动化 可最大程度地减少人为错误的可能性，使测试、部署和作 保持一致性 。
考虑 日常操作及其对系统稳定性的影响。 工作负荷可能受到持续作的约束，例如应用程序修订、安全性和符合性审核、组件升级和备份过程。 仔细审查这些更改可确保 系统的稳定性。
持续从生产事件中吸取经验。 根据发生的事件，可以确定设计和操作中的影响和在预生产中可能被忽视的疏忽。 最终，你将能够基于现实事件 推动改进 。

保持简单

目标图标 避免过度设计架构设计、应用程序代码和作。

通常，导致最可靠解决方案的关键在于你删除了什么，而不是你添加了什么。 简单性减少了控制的表面面积，从而最大限度地减少效率低下以及潜在的配置错误或意外交互。 另一方面，过度简化可能会引入单一故障点。 保持平衡的方法。

方法 益处
仅当组件有助于实现目标业务价值时，才会将组件添加到体系结构。 使关键路径保持精简。 针对业务需求进行设计可能会导致易于 实现和管理的简单解决方案。 避免使用太多关键组件，因为每个组件都是一个重要的故障点。
在代码实现、部署和流程中建立标准，并记录这些标准。 使用自动验证确定实施这些标准的机会。 标准提供 一致性并最大程度地减少人为错误。 标准命名约定和代码样式指南等方法可以帮助你保持质量，并使资产在故障排除过程中易于识别。
评估理论方法是否转换为适用于用例的 务实设计 。 过于精细的应用程序代码可能会导致不必要的依赖性、额外操作和难以维护。
开发足够多的代码。 你将能够防止因 实现效率低下而导致的问题，例如意外的资源消耗、用户或数据流故障和代码 bug。

相反，可靠性问题应导致代码评审，以确保代码具有足够的弹性来处理问题。
利用平台提供的功能 和预生成资产，这些资产可帮助你有效地满足业务目标。 此方法 可最大程度地减少开发时间。 它还使你能够依赖已用于类似工作负荷的经过验证的实践。

后续步骤

可靠性清单

  • Last updated on