3. Azure Well-Architected Framework (WAF)

© Unai Huete Beloki 2025
U. H. Beloki, The Art of Site Reliability Engineering (SRE) with Azure,
https://doi.org/10.1007/979-8-8688-1545-4_3

第三章 Azure Well-Architected Framework (WAF)

前两章主要向你介绍了站点可靠性工程（SRE）和服务级别定义的概念。尽管本书的目标是如何在 Azure 环境中应用并实现 SRE，但前两章分享的大部分信息适用于任何数据中心场景——无论是在 Azure、Amazon AWS、Google GCP、本地部署还是混合环境中运行。后续章节将在需要时再次重申这些概念。

从本章开始，对 Azure 的关注将变得更加明显，首先从 Azure Well-Architected Framework (WAF) 入手。WAF 是 Microsoft Azure 架构团队提供的一组最佳实践，旨在帮助客户和合作伙伴在建立坚实 Azure 服务基线以及优化平台上运行的应用和服务层工作负载的过程中应对挑战。

尽管本章会涉及许多技术细节，但尚未达到“动手实践”的程度，而是从“如何设计”的角度解释概念。只有在接下来的章节中，我才会逐步引导你了解实际场景，并提供大量关于如何实际部署资源、勾勒架构、集成 DevOps CI/CD 管道作为自动化的示例，最后以监控和可观测性收尾。

通过本章的学习，你将掌握以下内容：

理解 Well-Architected Framework (WAF) 的概念
识别 Well-Architected Framework (WAF) 的构建模块
使用 WAF 对现有 Azure 环境进行评估
分析 Well-Architected Framework (WAF) 评估结果并优化 Azure 环境

理解 Well-Architected Framework (WAF) 概念

Azure Well-Architected Framework 为 Azure 客户提供了一套指南和最佳实践，说明如何“按部就班”地实现 Azure 工作负载。

该框架聚焦于五个核心目标，这些目标应成为任何合理的 Azure 架构设计的一部分，无论将在平台上部署何种工作负载或服务：

可靠性
安全性
成本优化
运维卓越
性能效率

WAF 背后的理念是：它应成为 Azure 部署计划的中心，每个目标都需纳入考虑。一旦在云解决方案架构设计中触及每个目标的各个要点，你就可以准备部署了。然而，部署完成后工作并未结束——你可以将 WAF 的指南和最佳实践重新应用于新部署以及已在 Azure 上运行的工作负载。

图 3-1. WAF 目标

[此处为图 3-1 占位符,原文无实际图像]

可靠性：系统运行的健康程度如何？从故障中恢复的速度有多快？
安全性：集成威胁防护，保障工作负载的安全
成本：在保证架构质量的前提下管理成本，避免超支
运维：为使系统保持尽可能健康的状态而执行的管理任务
性能：你的系统能否灵活适应行为变化（如峰值负载和空闲时段），而不影响应用质量？

在整合 Azure 环境的总体范围内，WAF 的每个构建模块都同等重要。然而，鉴于我们本章及全书强调的 SRE 主题，显然会更多地关注可靠性组件。本章将从概念上（“是什么”）覆盖可靠性主题，而第四章将介绍如何使用 Azure 平台特性来实现（“怎么做”）。

从图中看，这些目标似乎是一个线性流程，每个目标同样重要。我认为这在一定程度上是有道理的。每个目标无疑与其他任何目标同等重要。然而，根据工作负载类型、Azure 资源以及技术和业务需求的不同，每个目标的权重可能会发生变化。

例如，在将工作负载迁移到 Azure 的早期阶段，组织可能可以接受更高的资源消耗。搭建概念验证（POC）环境会产生额外成本；DevOps 团队可能需要更多时间在开发/测试或暂存环境中运行多次部署周期，然后才能进入生产环境。

一旦你针对这五个目标类别（Microsoft 称之为“支柱”）映射了你的业务案例，你很可能还需要识别取舍。这听起来可能有点奇怪，几乎像是在告诉你牺牲某些目标以换取其他目标。虽然并非完全如此，但这实际上是我在许多组织中看到的情况，并且我在职业生涯中已经在本地部署和云组织中多次目睹过。

请记住，我在前面的段落中使用了“最终”这个词。在最理想、最完美的世界里，你会以同等的方式强调每个目标。预算控制与可靠性、安全性、性能同等重要。这一切最终将导向运维卓越。然而，应用程序、系统，甚至业务目标本身并不总是那么清晰。作为云解决方案架构师，你可以设计出最漂亮、最健壮、性能最优的架构，但如果业务不愿意为此买单，那么这个设计（或部分设计）就只能“拜拜”了，对吧？

或者，如果存在你和技术云团队甚至业务本身都无法预见的未知因素呢？我想到的一个例子是 2020 年 3 月初席卷各大洲的 COVID-19 疫情。在欧洲多个国家，实体店、餐馆、酒吧和其他公共场所不得不关闭——几乎是过夜之间。员工不能再上班，因为他们不被允许进入办公室。学校关闭了数周（有时数月），实体商店被迫关闭等。我还记得那时看到一股巨大的云采用浪潮，导致 Azure 西欧区域性能下降，其他 Azure 区域也很快跟进，因为组织试图在其他地方部署所需的 Azure 资源，或者跨区域执行灾难恢复故障转移。组织迅速将工作负载迁移到云端，部署新的工作负载场景（如虚拟桌面解决方案），并建立 Azure VPN 以使系统管理员和开发人员仍然能够连接到系统——而此前这些连接是通过总部或分支机构的站点到站点或 ExpressRoute 隧道进行的，现在却被迫在家办公。

正是在这种情况下，许多组织（包括作为 Azure 服务提供商的 Microsoft）不得不就某些取舍达成一致，以使工作负载能在 Azure 上运行。我仍然听到客户说他们新部署的工作负载在云中尚未达到 100% 的高可用性，因为他们需要优先关注其他事项（如安全性），或者将满足性能需求作为更高优先级。其他团队则在准备度方面挣扎，因为他们需要如此迅速地提升 Azure 技能；几乎不可能跟上运行 Azure 工作负载所涉及的各种服务、架构选项和管理方面。（这也是促使我写这本书的另一个动力，希望尽可能帮助你。）

WAF – 可靠性构建模块

可靠性构建模块与本书总体主题最为接近，因为它扩展了站点可靠性工程的概念。不过请记住，决定哪些目标比其他的更重要存在许多动态因素；并且在最终设计你的 Azure 架构时，所有目标同样重要。

部署可靠的工作负载涉及以下概念：

本地架构与云架构（非常）不同。
云平台并非 100% 可靠。
可观测性至关重要。
DevOps 与自动化。
工作负载的自我修复。

当应用工作负载可靠时，意味着它运行健康，没有或只有极少的停机时间。有时这也会与“弹性”混淆。然而，两者并不完全相同。弹性通常指系统/应用在发生中断时通过快速恢复保持运行的能力。弹性越强，恢复时间越短。而可靠性越强，停机时间越少，这意味着你无需过于担心弹性。看，含义略有不同，但对于任何工作负载都至关重要。

两者将很大程度上决定 SRE 流程的成功因素以及 SRE 团队的整体成功。第四章将重点展示实现可靠性/弹性的一些示例。其他章节（如第六章）也将提供一些关于如何将事件响应实践应用于自动恢复的技巧。

本地架构与云架构（非常）不同

建立可靠的云架构与在本地数据中心构建类似的可靠架构是不同的。过去 40 年来，组织通常的做法是投资冗余的物理组件——从通常配备内置于物理层的智能存储复制功能的物理存储（还有人记得磁盘镜像、带区集、RAID 集吗？），到具有冗余电源、热插拔内存等的物理服务器。从软件角度来看，关键业务应用通常部署在集群中，通常反映两个或更多运行相同应用的服务器，采用主动/被动或主动/主动场景。

VMware 和 Microsoft Hyper-V 等虚拟机管理程序解决方案在 2003 年左右成为受欢迎的技术，IT 行业注意到一个转变：从投资冗余的物理数据中心组件转向逻辑的高可用软件层。诸如 VMware vMotion 和 Hyper-V 实时迁移等技术——通过它们可以轻松地将虚拟机工作负载从一台物理主机迁移到另一台，停机时间极短——极大地促进了组织对高可用性和灾难恢复的看法。

图 3-2. 采用灾难恢复解决方案的高可用数据中心架构

[此处为图 3-2 占位符,原文无实际图像]

如今转向典型的可靠云架构——这将成为下一章解释的核心——部分仍然相同，具体取决于你使用的是基础设施即服务（IaaS）还是平台即服务（PaaS）。如果是前者，从 Azure 的角度来看，Microsoft 负责为你提供冗余的物理数据中心组件，一直到虚拟机管理程序（用于 Azure 虚拟机的 Hyper-V），而作为客户，你主要负责保持系统运行、使工作负载高度可用和冗余、将备份和灾难恢复集成到解决方案中等等——仅举几个核心方面。如果你查看平台服务，如 Azure App Service、Azure SQL Database、Azure Cosmos DB、Azure Service Bus 等许多其他服务，Microsoft 还承担托管实际底层服务层的责任。

第3章：Azure Well-Architected Framework (WAF)

对于像Azure App Service、Azure SQL Database、Azure Cosmos DB、Azure Service Bus等平台服务，Microsoft还负责托管底层实际的服务层，例如Web应用服务、SQL数据库服务器实例等。作为客户，您的责任是部署实际的应用层（Web应用源代码或容器）以及数据库层（实际的数据库表和内容）。

此外，云环境比本地环境更具动态性。在本地解决方案中，作为系统管理员，您可以通过远程桌面连接到物理机器，并通过检查日志/事件/性能指标来诊断可能的问题。相反，在云环境中，尤其是基于PaaS产品的环境中，后端使用的VM/服务器实例可能随时变化；故障排除不是基于连接到底层基础设施（不可能）；您需要利用Azure Monitor下的工具，如Application Insights、Log Analytics和Metric Explorer来导出和分析这些日志/指标（这将在第6章中介绍）。

云并非100%高可用

第3章 Azure Well-Architected Framework (WAF) 第66页

配置Cosmos DB多区域数据库复制（参见图3-3），这只是Azure不同平台能力内置功能中的几个示例。

图3-3. Cosmos DB全局数据复制的配置

延续云（Azure，但也包括Amazon AWS、Google GCP和其他公有云提供商）并非100%高可用的思路，您需要验证不同服务所提供的合同SLA（服务级别协议），正如前几章已经简要提及的那样。

以下是一些示例：

Azure App Service：Microsoft保证客户订阅中运行的应用在99.95%的时间内可用。免费层或共享层下的应用不提供SLA。
Azure SQL Database：提供多种SLA可供选择，取决于后端层的业务关键性。配置为区域冗余部署的Azure SQL数据库业务关键层或高级层具有至少99.995%的可用性保证，而非区域冗余部署则具有至少99.99%的可用性保证。
Azure Kubernetes Service：对于购买了Azure Kubernetes Service (AKS)正常运行时间SLA的客户，Microsoft保证使用Azure可用区域的AKS集群的Kubernetes API服务器正常运行时间为99.95%，不使用Azure可用区域的AKS集群则为99.9%。AKS集群中代理节点的可用性由虚拟机SLA覆盖。

有关所有Azure服务及其相应的服务级别协议，请参见 https://azure.microsoft.com/zh-cn/support/legal/sla/ （中文页面）。

关键要点

作为Azure云解决方案架构师，您需要了解并掌握不同SLA的含义，以便选择正确的Azure平台目标进行部署。作为SRE，您需要与云架构师合作，强调这些选择对解决方案可靠性的重要性。同样重要的是，在将业务正常运行时间要求与所选的Azure服务进行映射之前，您需要理解并了解组织的业务正常运行时间要求。一个对业务至关重要、要求SLA达到99.999%的电子商务应用程序，所需的Azure服务和架构与一个不那么关键、要求SLA为95%的人力资源应用程序是不同的。

第3章 Azure Well-Architected Framework (WAF) 第67页

第3章 Azure 良好架构框架 (WAF)

第4章将提供更多关于常见Azure服务（包括基础设施即服务 (IaaS) 和平台即服务 (PaaS)）的技术见解，以及如何从可靠状态视角设计它们。主要指南将采用Azure产品团队参考架构，并结合我过去几年在为客户设计、架构和部署Azure环境时的个人观察。

请记住，在考虑可靠性时，也不要忘记围绕成本、安全性和性能的决策权衡。更可靠的拓扑通常意味着更复杂的架构，跨越多个Azure区域。拓扑中包含更多服务也意味着更多潜在的安全威胁和需要应对的风险，更多可能发生故障的组件，此类架构中的延迟可能比较简单的场景更频繁地出现，等等。

可观测性至关重要

除了探索冗余的云服务架构，遵循平台规定的SLA以及业务要求的SLA之外，还需要其他策略来优化可靠性。其中之一是可观测性（传统上下文中有时称为监控，两者区别在第6章解释）。

监控将在第6章中详细讨论，但简而言之，它帮助IT运维团队不仅识别工作负载运行的健康状况（或未运行），还能预测或预见中断。如果没有合适的监控方案，IT团队除了等待最终用户或客户告知工作负载不可用或响应异常外，无法识别问题或事件。通过依赖监控指标和日志，IT运维和DevOps团队通常能够更快地检测并缓解问题，甚至更好地避免中断。

对于Azure Kubernetes服务 (AKS)，还完全支持第三方可观测性解决方案，如Prometheus和Grafana，如果需要，它们可以与Azure Monitor服务集成（见图3-4）。

图3-4. 监控AKS（来源：https://learn.microsoft.com/zh-cn/azure/aks/monitor-aks）

DevOps与自动化

尽管不是中断的唯一因素，但人为因素通常是IT环境中问题的根本原因。打补丁、每月维护、灾难/恢复测试等场景，往往始于良好的意图（保持系统健康），但常常导致比计划更严重的中断（或者完全没有计划）。

在工作负载的生命周期中引入越多自动化，其运行就越可靠。从DevOps实践开始，将应用程序源代码存储在源代码控制系统（例如Azure DevOps Repos或GitHub仓库中的Git仓库）中，依赖特性分支、拉取请求和同行评审，将有助于应用程序代码的成功和质量。接下来，将适当的构建/测试/安全/质量工作负载集成到持续集成/持续交付 (CI/CD) 管道中，是另一个重要方面。没有人希望发布有缺陷的代码，更不希望在工作负载发布后才发现问题。关于发布工作负载，如果未首先通过开发、测试和/或预生产环境，则不应允许发布到生产环境。

在第5章中，我将引导你了解几种常见的CI/CD管道场景，包括使用Azure Pipelines和GitHub Actions。

不同的环境应使用基础设施即代码来部署：考虑Azure ARM模板、Azure Bicep，或多云工具如Terraform或Ansible。手动部署工作负载（人为因素是一薄弱环节）不仅耗时，而且特别容易出错，切换到自动化部署将是良好的进步。然而，使用基础设施即代码还有额外优势。不同于从“接下来我要部署什么”的方法来部署资源，基础设施即代码允许你关注“我的最终状态应该是什么样的”这一特性，声明式基础设施即代码技术如Bicep或Terraform使这成为可能。通过使用自动化，部署也易于重现和重复，使IT团队能够快速在不同环境中运行部署，并在灾难发生时依靠自动化重新部署特定工作负载。如果你知道你可以部署虚拟机架构——从虚拟机资源和完全修补的操作系统开始，集成虚拟网络设置和网络安全组定义，一直到使用自定义脚本或配置即代码注入自动化软件部署——为什么不这样做？或者，如果同样的部署需要30分钟运行，为什么要花60分钟来排除运行时的故障？

这就是DevOps和自动化可以为可靠性目标带来的效率。

自我修复

自我修复是指依赖平台的自动化方面在发生中断时自行修复，从而使你的解决方案对问题更具弹性。这可以通过两种不同的方式实现：

结合自动化和可观测性：在这种场景下，依靠平台的监控能力和云服务，结合警报和通知，触发自动操作来修复问题。一个简单的例子是，当某个区域的服务宕机时捕获警报，并因此触发在不同区域进行Azure部署。这也将在第6章中涵盖。
使用自我修复服务：我不确定这是否是100%正确的定义，但容器化工作负载场景（如Azure容器实例 (ACI) 和Azure Kubernetes服务 (AKS)）很接近。ACI的默认设置之一是——当容器运行时失败时——它会停止容器并启动新实例。类似的行为也是Kubernetes的出色之处，它依靠智能编排来检测POD（Kubernetes中的容器运行时）中的故障，在需要时重新启动它们，甚至在Kubernetes集群中运行节点发生中断时，将POD分散到健康节点。还可以定义探针（存活/就绪）来自动检查容器工作负载的健康状况并进行修复。

本书余下的章节将详细回顾这些概念，并提供更多实际示例和动手场景供你跟随。

可靠性检查清单

为了将应用程序工作负载标识为可靠，必须满足以下要求：

可用性：在SLA术语中，可能的和所需的最长正常运行时间是多少？
高弹性：在发生中断时，工作负载可以多快恢复或复原？
成本：为提高工作负载的高可用性和可靠性需要承担多少额外成本？

为此，应从可靠性检查清单开始，例如：

确定满足业务要求的可用性及恢复目标。这可能包括备份、数据复制、Azure区域、可用区等。
通过收集需求来集成应用程序弹性和高可用性。同时映射技术和业务需求以全面了解。
如果应用程序和数据平台未达到组织的可靠性要求，则不要批准投入生产。
建立冗余连接路径，使用Azure ExpressRoute和站点到站点VPN作为回退方案，以保障云可用性。通过跨不同区域依赖微软骨干网的VNet对等扩展。
在适用情况下使用可用区以提高可靠性并优化成本。可用区支持虚拟机，也支持Azure Web应用和其他Azure服务。
确保工作负载架构能够弹性应对故障，遵循Microsoft Azure参考架构以及良好架构框架指南。
当可用服务级别的技术或业务要求未满足时，建立回退方案。识别业务风险、成本以及作为解决方案一部分需要理顺的流程。
识别工作负载中的潜在弱点或故障点以实现弹性。像混沌工程（第8章中涉及）这样的场景可能是进行此操作的好工具。
确保系统、数据和应用程序在其一个或多个依赖项缺失时仍能正常运行。依赖无服务器或微服务的架构，配合负载均衡器以及跨多个区域部署工作负载，可以使这成为可能。

测试应用程序的弹性

一旦架构设计到位，并且根据技术和业务需求的协同（最好在开发/测试或预生产环境中）实际部署了工作负载，就该通过测试场景来验证所部署架构能够达到的弹性（以及可靠性）水平了。

不同组织对如何以及何时执行应用程序测试存在强烈意见。在我看来，测试执行得越多越好。左移测试——在应用程序生命周期中尽可能早地移动测试实践——最近获得了一些势头（更多内容见第5章）。

该过程在DevOps周期中已经开始：在构建阶段（持续集成）运行应用程序组件的单元/集成测试（低级）。然而，这通常只运行代码验证，并未检查工作负载一旦发布到目标架构上后运行的可靠性。

此外，测试应用程序存在一个误解，即它应该明确且仅发生在开发/测试环境中（我知道，我自己两段前也提到了这一点）。由于自动化部署（如Azure ARM模板或Bicep、Terraform —— 基础设施即代码）以及配置即代码（Chef、Puppet、Ansible或PowerShell DSC）越来越多，使组织能够以更快的方式运行更广泛的测试，并使该过程更具可重复性。请记住，我已经强调过混沌工程的下一波浪潮，我将在第8章中更深入地解释。虽然它不再完全作为测试场景构建 —— 混沌工程正在真正进入，对生产运行（或类似生产）的工作负载进行压力测试并将其击垮 —— 但它仍然被接受为一种测试场景。老实说，没有什么能阻止你在非生产工作负载上也运行混沌工程实践（特别是在预生产环境，架构尽可能接近生产设计）。

另一个问题是，像混沌或负载测试这样的测试应该多久进行一次（相比应每天在定义的CI/CD管道中以自动化方式运行多次的单元/集成/UI测试）。

由于混沌/负载测试工作负载可能更昂贵且结果……

3. Azure Well-Architected Framework (WAF)

本章继续深入讲解 WAF 的可靠性支柱、检查清单和评估方法，包括混沌工程测试、负载测试、故障注入测试等多种可靠性测试，以及 Well-Architected Framework 评估实践。

可靠性测试的频率与策略

另一个问题是：混沌测试或负载测试之类的测试应该多久执行一次？相比之下，单元/集成/UI 测试应该在定义的 CI/CD 流水线中以自动化方式每天执行多次。

由于混沌/负载测试的工作负载可能更昂贵，且结果可能不经常变化，一种可选方案是：在每次重大变更的交点执行测试，例如架构变更、版本或应用程序升级、迁移到新环境等。即使一切在开发/测试或预生产环境中看起来正常，我们都知道生产环境总是存在（轻微或显著的）差异。确保在部署工作负载时进行详细而彻底的测试。

对于某些组织和应用程序，集成基于环的部署策略会很有益——通过利用金丝雀/早期采用者/正式发布组/环缓慢增加受变更影响的用户数量。例如，微软在 Edge 浏览器或 Windows 11 上所做的事情。这种场景的好处是，在达到普通用户群体之前，先分配一定数量的用户（自愿的金丝雀/早期采用者）来获取反馈（错误/功能）。

另一个概念是蓝绿部署，通常同时部署两个相同的环境。所有用户连接到一个环境；当发生重大变更或引入新版本时，它们会先部署到另一个环境。在那里进行测试和验证，最终成为所有用户的端点。同时，原始环境通常被弃用，成为更新的新位置，之后用户被重定向回该环境，依此类推。

在第 5 章中，我将从 DevOps 的角度进一步解释这些概念以及如何集成它们。

应执行哪些可靠性测试？

这引出了下一个需要回答的问题：应执行哪些类型的可靠性测试？

这里可以定位多种测试（不包括功能测试），具体取决于您想从中获得什么。简而言之，常见测试如下：

性能测试：在用户负载下验证应用程序并监控其行为。与此相关，您可能会遇到负载测试或压力测试实践；性能测试可以结合两者。
负载测试：主要用于在特定预期用户负载下触发可伸缩性（尝试模拟可能的场景）。
压力测试：通常用于验证应用程序或系统在崩溃前能承受的最大负载（尝试找到系统的极限）。可以想象游戏玩家对 CPU 进行超频，以找出计算机在重负载和显示最佳图形时可达到的最高性能。
故障注入测试：引入小规模故障以识别应用程序架构的弱点，或使其崩溃。故障注入是混沌工程的基础，尽管混沌工程通常更进一步，通过组合多个故障造成重大中断。这里的简单场景包括：关闭 Azure VM 规模集或可用性集中的虚拟机以观察影响，更改 Azure 存储的访问密钥以验证应用程序是否回退到辅助访问密钥，更改服务主体的凭据，断开磁盘，中断网络连接等。
灾难/恢复测试：可能是其中最复杂的测试。在此场景中，您的测试或生产环境将从备份或数据复制中恢复，通常是在一个全新的环境中。可以使用诸如 Azure 备份和 Azure Site Recovery（仅适用于虚拟机）等服务。目标是验证备份和灾难恢复解决方案是否足以通过依赖备份或恢复过程来使生产环境恢复运行。这有助于确认为您解决方案定义的指标，如恢复时间目标（RTO）和恢复点目标（RPO）（将在下一章介绍）。虽然这看起来显而易见，但我记得几个场景中，客户正在运行备份作业，却在中断期间发现备份磁带上实际上什么也没存储。

Well-Architected Framework 评估

到现在为止，您应该对应用程序架构的可靠性和弹性有很好的理解，并且能够识别如何彻底测试应用程序以应对故障和预防中断。

在本章的最后部分，我想带您回到流程的起点：评估组织在 Well-Architected Framework 方面的成熟度。

Microsoft 提供了多种不同的评估工具和实践供您使用，Well-Architected Framework 只是其中之一。

图 3-5. Microsoft 评估

具体的评估包括：

Azure Well-Architected Review
DevOps Capability Assessment
Mission Critical | Well-Architected Review
Azure Landing Zone Review
Go-Live | Well-Architected Review
Data Services | Well-Architected Review
Developer Velocity Assessment

我希望我们有时间和页面资源来讨论每一项，因为其中几项实际上与本书的范围相关。但正如您所想象的，我将引导您完成 Azure Well-Architected Review。

从可用评估中点击 Azure Well-Architected Review。您可能需要“登录”并创建一个配置文件。

评估链接： https://learn.microsoft.com/en-us/assessments/azure-architecture-review/