可靠性成熟度模型

为工作负载基础设施和操作建立坚实的复原能力基础，而不是将时间花在优化任务上。

成熟度模型的级别 1 旨在帮助工作负荷团队为系统可靠性构建坚实的基础。 重点在于引导启动，即为未来的可靠性决策打下基础。 此阶段主要涉及功能实现，并对现有做法进行一些小的扩展。

此阶段包括研究、获取见解和创建系统的清单。 它还使用 Azure 上的内置可靠性功能，例如启用区域冗余以实现即时改进。

通过建立这些基础知识，你可以让团队做好准备，通过可靠性成熟度模型的水平来逐步增强系统的复原能力和性能。

关键策略

• 评估卸载运营责任的机会

此策略从根本上讲是一种 构建 与 购买或依赖 的方法。 该决定取决于在这个阶段可以管理多少责任，同时仍支持未来的开发。 你希望使用与工作负荷相关的资源，但应始终探索卸载其维护的机会。 下面是一些可能需要应用此方法的经典用例。

• 通过选择平台即服务（PaaS）解决方案将责任卸载到云平台。 它们为常见的复原需求（例如复制、故障转移和备份存储）提供现成的解决方案。 采用此方法时，云提供商将处理托管、维护和复原能力改进。

  例如，云提供程序跨多个计算节点复制数据，并将副本分布到可用性区域。 如果在虚拟机（VM）上构建自己的解决方案，则需要自行管理这些方面，这可能非常耗时和复杂。

• 卸下与工作负荷的业务目标不直接相关的责任。 某些专用作（如数据库管理和安全性）可能会影响工作负荷的可靠性。 探索拥有经验丰富的团队、技术或同时处理这些任务的可能性。

  例如，如果你的团队没有数据库专业知识，请使用托管服务来帮助将责任转移到提供商。 当你开始的时候，此方法非常有用，因为它允许你的团队专注于工作负荷的功能。 许多企业共享、集中管理服务。 如果平台团队可用，请使用它们来处理这些操作。 但是，此方法可能会添加依赖项和组织复杂性。

  或者，如果你的团队具有适当的专业知识，则可以明确决定使用其技能并选择不包含管理功能的服务。

• 将责任卸载给非Microsoft供应商。 选择现成的产品作为起点。 仅当自定义解决方案对工作负荷的业务价值有所贡献时，才会生成自定义解决方案。

风险： 如果 购买或信赖 选项部分满足你的要求，则可能需要实现自定义扩展。 此方法可能会导致“自定义锁定”情况，其中更新和现代化变得不切实际。 定期查看你的要求，并将其与解决方案的功能进行比较。 为两者之间存在重大偏差时制定退出策略。

相反的情况也是一种风险。 尽管 购买或依赖 选项起初可能看起来更简单，但如果 PaaS 服务、供应商解决方案或平台拥有的资源的限制不满足工作负荷所需的粒度或自治级别，可能需要重新评估和重新设计。

• 标识关键用户和系统流

在此阶段，将工作负荷分解为流至关重要。 专注于 用户 和 系统 流。 用户流确定用户交互，系统流确定不直接与用户任务关联的工作负荷组件之间的通信。

例如，在电子商务应用程序中，客户执行前端活动，例如浏览和订购。 同时，后端事务和系统触发的进程满足用户请求并处理其他任务。 这些不同的流是同一系统的一部分，但它们涉及不同的组件并提供不同的用途。

在此阶段开始生成流目录。 观察用户交互和组件通信。 列出和分类流，定义它们的起点和终点，并记下依赖项。 为了清楚起见，使用关系图记录结果和异常。 此目录可以作为与业务利益干系人进行初始对话的重要工具，从其角度识别最重要的方面。 此对话可以通知优先顺序的第一级。

通过评估主要业务活动的风险和影响，将流分类为关键。 若预期中断发生，优雅降级的重点是维持这些关键流程。 在电子商务示例中，关键流包括产品搜索、将项目添加到购物车和结帐，因为这些任务对于业务至关重要。 其他过程（如更新产品数据和维护产品映像）并不那么重要。 确保关键流在中断期间保持正常运行，以防止收入损失，让用户继续搜索产品和将商品添加到购物车。

有关详细信息，请参阅 Azure Well-Architected Framework：使用流优化工作负荷设计。

• 选择正确的设计模型、资源和功能

应在以下级别应用此策略：

• 建筑： 工作负荷设计应考虑到各种基础结构层的可靠性预期。 初始决策可能是容器化或 PaaS 之间用于托管应用程序的选择。 或者，也可以考虑采用星型拓扑或单一虚拟网络等网络结构。

  还应设置基于功能创建分段的边界。 例如，请考虑拆分计算和数据存储和使用专用服务，而不是在一个具有单区域虚拟磁盘的一个 VM 上托管所有内容。

  谨慎

  在迁移场景中，若直接采用“原样迁移”策略而不评估新机会，可能错失优势并带来低效。 务必尽早研究现代化改造，以避免被卡在难以更改的设置中，充分利用更好的方案和改进措施。

• Azure 服务： 使用决策树帮助你为设计选择合适的服务。 选择满足当前需求的组件，但保持灵活，以便随着工作负荷的发展而切换服务，并且需要更多功能。

• Azure 服务中的 SKU 或层： 查看每个 SKU 的功能并了解平台的可用性保证。 评估服务级别协议，以了解围绕已公开发布的百分位数提供的覆盖范围。

• 支持可靠性的功能： 选择云原生服务，通过简单的配置增强可用性，而无需更改代码。 请务必了解这些选项并有意选择配置，例如增加区域冗余或将数据复制到次要区域。

• 使用基本级别的冗余进行部署

在解决方案的每个部分中，避免单一故障点，例如单个实例。 请改为创建多个实例来实现冗余。 Azure 服务通常为你处理冗余，尤其是在使用 PaaS 服务时，通常默认包括本地冗余，并提供升级冗余的选项。 最好使用区域冗余将这些实例分散到多个 Azure 数据中心。 如果不这样做，请至少确保本地冗余，但此方法的风险更高。 在将来的级别中，通过扩展解决方案并使用异地冗余组件来评估是否满足可靠性要求。

折衷： 一个重大权衡是冗余成本增加。 此外，跨区域通信可能会带来延迟。 对于需要最小延迟的旧应用程序，冗余可能会降低性能。

风险： 如果应用程序不是针对多实例环境设计的，它可能会与多个活动实例作斗争，这可能会导致数据不一致。 此外，如果应用程序是为低延迟的本地设置构建的，则使用可用性区域可能会中断其性能。

• 启用指标、日志和跟踪以监视流

选择平台原生工具（如 Azure Monitor），以确保指标、日志和跟踪的可见性。 使用内置功能设置潜在问题的警报。 你应该有基本的警报来发送通知并获取警报。 利用 Azure 平台功能，指示服务健康状态的变动，例如：

• 用于检查平台级健康状况的 Azure 服务运行状况。

• 使用 Azure 资源运行状况检查资源级别的健康状态。

为基础设施和应用程序设置 Azure Monitor操作组。

折衷： 收集更多日志时，需要管理不断增加的数量，这会影响这些日志的存储成本。 使用保留策略管理数据量。 使用 Azure Monitor 在工作区上设置每日上限。 有关详细信息，请参阅 可靠性的配置建议。

开始构建以下各层的可观测性。

基础结构

首先启用诊断日志，并确保从平台组件收集本机指标进行分析。 收集有关资源使用情况的信息，例如 CPU、内存、输入/输出和网络活动。

应用程序

收集应用程序级指标，例如内存消耗或请求延迟，以及日志应用程序活动。 在独立于主应用程序线程的线程或进程中执行日志记录作。 此方法不会导致日志记录减慢应用程序的主要任务。

此外，请检查 Application Insights 中 的基本可用性测试 。

数据

若要在基本级别监视数据库，请收集数据库资源发出的关键指标。 与基础结构组件类似，跟踪数据存储上下文中的资源使用情况，例如网络指标。 收集关于如何优化连接池管理的数据对于提高后续流程的效率非常重要。

对于可靠性，必须跟踪连接指标，例如监视活动连接和失败的连接。 例如，在 Azure Cosmos DB 中，当请求数超过分配的请求单位和连接开始失败时，将返回 429 状态代码。

开始构建故障缓解手册

故障情况可从间歇性、稍长的短暂失败到灾难性中断不等。

在第一层级中，重点关注平台故障。 即使它们超出了你的控制范围，你仍应该有处理策略。 例如，使用可用性区域解决区域性中断。 预测平台级别的暂时性故障，并在工作负荷中处理它们。

处理这些失败的过程因复杂性而异。 开始记录潜在的平台级故障、其相关风险和缓解策略。 本练习主要是理论性的，在更高级别的自动化中成熟。

应记录故障，包括其可能性、影响和缓解策略等因素。 使用与工作负荷目标一致的关键性尺度。 您的规模可能包括：

• 高。 完整的系统中断，导致重大财务损失和用户信任下降。

• 中等。 影响部分工作负荷并导致用户不便的临时中断。

• 低。 影响应用程序非核心功能的次要软件问题，仅导致用户的停机时间最少。

下面是一个示例模板：

在第一级，不要追求完整性，因为总会有一些无法预见的失败情况。 如果遇到意外中断，请在操作手册中记录原因和缓解措施。 将此资产视为一段时间内更新的活文档。

• 添加机制以从暂时性故障中恢复

在云环境中，暂时性故障很常见。 它们表明短期问题，通常可以通过重试在几秒钟内解决。

使用内置 SDK 和配置来处理这些故障，使系统保持活动状态。 内置配置通常是默认设置，因此可能需要测试以验证实现。 此外，实现旨在处理体系结构中暂时性故障的模式。 有关详细信息，请参阅 支持可靠性的体系结构设计模式。

持久性问题可能表明问题不是暂时性的，也可能预示着故障或停机的开始。 此方案不仅需要修复应用程序中的本地化问题。 它涉及检查系统的关键用户和系统流，以及添加自我保存技术和恢复工作。 这些方法是级别 2 描述的成熟做法。

• 运行基本测试

在软件开发生命周期的早期阶段集成基本可靠性测试。 查找执行测试的机会，从单元测试开始验证功能和配置。

此外，请针对风险缓解手册中识别的问题开发简单的测试用例。 专注于高影响力、低工作量的缓解措施。 例如，模拟网络中断或间歇性连接问题，了解重试逻辑如何解决中断。

风险： 测试通常会在开发周期中引入摩擦。 为了减少这种风险，应将可靠性测试与开发任务同时进行跟踪。

功能开发是优先事项，测试可以在开发周期中引入摩擦。 在功能开发完成之前，可以更轻松地开始测试。 在开始设计应用程序的非功能方面时，可以在添加功能功能时对其进行扩展，而不是构建积压问题，以便稍后解决。 虽然此方法最初需要更多精力，但它可以管理，并防止以后出现更大的问题。

确保系统保持正常运行和稳定，方法是合并自我保存功能，并制定基本的恢复计划来管理故障。

云中的故障是不可避免的。 复原策略应努力使系统在所有条件下保持正常运行。 级别 1 引入了解决暂时性故障的方法。 级别 2 侧重于整合自我保护策略，以防止、检测和从长期故障中恢复。 如果尚未解决，这些问题可能会变成全面中断。

第 1 级中识别出的关键流程应优先处理。 它们需要提高所有组件的复原能力和恢复工作，包括应用程序、服务和数据库。 预期调整初始预配大小、实例计数和自动缩放策略，以减少可靠性风险。

在此级别中，应有意识地设计监控和测试实践。 使用符合技术需求并限定为开发团队的高级监视技术。 扩展简单的操作手册，以涵盖您开发和拥有的架构组件，例如应用程序代码。

关键策略

• 评估复原状态，防止故障

• 冗余级别是否足以承受故障？ 定义冗余策略，该策略指定要维护的冗余资源数。 确定这些资源的位置，无论是在本地、跨区域还是在地理位置分布的位置。 评估云平台的设置，并选择满足业务需求和可接受的权衡的级别。

• 工作负载组件是否足够隔离，以控制其故障？ Bulkhead 模式等模式有助于构建复原能力和故障隔离。 舱壁模式将系统划分为隔离的组件（即舱壁），以防止故障蔓延至系统其他部分。

• 关键路径上的组件是否以异步方式通信？ 否则，请使用通信方法，例如队列。 即使下游组件发生故障，此方法也会使系统正常运行。 它还阻止系统进入不确定状态。 浏览 Azure 选项，包括用于队列的 Azure 服务总线和用于事件流的 Azure 事件中心。

  折衷： 异步通信可以通过解耦进程来帮助防止级联失败。 但是，它会在通信路径中添加延迟，这可能会给关键组件带来问题。 在进行任何设计模式更改之前评估性能影响。

• 操作是否设计为保持一致性？ 应用程序机密和证书等资产可能会过期，并且需要定期刷新。 例程更新中的不一致可能会导致可靠性问题。

  理想情况下，识别和消除正在进行的人为操作任务，因为它们容易出错，并可能造成可靠性风险。 将尽可能多的作任务卸载到云提供商。 例如，使用Microsoft Entra ID 的托管标识和 Azure Front Door 管理的传输层安全性 （TLS） 证书。

  监视是必要的，以便采取主动措施，例如跟踪证书过期和接收通知。 应用程序应记录重要事件，例如即将过期的 TLS 证书。 使用多种方法来检查潜在故障有助于确保采取必要的作。

• 在监视系统中添加技术功能

在第 1 级中，您收集了来自工作负载组件的监控数据，重点关注基础设施。 基本分析已完成，并设置了基本警报。 此设置对于了解工作负荷组件的基线性能以及识别异常行为至关重要。

级别 2 通过向工作负载资源添加高级可观测性能力，并采用更为结构化的方法分析监控数据，从而进一步提升监控水平。 利用云服务提供的分析工具。 例如，Azure Monitor 见解工具（例如 VM 见解和网络见解）提供跨依赖项的运行状况和性能的可视化效果。

计划在以下各层实现可观测性功能。

应用程序

• 响应运行状况探测。 使应用程序能够响应来自探测的运行状况检查请求。 应用程序应具有专用终结点进行运行状况检查，这些终结点至少提供状态信息，例如 正常 或 不正常。 此方法允许监视系统评估应用程序是否正常运行并可以处理请求，或者是否存在需要解决的问题。

  Azure 负载均衡服务（例如 Azure Front Door、Azure 流量管理器、Azure 应用程序网关和 Azure 负载均衡器）支持运行状况探测。 运行状况探测向应用程序发送健康检查请求。

• 提升为语义日志记录。 在应用程序中包含有关事件和操作的结构化信息。 使用结构化日志记录时，日志数据使用定义完善的架构以一致格式记录。 通过此架构，可以在后续阶段更轻松地生成自动化、搜索和分析。 包括特定字段（如时间戳和错误代码）以帮助快速识别和解决问题。

• 实现分布式跟踪。 当请求流经系统的不同组件时，必须跨边界捕获跟踪数据。 此数据可用于深入了解应用程序行为并确定性能瓶颈、错误和延迟问题。 Azure Monitor 支持通过 Application Insights 进行基于 OpenTelemetry 的数据收集。

数据

• 跟踪查询持续时间、失败的查询和其他相关指标。 长时间运行的查询可以指示资源约束，并且可能需要调整架构设计。

  在此阶段，数据库已运行一段时间。 请关注数据增长率，尤其要注意那些增长速度意外快的表。 此信息对于规划将来的存储需求和尽早解决性能问题至关重要。

• 使用数据库管理系统提供的工具和仪表板监视数据库复制的状态。 例如，如果您使用 Azure Cosmos DB，应使用其 Insights 功能。 对于 Azure SQL 数据库或 Azure SQL 托管实例，请考虑使用数据库观察程序获取有关数据库的诊断详细信息。

  随着数据库的增长，架构问题可能变得更加明显，这会影响性能。 若要优化查询效率，请考虑添加索引或修改架构，因为这些更改可能会影响可靠性。

操作

级别 1 侧重于上述层。 在第 2 级中，您开始围绕监控系统构建运维操作。

• 使日志保持足够长时间，以获取见解。 从可靠性的角度来看，请配置保留期，以便收集足够的数据来检测故障模式、排查问题并执行根本原因分析。

• 监视备份和恢复过程。 确保备份按计划成功存储在位置，并在合理的时间范围内恢复工作负荷数据。 监视这些进程对于在更高级别设置恢复点目标（RPO）指标的基线非常重要。

✓ 扩展故障缓解手册

级别 1 侧重于预期的平台故障。 在级别 2 中，处理自己工作负荷中的组件和操作中的故障点。 当代码在平台上运行时，平台和应用程序之间的交互点将增加。 预期会因为代码中的漏洞、部署失败和人为错误而出现故障。 使用自我保存或恢复策略缓解这些问题。

扩展您的失败缓解方案，以包括错误和部署问题。 下表基于级别 1 的模板生成：

如果试图覆盖所有可能的故障场景，此过程可能会令人不堪重负。 为方便起见，请专注于属于关键用户流的组件。 随着工作负载的成熟，这份动态文档将持续增长。

• 制定基本恢复计划

故障缓解手册是制定基本恢复计划的基础。 缓解策略可能包括设计模式实现、平台配置调整、实时站点事件管理、自动化测试和培训人员，以在代码评审期间检测问题。

从优雅降级策略开始，包括在系统部分功能异常时的临时修复。 目标是通过禁用失效部件并调整用户体验，确保持续为用户提供服务。 例如，如果数据库关闭，应用程序可以禁用受影响的功能，并使用 HTTP 状态代码通知客户端服务暂时不可用。

为了实现优雅降级，需要将系统组件隔离，仅让受影响部分出问题，其余组件保持正常运行。 使用舱壁模式实现故障隔离。

利用此机会重新审视可能导致恢复速度降低的设计选择。 例如，将域名系统（DNS）记录直接指向 Azure 应用服务上的应用程序可能会导致恢复过程中由于 DNS 传播而延迟。 使用 Azure Front Door 等专用服务作为入口点，以便在恢复步骤期间更轻松地重新配置。

预计此基本计划会在更成熟的级别演变为完整的灾难恢复计划。

• 创建测试计划

通过模拟在风险缓解预案中确定的中断和问题来创建测试计划。 使用简单的测试用例补充这些缓解措施，以确保它们按预期工作且可行。 验证这些功能是否正常运行，并执行降级测试，以查看当特定组件失败时系统如何执行。 通过确保测试失败或通过，使结果保持简单。

使用模拟框架等测试工具将错误注入 HTTP 请求，这有助于更显式地测试重试策略。 Azure Chaos Studio 提供了一个全面的测试套件，用于模拟组件中断和其他问题，这使得它成为探索的宝贵服务。 当你熟悉 Chaos Studio 的功能时，你可以逐渐采用 Chaos Studio。

评估扩展操作对可靠性的影响

若要处理负载峰值，关键组件必须能够高效地横向扩展或纵向扩展。 利用 Azure 提供的自动缩放功能。 这些功能根据预定义的配置调整服务的容量限制。 通过此调整，可以根据需要纵向扩展或缩减服务。

• 确定潜在的瓶颈，并了解它们可能构成的风险。 例如，高吞吐量不应导致流崩溃。

• 了解负载模式。 静态使用模式可能会降低瓶颈，但使用情况和消耗动态的变化可能会加剧风险。

  注释

  可能存在无法横向扩展的组件，例如整体数据库和旧版应用程序。 根据需要主动监视负载曲线，以便重新构建。

• 根据性能和可靠性要求确定合理缩放限制。 对于性能问题，逐步纵向扩展是最常见的。 但是，对于关键流的可靠性问题，可能需要更快速地进行扩展以避免中断。 在任一情况下，请避免无限缩放。

风险： 处理与性能相关的问题时，缩放可能是一种有用的缓解策略。 但是，缩放是临时修复，而不是解决方案。 调查并解决根本问题，例如内存泄漏或失控进程。 否则，您可能会在另一个临界点再次应用相同的缓解措施，并为不需要的资源付费。 通过解决根本原因，可以确保长期稳定性和成本效益。

设置可靠性目标和目标，使团队对恢复过程负责。

在早期阶段，你的团队专注于实现小成功和掌握基本能力。 他们从小改进开始，解决简单的问题，构建强大的基础，同时主要依靠 Azure 可靠性功能。 随着团队的发展，他们应对与自己的资产和流程相关的更多技术挑战。

在级别 3 中，你的团队应集成业务见解和技术技能，以便进行恢复规划。 它们使用高级监视设置目标和计划恢复过程。 此方法可帮助站点可靠性工程师（SRE）快速满足可靠性目标。

关键策略

• 将可靠性功能正式化为目标

可靠性目标有助于为工作负荷团队设置责任。 请务必与业务利益干系人进行协作对话，讨论恢复时间和成本，并做出符合业务目标的妥协。 召集利益相关者，并以研讨会的形式进行讨论。 考虑研讨会议程的以下几点：

• 说明目标背后的指标。 首先介绍用于定义目标的关键指标，例如服务级别目标、恢复时间目标（RTO）和恢复点目标（RPO）。 显示这些指标如何与业务目标保持一致。 专注于关键用户流。 例如，在电商应用中，更新邮件偏好的 RTO 优先级低于结账流程。

• 传达取舍之间的考量。 利益干系人通常期望比实现的目标还要多。 说明扩展范围如何影响预算、作要求和性能。

• 提出目标目标。 根据架构经验和工作负载设计，推荐目标值，如 99.9% 正常运行时间，RPO 和 RTO 设为 4 小时。 促进利益干系人的讨论，提供反馈并进行调整。 确保业务和技术利益干系人都防范不切实际的期望。 以协作心态展开讨论。

• 达成共识或决定。 旨在达成一致，但如果这是不可能的，请让决策者敲定目标，以确保进展。

请通过健康模型主动进行监控

在级别 1 中，从工作负荷组件（包括平台服务和应用程序）收集监视数据。 基本分析和警报旨在建立基准性能并确定异常。 在级别 2 中，焦点会转移到从工作负荷组件（如应用程序代码）获取可观测性数据。

级别 3 通过运行状况建模将业务上下文添加到关键流并定义 正常、 不正常和 降级 状态，从而增强监视功能。 需要与利益相关者达成一致，确定可接受的用户体验折中，并用于定义运行状况状态。

健康建模需要操作成熟度和监视工具的专业知识。 你的团队会评审原始数据、性能级别和日志，以创建自定义指标和阈值，用于定义流的运行状况状态。 它们必须了解这些值与系统的整体运行状况的关系。 向利益干系人传达明确的定义和阈值。

在仪表板中可视化运行状况模型，帮助 SRE 快速定位问题，聚焦运行不正常或降级的流程。

运行状况模型定义应用程序的状态和关键流。 绿色表示所有关键流都按预期运行。 红色表示失败。 黄色显示问题的趋势。 迭代处理健康模型版本可确保可靠性和准确性，但对于大型应用程序来说需要投入大量精力。

健康状态的变化需要配置为警报。 但是，若要有意保留警报，必须考虑到组件的关键性。

有关详细信息，请参阅 Well-Architected 框架：健康建模。

设置可执行的警报

为了提高响应效率，请明确定义警报，并提供足够的信息来采取快速行动。 详细的警报名称和说明有助于在故障排除期间节省时间和精力。 仔细配置严重性、名称和描述，特别关注严重等级。 并非每个事件都是紧急事件。 深思熟虑地评估严重性级别并为每个级别建立标准，例如 CPU 峰值是否从 80% 到 90% 是否有资格成为紧急状态。 设置适当的阈值，以确保有效地定义警报。

有效的警报管理可确保警报在正确的时间通知正确的人员。 频繁和破坏性的警报表示需要调整，在忽略它们时可能会适得其反。 通过设置适当的阈值来筛选出假警报来减少不必要的通知。 确定自动化可以触发操作流程的机会。

创建一个包含有效排查警报所需信息的单一着陆页，以优化故障排除的效率。 与登录到 Azure 门户和搜索指标相比，此方法可以节省时间。 如果 Azure Monitor 内置功能无法完全满足你的需求，请考虑开发自定义仪表板。

• 执行故障模式分析

在前面的阶段中，你为单个组件创建了故障缓解的简单指南。 在此级别，将操作手册演变为正式的故障模式分析（FMA）练习。 本练习的目的是主动识别潜在的故障模式。

FMA 要求你在工作负荷中识别潜在的故障点，并计划缓解作，例如自我修复或灾难恢复（DR）。 首先，监视增加的错误率，并检测对关键流的影响。 使用过去的经验和测试数据来识别潜在的故障并评估其爆破半径。 确定主要问题（如区域范围的中断）的优先级。

请务必将操作分类为 预防性 或 反应性操作。 预防性作在导致中断之前识别风险，从而降低其可能性或严重性。 响应性操作用于解决问题，以缓解降级的运行状况状态或中断。

在电子商务示例应用程序中，工作负荷团队希望执行 FMA 来为重大事件做好准备。 其中一个关键用户流是向购物车添加项目。 属于流的组件包括前端、CartAPI、ProductCatalogAPI、UserProfileAPI、PricingAPI、Azure Cosmos DB 和 Azure 事件中心。

FMA 很复杂，可能很耗时，因此应逐步地进行分析。 此过程是迭代的，并在后续阶段继续发展。

有关详细信息，请参阅 RE：03 有关执行 FMA 的建议。

准备 DR（灾难恢复）计划

在级别 2 中，你创建了一个恢复计划，重点介绍用于还原系统功能的技术控制。 但是，由于灾难性损失或失败，灾难需要更广泛的方法。 DR 计划基于进程。 它们涵盖通信、详细的恢复步骤，并可能包括脚本等技术项目。

首先，确定要规划的灾难类型，例如区域中断、Azure 范围的故障、基础结构中断、数据库损坏和勒索软件攻击。 然后，为每个方案制定恢复策略，并确保设置用于还原作的机制。 业务要求、RTO 和 RPO 应指导 DR 计划。 低 RTO 和 RPO 需要显式自动化过程，而更高的 RTO 和 RPO 允许更简单的恢复方法和手动分析。

DR 主要包括以下动作：

• 通知责任方。 必须清楚地了解谁参与和何时参与。 确保团队使用正确的流程、具有正确的权限并了解他们在恢复中的角色。 应尽早确定一些责任，如首席执行官向市场报告或处理监管要求。

  理想情况下，应具有单独的恢复和通信角色，并为每个角色分配不同的人员。 最初，发现问题的 IT运营人员可能会同时担当这两个角色。 但随着情况的升级，资深技术人员可能会处理技术恢复，而业务人员则负责管理通信。

• 制定业务决策。 在灾难期间，压力水平可能很高，这使得明确的决策至关重要。 结构良好的 DR 计划需要技术团队与业务利益干系人之间持续讨论，以定义初步决策选项。 例如，考虑工作负荷资源是否应在一个 Azure 区域中运行，并在另一个区域中备份，或者是否应提前准备好 IaC 资产，以便在故障转移期间创建新资源或从备份还原。

  根据 DR 计划采取的行动可能具有破坏性或有重大副作用。 了解这些选项、权衡其优缺点，并确定应用选项的正确时机至关重要。 例如，如果主要区域预期在可接受的时间范围内正常运行，则评估是否有必要恢复到其他区域。

• 还原系统操作。 在灾难期间，重点应放在恢复运作，而不是查明原因。 对于技术恢复，特别是区域级故障转移，提前决定使用主动-主动、主动-被动、温备或冷备方式。

  根据所选的方法准备特定的恢复步骤。 从操作恢复的具体步骤列表开始。 随着过程成熟，旨在将 DR 计划定义为脚本，只需进行最少的手动交互。 使用版本控制并安全地存储脚本，以便轻松访问。 此方法需要更前期的工作，但在实际事件期间将压力降到最低。

  有关详细信息，请参阅 在主动-被动中部署 DR。

• 执行事故后分析。 确定事件的原因，并找到将来防止它的方法。 进行更改以提高恢复过程。 本练习也可能发现新的策略。 例如，如果系统切换到辅助环境，请确定是否需要主环境以及故障回复过程应是什么。

DR 计划是一个动态文档，能够根据工作负荷的变化进行调整。 随着新组件和风险的出现，更新 DR 计划。 根据演练或真实灾难中获得的见解优化恢复计划，收集 DR 操作员的实际信息。

控制因技术和作更改而引发的风险，并优先考虑事件管理。

在前面的级别，工作团队专注于开发功能并确保系统正常运行。 在第四级，焦点转向保持系统在生产中的稳定可靠性。 事件管理变得非常重要，因为确保引入的任何更改经过全面测试和安全部署，以避免使系统不稳定。

此过程需要改进运营控制，例如投资专用团队来管理可靠性事件。 它还需要技术控制，以进一步增强系统可靠性，超越以前阶段强化的关键组件。 随着系统继续在生产环境中运行，数据增长可能需要重新设计，例如分区，以确保可靠的访问和维护。

关键策略

• 可靠的更改管理

更改期间发生最大的可靠性风险，例如软件更新、配置调整或流程修改。 从可靠性的角度来看，这些事件至关重要。 目标是最大程度地减少问题、中断、停机时间或数据丢失的可能性。 每种类型的更改都需要特定的活动才能有效地管理其独特的风险。

在级别 4 中，可靠性与卓越运营准则中介绍的安全部署策略相交，以保持在管理更改时的环境稳定。 可靠的更改管理是实现工作负荷稳定性的要求。 请考虑以下关键方面：

• 响应平台更新。 Azure 服务有不同的机制来更新服务。

  • 熟悉维护过程并更新你使用的每个服务的策略。 了解服务是否支持自动升级或手动升级以及手动更新的时间范围。

  • 对于已计划更新的服务，请在影响较低的时间计划这些更新，从而有效地管理这些更新。 避免自动更新，并在评估风险之前延迟更新。 某些服务使你能够控制计时，而其他服务则提供宽限期。 例如，在 Azure Kubernetes 服务（AKS）中，有 90 天时间选择加入更新，否则将自动应用。 在非生产群集中测试更新，该群集镜像生产设置以防止回归。

    逐步应用更新。 即使测试表明更新是安全的，同时将其应用于所有实例可能具有风险。 相反，一次更新几个实例，并在每次更新之后等待一段时间。

  • 定期检查有关更新的通知，这些更新可能在活动日志或其他特定于服务的通道中可用。

  • 监控更新后突发或逐渐的变化。 理想情况下，健康模型应通知你这些更改。

• 使用自动化进行彻底测试。 在推出更改时，将更多测试集成到生成和部署管道中。 寻找将手动流程转换为管道自动化部件的机会。

  在各个阶段使用不同类型的测试组合进行全面测试，以确认更改按预期工作，不会影响应用程序的其他部分。 例如，正测试可以验证系统是否按预期运行。 它应验证没有错误，并确保流量正确流动。

  规划更新时，请确定要应用的测试入口和类型。 大多数测试应在部署前阶段进行，但在更新测试时，还应在每个环境中执行冒烟测试。

• 遵循安全部署做法。 使用包含验证窗口和安全部署做法的部署拓扑。 实现安全部署模式，例如金丝雀部署和蓝绿部署，以增强系统的灵活性和可靠性。

  例如，在 Canary 部署中，一小部分用户首先接收新版本。 此过程在部署到整个用户群之前启用监视和验证。 功能标志和深色启动等技术有助于在生产环境中进行测试，然后再向所有用户发布更改。

• 更新灾难恢复计划。 定期更新 DR 计划，使其保持相关且有效。 避免过时的指示。 此方法可确保计划反映部署到生产并受用户依赖的系统当前状态。 整合从演练和实际事件中吸取的教训。

有关详细信息，请参阅 卓越运营级别 4

• 投资专用团队来处理事件

最初，开发团队可能会参与处理故障事件。 在第 4 级中，为事故管理投资站点可靠性工程（SRE）。 SRE 专门从事生产问题，是效率、变更管理、监视、应急响应和容量管理方面的专家。 熟练的 SRE 团队可以显著减少对工程团队的依赖。

为 SRE 提供独立处理事件所需的工具、信息和知识。 此准备减少了对工程团队的依赖。 SRE 应该接受根据此前阶段开发的操作手册和工作负荷健康模型进行的培训，以便能够快速识别常见模式并启动缓解过程。

工程团队应该有时间反思反复出现的问题并制定长期策略，而不是每次单独解决这些问题。

• 自动执行自我修复过程

在以前的级别中，自我修复策略是使用冗余和设计模式设计的。 现在，你的团队具有实际使用经验，你可以集成自动化来缓解常见的故障模式，并减少对工程团队的依赖。

折衷： 自动化可能需要一段时间，而且设置成本高昂。 专注于首先自动执行影响最大的任务，例如经常发生或可能导致中断的任务。

根据触发器配置操作，并随时间推移自动化响应，为 SRE 构建自动化操作手册。 一种方法是通过编写执行缓解措施的脚本来增强行动方案。 探索 Azure 原生选项，例如使用 Azure Monitor 操作组来设置自动启动各种任务的触发器。

• 将复原能力扩展到后台任务

大多数工作负荷包括不直接支持用户流的组件，但在应用程序的整体工作流中扮演关键角色。 例如，在电子商务系统中，当用户下订单时，系统会向队列添加消息。 此作触发多个后台任务，例如电子邮件确认、信用卡费用最终确定和仓库通知，以便进行调度准备。 这些任务独立于为网站上的用户请求提供服务的函数单独运行，这可降低负载并提高可靠性。 系统还依赖于后台任务来清理数据、定期维护和备份。

评估和改进主要用户流后，请考虑后台任务。 使用已到位的技术和基础结构，并为后台任务添加改进。

• 实施检查点机制。 检查点是将进程或任务的状态在特定时间点保存的技术。 检查点对于长时间运行的任务或进程特别有用，这些任务或进程可能因网络故障或系统崩溃等意外问题而中断。 当进程重启时，它可以从最后的检查点继续，最小化中断影响。

• 保持流程幂等。 确保后台进程中的幂等性，以便在任务失败时，另一个实例可以拾取它并继续处理，而不会出现问题。

• 确保一致性。 如果后台任务在处理过程中停止，则阻止系统进入不一致的状态。 检查点机制和任务级幂等性都是提升后台任务一致性的技术。 将每个任务作为原子事务运行。 对于跨多个数据存储或服务的任务，使用任务级幂等性或补偿事务以确保任务完成。

• 将后台任务集成到监视系统和测试实践中。 检测故障并防止未察觉的中断，这可能会导致功能性和非功能性后果。 监视系统应从这些组件捕获数据，为中断设置警报，并使用触发器自动重试或恢复进程。 将这些资产视为工作负荷的一部分，并像对关键组件执行一样执行自动测试。

Azure 为后台作业（例如 Azure Functions 和 Azure 应用服务 WebJobs）提供了多个服务和功能。 专注于可靠性的流程实现时，请查看其最佳实践和限制。

工作负荷体系结构的发展，目标图标保持复原能力，使系统能够承受新的和无法预见的风险。

在级别 5 中，提高解决方案可靠性的重点是从实施技术控制转向。 基础结构、应用程序和操作应具有足够的可靠性，以承受中断并能够在目标恢复时间内恢复。

使用数据和未来的业务目标来确认，如果你的业务需要进一步进行，则可能需要进行体系结构更改。 随着工作负荷的发展和新功能的添加，尽量减少与这些功能相关的中断，同时进一步减少现有功能的中断。

关键策略

• 使用可靠性见解来指导体系结构演变

在此级别，与业务利益干系人协作做出决策。 请考虑下列因素：

• 分析指标，这些指标指示系统在一段时间内越过可靠性阈值的次数以及是否可以接受这一点。 例如，在一年内遇到五次重大中断可能会引发系统设计和作做法的重新评估。

• 评估系统的业务关键性。 例如，支持任务关键型工作流的服务可能需要重新设计零停机时间部署和即时故障转移，即使它会增加成本或复杂性。 相反，减少使用的服务可能会受益于更宽松的服务级别目标。

• 评估其他支柱的变化如何影响可靠性。 例如，增加的安全措施可能需要对额外的安全跃点进行可靠性缓解措施，这可能会带来潜在的薄弱环节。

• 评估维护可靠性的运营成本。 如果这些成本超出预算限制，请考虑体系结构更改以优化和控制支出。

为了帮助利益干系人、工程师和产品经理做出明智的决策，请考虑可视化上述数据点以及额外的见解。 此方法提供可靠性的完整概述。

• 在生产环境中运行受控测试

在此级别，仅当工作负荷需要最高复原保证时，才考虑生产中的受控试验。 这些测试做法称为 混乱工程。 测试验证系统是否可以正常恢复，并在不利条件下继续正常运行。

请考虑以下示例用例：

• 依赖项流分析： 常见用例是测试设计为微服务的应用程序。 可以关闭随机微服务实例，以确保故障不会级联或中断用户体验。 可以通过禁用特定组件来分析下游系统的反应，从而将此方法扩展到系统流。 目标是确定紧密耦合或隐藏依赖项，并测试系统冗余计划的性能。

• 优雅降级测试：评估系统在功能降低情况下的运行表现。 例如，如果建议引擎失败，则可以隐藏非关键功能。

• 第三方故障模拟： 禁用或限制对外部 API 的调用，以查看系统如何运行以及是否正确实现回退或重试。

混沌工程是测试复原能力的黄金标准。 但是，请为成熟的系统和工作负荷团队保留这种做法。 确保保护措施到位，以限制爆炸半径并防止用户影响。

• 通过举办游戏日来做好准备。 从非生产环境开始，使用低风险配置与模拟事务模拟真实场景。 此方法有助于识别进程差距、人为错误路径和体系结构缺陷。

  当非生产测试停止产生有价值的见解时，如果你有信心，可能需要迁移到生产环境。 在转换之前，请务必列出所有问题、评估复原能力并解决任何问题。

• 限制试验的范围。 例如，可能只关闭一个实例。 明确定义测试的目的。 了解要测试的内容以及原因。

这些测试必须遵循服务级别协议，并在预定义的限制和错误预算内运作。 为这些试验选择适当的时间范围。 通常，在工作日执行这些作可确保团队完全配备人员，并有足够的资源来响应可能发生的任何事件。

• 进行灾难恢复演练

混沌工程测试技术控制的弹性。 灾难恢复（DR）演练评估进程控制复原能力。 DR 演练的目标是在系统从重大故障或灾难中恢复时验证过程、协调和人工作的有效性。

对于监管类工作负载，合规要求可能规定 DR 演练频率，以记录努力程度。 对于其他工作负荷，建议定期执行这些演练。 六个月的间隔提供了一个很好的机会来捕获工作负荷更改并相应地更新 DR 过程。

DR 演练不应仅仅是例行公事。 当正确进行时，DR 演习有助于培训新团队成员，并识别工具、通信和其他与演习相关任务中的差距。 它们还可以突出显示可能忽略的新视角。

请考虑以下用于执行 DR 演练的关键方法，每种方法的风险和实践性各不相同：

• 完全模拟： 这些练习是完全基于白板的，包括过程演练，而不会影响任何系统。 它们适用于训练和初始验证。 但是，它们不提供关于真实事件的洞察力。

• 非生产环境中的实际演练： 这些演练使您能够验证自动化、脚本和流程，而不会带来任何业务风险。

• 生产中的实战演练： 这些演练提供最高级别的置信度和逼真性。 仅在测试前两种方法后进行这些演练。 彻底规划和回滚策略对于尽量减少风险至关重要。 如果有可能导致中断，请不要继续。

无论哪种 DR 演练类型，都应清晰定义工作负载恢复场景。 进行演习就像是真正的事件一样。 此方法可确保团队遵循经过充分理解的清单。 记录结果并对结果进行分类，以推动持续改进。 灾难恢复准备可能包括以下过程：

• 理解事故管理系统，并确保团队掌握升级路径。

• 列出协作和状态更新的通信工具，包括在主要系统受到影响的情况下的替代方法。

• 为工作负载的相关测试场景提供技能培训材料。

• 跟踪差异，以捕获实现过程中遇到的问题。

权衡： 这些演练通常不会造成干扰，但它们确实需要时间。 若要最大程度地提高其有效性，请专注于关键方面并避免不必要的任务。 请确保在积压工作中为这种做法分配时间。

创建 DR 计划或进行 DR 演练时，特别是针对前几个演练，请考虑包括专业知识。 他们在多区域设计、故障转移与恢复策略、服务或工具方面的输入可能非常有价值。 如果你的组织有一个云卓越中心团队，请确保将其包含在规划过程中。

如果有必要，评估您的数据模型并进行分段。

数据是动态的，不断发展。 与体系结构中的其他组件不同，随着用户与系统交互，数据通常会增长。 一段时间内监视数据模式并评估它们对体系结构其他部分的影响至关重要。 在此级别，请考虑简化数据管理并提高性能的技术以提高整体可靠性。 分区是实现这些结果的关键策略。

探索热冷分区等技术，这些技术基于访问模式对数据进行划分，并单独存储数据。 使用访问频率或相关性等条件来确定要分区的内容。

热冷分区可以与分片结合使用，这是将大型数据库划分为称为 分片的较小单元的过程。 每个分片包含一部分数据，并一起构成完整的数据集。 此方法可实现独立的数据管理。

折衷： 均衡分区需要操作过程来评估并确认其分布。 此方法有助于避免一个分区的过度使用，从而防止出现热点分区。 但是，它还需要持续的努力和资源来保持平衡。

选择分区技术时，请考虑以下可靠性优势：

• 增强的性能： 通过跨多个分区分配请求，可以减少单个存储上的负载。 有效实现时，分片使系统能够每天处理数百万个写入请求。 此策略可提高性能并最大程度地降低延迟。

  分区可以简化水平缩放。 例如，数据分片可以将用户或客户划分为等大小的组。

• 改进了数据管理： 热冷分区允许将不同级别的数据管理应用于每个存储层。 例如，将存档数据移动到单独的存储有助于防止作和备份速度变慢。 同样，并非所有日志数据都需要存储在关系数据库中。 它可以被存储在另一个数据存储中，而活动工作负载数据仍然保持关系型结构。

• 定制的可靠性策略： 可以应用不同的可靠性策略来帮助确保每个分区具有适当的复原能力级别，并阻止任何单个存储成为瓶颈。 热分区可以是完全冗余的，包括区域冗余和异地冗余，而冷分区依赖于备份。 提高的可靠性优势在于，可以减少某些类型故障的爆炸范围。 例如，如果失败影响一个分片，则可能不会影响其他分片。

折衷： 由于不同数据分区之间具有很强的相互依赖关系，因此很难维护或修改分区。 这些更改可能会影响验证数据一致性和完整性的能力，尤其是在与单个数据存储相比时。 随着分区数的增加，维护数据完整性的可靠进程的需求变得更加重要。 如果没有这些措施，可靠性可能会受到损害。