AWS Well-Architected 框架：如何开展自我评估

每一套成功的云基础设施都始于牢固的根基。我见过一些组织的云架构起初看似可用，但在压力之下便土崩瓦解，耗费了时间、金钱与信任。AWS Well-Architected 框架的存在，正是为了从一开始就预防这些问题。

在本教程中，我将带您了解 AWS Well-Architected 框架、其六大基础支柱，以及可用于构建首个云解决方案或优化既有基础设施的实用落地策略。理解该框架将帮助您构建安全、可靠、高效且具成本效益的系统。

如果您是 AWS 新手，建议从我们的 Introduction to AWS 课程开始。

什么是 AWS Well-Architected 框架？

先来弄清这个框架究竟是什么，以及它为何重要。

AWS Well-Architected 框架是一套由 AWS 解决方案架构师基于多年与数千位客户合作经验而制定的全面最佳实践、设计原则与架构指南。它给出了一组基础问题，帮助您判断特定架构是否符合云端最佳实践。

可以把它当作评估云架构的“量尺”。它并非审计机制，但能促成对架构决策的建设性讨论。它描述了在设计与运营云端工作负载时应采用的 AWS 最佳实践与策略，帮助您理解所做取舍及其潜在后果。

该框架最初由五大支柱构成。为反映云计算中环境责任的重要性日益提高，AWS 于 2021 年末新增“可持续性”作为第六支柱。我们稍后将逐一探讨。

AWS Well-Architected Tool 可在 AWS 管理控制台中免费使用，便于您定期评估工作负载、识别高风险问题并记录改进。这意味着您不只是阅读最佳实践，而是在主动将架构与其对标评估。

AWS Well-Architected 框架的六大支柱

既然已经了解了基础，让我们深入这六大核心支柱。它们协同作用，构建稳健而高效的云架构。每一支柱都关注构建与维护云系统的不同侧面。以下是快速概览：

卓越运营

先从卓越运营开始，其重点在于运行与监控系统以交付业务价值。该支柱关注您日常如何运营系统，因此它是其他一切的基础。

指导卓越运营的核心设计原则包括：

• 以代码化方式开展运维
• 频繁进行小规模变更
• 预见并假定会发生故障
• 从运营故障中学习

我发现，在卓越运营方面表现优秀的组织，能更快响应事件、更有信心地部署变更。将运维视为代码，能带来可重复性与一致性——这是扩展云基础设施的两大关键要素。

需要牢记的一些关键最佳实践：

• 明确运维优先级
• 使用 Amazon CloudWatch 实施全面监控
• 使用运行手册与演练手册来标准化操作
• 定期开展复盘，不断改进流程

安全

在以卓越运营作为系统运行基础之上，安全是确保这些系统值得信赖的防护层。显而易见，任何组织都离不开安全的系统。

它专注于通过风险评估与缓解策略来保护信息与系统。要在云中打造稳健的安全态势，您应遵循以下七条设计原则：

• 建立稳固的身份基础
• 启用可追踪性
• 在各层面落实安全
• 将安全最佳实践自动化
• 保护传输中与静态数据
• 尽量减少人员直接接触数据
• 为安全事件做好准备

云安全的强大之处在于，能够在各个层面自动实施安全控制。不像传统基础设施常把安全放在事后，Well-Architected 的方法自始至终将安全编织进架构的肌理。

可靠性

在我们已建立的运营与安全基础之上，可靠性确保工作负载能正确且一致地执行其预期功能，并能快速从故障中恢复以满足需求。

即使运营与安全做得再好，如果系统不可靠，也无法交付价值。在为云端设计可靠性时，可遵循以下设计原则：

• 自动从故障中恢复
• 测试恢复程序
• 水平扩展
• 通过自动化管理变更

云端可靠性的妙处在于“为故障而设计”，而非试图完全杜绝故障。假定故障必然发生，并构建可自动恢复的系统，您将获得较传统方法更具韧性的架构。

性能效率

在拥有可靠系统之后，性能效率关注高效使用计算资源以满足系统需求，并在需求变化时维持这种效率。该支柱关于在不过度预置也不浪费资源的前提下，交付恰到好处的性能。

实现性能效率的关键设计原则包括：

• 普及先进技术的使用
• 快速实现全球化部署
• 采用无服务器架构
• 更高频率地进行试验

性能效率与下一个支柱直接相关，因为您选择的资源及其使用方式会直接影响成本。在这里，架构决策会体现在账单上。

成本优化

在讨论完性能之后，让我们看看如何以具成本效益的方式实现它。成本优化指在满足功能需求的同时，以最低价格点运行系统并交付业务价值。请注意，这个支柱强调的是“优化”，而非“最便宜”。两者有本质区别。

一些最佳实践包括：

• 使用 AWS Cost Explorer 与成本与用量报告追踪费用
• 使用 AWS Compute Optimizer 进行资源适配（Right-sizing）
• 实施自动伸缩以使容量与需求匹配
• 对可预测的工作负载使用 AWS Savings Plans

以我的经验来看，成本优化是各支柱之间取舍最为直观的地方。比如您可能会在多区域部署等可靠性特性上投入更多，但这种投资能保护收入。

您也可能选择性能更高但成本更高的实例，却能更快处理工作负载，最终降低总体成本。关键在于对这些取舍做出知情决策。

可持续性

最后来到最新的一支柱：可持续性。该支柱致力于尽量降低运行云端工作负载对环境的影响，尤其是能耗与能效。

您可以采用一些策略来提升系统的可持续性，例如：

• 依据可再生能源使用情况选择 AWS 区域
• 实施高效的缓存策略
• 使用高效的编程语言
• 使用 Amazon S3 Intelligent-Tiering 管理数据生命周期
• 使用诸如 AWS Graviton 处理器等高能效实例类型

虽然亚马逊将其单列为一支柱，但它常与其他支柱相呼应并互相促进。更高效的代码既减少环境影响，也降低成本。通过资源适配提升利用率，有助于可持续性与成本优化。托管服务往往比自管基础设施运行得更高效。

框架的实践落地

在清晰理解六大支柱之后，接下来讨论如何在组织中真正实施该框架。理解原理是一回事，将其付诸实践才是价值所在。

实施前的准备

在开展 Well-Architected 评审之前，充分准备能助您事半功倍。可将其视为打地基。准备越充分，评审越有价值：

• 定义基础概念：先理解指导评审的关键术语。组件用于满足某项需求；工作负载是一组交付业务价值的组件；技术组合包含您所有的工作负载。共享这套词汇，能确保评审中所有人理解一致。
• 设定目标：让评审目标与实际业务需求对齐。您是在为重大上线做准备？降低成本？提升安全态势？设定可度量的 KPI，如目标可用性或成本降低目标。清晰的目标能让评审聚焦于真正重要的事项。
• 组建项目团队：召集合适的人，例如架构师、开发人员、运维成员与业务干系人。多元视角有助于避免遗漏。评审前收集架构图与文档，便于参与者提前准备。

当团队就位、目标明确后，您就可以开始正式评审。

开展 Well-Architected 评审

评审流程即将您的架构与 AWS 最佳实践进行对照评估。

首先清晰界定工作负载范围。根据目标选择优先评审的支柱。将评审组织为协作式讨论，而非问讯。对每个支柱的问题如实作答，并记录为何某些实践已实施或尚未实施的原因。

评审结束后，您将识别出高、中、低不同级别的风险。整体审视评审结果，找出可通过培训或标准化机制解决的共性问题。

使用 AWS Well-Architected Tool

AWS Well-Architected Tool 是一项免费服务，提供基于 AWS 最佳实践对架构进行度量的统一流程。

快速开始

在 AWS 管理控制台中打开该工具。使用基本信息创建一个新工作负载。选择要应用的镜头（至少包括 AWS Well-Architected 框架镜头），并在适用时添加专门镜头。

要创建新工作负载，请在 AWS 管理控制台中打开 AWS Well-Architected Tool 并点击 Define workload。设置流程分三步：

1. 指定属性：为工作负载命名，填写描述、评审负责人与环境（Production 或 Pre-production）。您也可以添加 AWS 区域、账户 ID，以及行业类型或架构设计链接等可选信息。
2. 应用配置文件（Profile）：可选地附加配置文件，为您的用例预填最佳实践答案。
3. 应用镜头（Lenses）：选择评审所用镜头。AWS Well-Architected 框架镜头是基线，应始终包含。其他官方镜头覆盖特定场景：

• DevOps Lens：用于集成 DevOps 实践
• Serverless Lens：用于无服务器架构
• Mergers & Acquisitions Lens：用于并购驱动的增长场景

4. 您也可以应用其他 AWS 账户共享的自定义镜头。

完成后，点击 Define workload 结束设置。

开展评估

每个工作负载在各支柱下都有一组问题。按支柱逐一回答问题以完成评估。工具会提供背景信息、最佳实践说明，以及文档与视频等资源。

针对每个支柱，您都会看到一组与具体工作负载相关的问题。例如，卓越运营支柱包含 11 个问题，并提供指导您完成评估流程的资源。

每个答案都会直接用于自动风险评估，既可在单个问题层面查看，也会汇总到支柱概览中。完成所有支柱后，工具会将结果汇总为完整报告。

审阅结果并采取行动

生成的报告会将发现分为四个风险级别：

• 高风险：关键最佳实践缺失或未遵循
• 中风险：部分最佳实践仅被部分落实
• 未发现改进项：已覆盖所有相关最佳实践
• 不适用：该工作负载范围外的最佳实践

根据这些发现制定改进计划，并按业务影响对问题排定优先级。该工具允许通过创建里程碑来跟踪进展。

它还与 AWS Trusted Advisor 和 AWS Service Catalog AppRegistry 集成，便于发现信息，并可通过 Cloud Intelligence Dashboards 可视化跨工作负载的指标。

在真实场景中应用 Well-Architected 原则

在覆盖了所有理论与实施步骤之后，让我们看看组织如何在实践中应用这些原则。真实案例能让框架“活起来”，并展示成功的模样。

案例研究与示例

Tricentis Flood 在进行 SOC 2 合规审计前，接受了 AWS 合作伙伴 Cprime 开展的 Well-Architected 评审。评审识别出安全性、可靠性与运营方面的改进项，Tricentis 立即采取了行动。

他们新增了入侵检测、详细的网络日志记录，并将计算与存储分布到多个 AWS 可用区与区域，即使数据中心离线也能确保可用性。 评审在他们最需要的时候，给出了清晰且有优先级的修复清单。

QSRSoft 是一家餐饮科技公司，已有五年多未完成 Well-Architected 评审。其先前流程需要 6 名员工、60 小时才能评审一个工作负载，因此评审屡次被推迟。

通过与 Rego（AWS 合作伙伴）合作并使用 AI 辅助工具，同样的评审仅用 72 分钟就完成了，发现了高风险的安全漏洞与可扩展性阻碍，并最终上线了 AWS Security Hub 以实现持续的自动化监控。

这两个案例说明同一要点：Well-Architected Tool 能暴露真实风险，而越早运行，修复成本越低。

常见挑战与解决方案

尽管好处显而易见，实施该框架并非没有阻碍。以下为组织常见的挑战及应对之策：

团队抵触

• 挑战：团队可能担心评审会暴露问题
• 解决方案：将评审定位为学习机会，强调尽早发现问题能避免更大麻烦

关键在于建立心理安全感。务必明确，发现问题正是目标所在，而非失败的表现。最优秀的团队会主动在问题尚易掌控时将其揪出。

时间限制

• 挑战：团队常称过于忙碌，尤其在上线前
• 解决方案：评审在重大上线前最为重要。聚焦高风险领域的精简评审也胜过不评审

这种挑战往往恰恰表明评审的关键时机到了。如果您忙到无法验证架构，可能也会忙到无暇从架构性失败中恢复。

能力差距

• 挑战：并非所有团队都在各支柱上具备同等专长
• 解决方案：借助 AWS Well-Architected 合作伙伴、使用工具内置的指导，并开展团队交叉培训

请记住，进行一次有价值的评审并不要求您在六大支柱上都是专家。该工具会引导您回答问题，合作伙伴也能弥补知识缺口。

特殊需求

• 挑战：工作负载可能有标准镜头未覆盖的特定需求
• 解决方案：创建自定义镜头，将组织特定的最佳实践与合规要求纳入其中

这其实是机会而非限制。自定义镜头让您将组织独特需求编码为可复用框架，统一应用于所有工作负载。我稍后会展示如何实现。

持续改进与监控

Well-Architected 框架并非一次性的练习，而是对卓越的持续承诺。许多组织的差异化，恰恰体现在不只是做一次评审，而是将持续改进融入文化。

毕竟，您的架构会不断演进，新增功能、流量模式变化、AWS 推出新服务。您的 Well-Architected 实践也应与之共同演进。

建立评审节奏

定期评审能让架构在演变中始终与最佳实践保持一致。把评审视作定期的健康检查，能在小问题变成大麻烦之前将其发现。建议在以下关键时间点进行评审：

• 重大功能发布之后
• 重要上线之前
• 关键工作负载每季度一次
• 所有生产工作负载每年一次

对于持续交付团队，可在合并重要变更前集成轻量评审。这样能尽早发现架构漂移，且更易纠正。将 Well-Architected 合规作为生产部署的必要条件。通过这种方式，您就能确保每个工作负载都以坚实的基础起步。

纳入反馈

只有将评审发现转化为具体改进，评审才会创造价值。建立反馈回路，把评审发现转为明确行动。每次评审后制定优先级计划，优先处理高影响、低投入的改进项，以积累势能。

在团队间共享发现。如果多个工作负载存在相似问题，就说明这是应以系统性方案应对的系统性问题。或许需要更新标准、提供共享组件，或开展培训项目。记录经验教训，帮助其他团队受益并避免重蹈覆辙。

这种知识共享能将单次评审升华为组织层面的学习。

监测进展

随时间跟踪改进，能展示 Well-Architected 项目的价值，并有助于争取持续投入。使用 AWS Well-Architected Tool 的里程碑功能，在特定时间点记录架构状态，清晰呈现改进前后对比。

使用 Cloud Intelligence Dashboards 可视化跨工作负载的指标，便于识别趋势并找出需要关注的工作负载。

跟踪系统可用性、平均恢复时间等业务指标，以展示改进如何转化为业务价值。相比技术指标，这些业务结果对干系人更为重要。

探索 AWS Well-Architected 镜头（Lenses）

AWS Well-Architected 镜头将框架指导扩展到特定领域。尽管六大支柱具有普适性，但镜头认识到：机器学习工作负载与无服务器应用、与金融服务平台的考量各不相同。每个镜头都提供面向这些特定情境的专门问题与最佳实践。

目前，框架包含 16 个镜头，但下表列出了最常用的几类：

如您所见，这些镜头覆盖了核心框架之外的专门需求，帮助您针对特定技术与行业进行优化。举例来说，如果您在构建机器学习平台，ML 镜头会就数据质量、模型训练与部署提出问题，这些在通用框架中并未出现，但对 ML 成功至关重要。

自定义框架

虽然 AWS 提供的镜头已覆盖诸多场景，但您可能需要应对组织特有的需求。这时，自定义镜头便大显身手。

自定义镜头允许您将内部最佳实践、合规要求与组织策略直接纳入框架。可为 PCI 合规、HIPAA 要求，或您所在行业或商业模式特有的安全标准创建自定义镜头。

创建自定义镜头的流程如下：

1. 从工具中下载 JSON 模板
2. 定义支柱、问题与改进计划
3. 上传回工具中

自定义镜头可在整个组织内共享，从而确保每个团队一致地应用公司的标准。

例如，一家医疗机构可以创建将 HIPAA 合规与内部安全标准相结合的镜头，围绕密钥轮换策略、审计日志保留，以及针对医疗数据泄露的事件响应流程提出问题。创建后，组织内的每个团队都可应用该镜头，确保所有工作负载的一致合规。

自定义镜头的力量在于，它能将机构知识编码固化。当您的资深架构师退休或离职时，他们的专业经验仍以自定义镜头的形式保留下来。

结语

AWS Well-Architected 框架为构建安全、可靠、高性能、具成本效益且可持续的云架构提供了系统化方法。应用六大支柱，能为您的云工作负载打下坚实基础。

该框架的真正力量在于持续改进。首次评审将识别改进机会，后续评审则跟踪进展。这样的迭代方式能将“良好”的架构打磨为“卓越”的架构。

从一个工作负载开始，开展评审、实施改进并衡量结果。从中汲取的经验将指导您未来的架构实践。请记住，该框架是帮助您做出知情决策的指南。您会基于自身情境做出取舍——只要理解其影响，这样的取舍就是合理的。

通过拥抱 AWS Well-Architected 框架，您将建立起架构卓越的纪律，为组织的长期发展保驾护航。

要在本教程基础上进一步学习，建议选修我们的 Understanding Modern Data Architecture 或 AWS Security and Cost Management 课程。