你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn 。 访问此页面需要授权。 可以尝试 登录 或 更改目录 。 访问此页面需要授权。 可以尝试 更改目录 。 中断和故障是所有工作负荷面临的严重问题。 可靠的工作负荷必须能够幸存这些事件，并继续 持续提供其预期功能 。 它必须具有 复原能力 ，以便其能够检测并承受故障，同时继续运行。 它必须 可恢复 ，这样，如果中断超过复原措施，则可以在商定的恢复目标内还原工作负荷。 它还必须 可用 ，以便用户可以在承诺的时间段内以承诺的质量级别访问工作负载。 假设不会发生故障是不现实的，尤其是在工作负荷构建为在分布式系统上运行时。 某些组件可能会失败，而另一些组件继续运行。 在某些时候，用户体验可能会受到影响，这损害了业务目标。 工作负荷体系结构应在 应用程序代码、基础结构和作中具有可靠性保证 。 设计选择不应更改由业务需求指定的意向。 此类更改应被视为重大权衡。 设计原则 旨在提供在开发生命周期内应考虑的可靠性方面的指导。 从建议的方法开始，并 证明一组要求的好处是正当 的。 设置策略后，使用 可靠性清单 推动行动。 如果不将这些原则应用于设计，工作负荷很可能不会准备好 预测或处理生产中的问题 。 其结果可能是服务中断，导致财务损失。 对于关键工作负荷，如果不应用这些原则可能会危及安全。

设计不是基于未定义或模糊的结果的猜测。 可靠性需要有针对性的活动，以在可接受的用户体验、设计约束以及成功表现及其衡量方式上达成一致。 制定明确的、可实现和记录的目标，与业务利益干系人协商，并立足于现实的投资和预测。 这些要求将直接影响您的架构选择，从弹性策略到可观测工具和扩展计划。 应预期组件故障、平台中断、性能下降、资源可用性有限和其他故障将发生。 在系统中构建复原能力，使其 容错且可正常降级 。 即使是高度可复原的系统也需要在体系结构设计和工作负荷作中采用 灾难准备方法 。 在数据层上，你应该有一个策略，可以在损坏时修复工作负荷状态。 在开发生命周期 中尽早和经常测试故障 ，并确定性能对可靠性的影响。 为了进行根本原因分析和事后分析，需要在团队之间实现信息透明，以便了解依赖项状态和持续故障。 来自可观察系统的见解、诊断和警报是 有效事件管理和持续改进的基础。 通常，导致最可靠解决方案的关键在于你删除了什么，而不是你添加了什么。 简单性减少了控制的表面面积 ，从而最大限度地减少效率低下以及潜在的配置错误或意外交互。 另一方面，过度简化可能会引入单一故障点。 保持平衡的方法。 想要尝试使用 Ask Learn 阐明或指导你完成本主题？ Last updated on 2025-10-31