aws-well-architected-review

Well-Architected 评审

概述

引导系统地开展 AWS Well-Architected Framework（WA Framework）评审：从代码和 IaC 中发现工作负载，获取实时语料清单，根据证据评估框架中的每个问题和最佳实践，并以内联方式交付按风险排序、按艾森豪威尔矩阵优先级排列的报告。

框架内容会在评审时从 AWS 实时文档中获取，而不是嵌入静态快照。推荐使用 AWS MCP 服务的文档读取器（aws___read_documentation）来可靠地获取内容；如果无法使用，则通过 HTTPS 使用环境中的网页抓取工具获取相同的 docs.aws.amazon.com 页面；如果完全无法访问文档，则根据内部知识继续评审，并说明无法实时验证框架清单。不要依赖任何非公开或内部的最佳实践／WA 指南 MCP；受支持的运行环境中无法使用这些服务。

详细流程位于参考文件中——当步骤要求时，请阅读相应文件：

• 评审模式 — 模式选择（完整／快速／限定支柱／评分）、触发短语、评分输出格式
• 发现流程 — 基础设施和应用架构发现
• 实时语料清单 — 有门控的 ACQUIRE_CORPUS 阶段：以确定性、只读方式遍历框架，记录语料，并设置验证门控
• 评估流程 — 根据冻结清单评估每项 BP、逐个支柱评审、汇总规则、覆盖率审计
• Lens 指南 — 何时以及如何应用 Well-Architected Lens
• 风险评估 — 影响 × 可能性矩阵和跨支柱权衡
• 报告模板 — 报告步骤的完整报告结构
• 安全注意事项 — 安全处理工作负载数据、评审工具、发现结果和持久化产物

执行模型

开始任何步骤之前，请阅读并遵循安全注意事项——在处理工作负载代码或审查工具之前，必须先加载机密信息脱敏、仅通过 HTTPS 检索、最小权限和保密处理要求。

完整审查按设有门槛的顺序执行。每一步都有一个转换门槛；门槛未通过时，不得进入下一步，也不得跳过该步骤。唯一面向用户的交付内容是一份完整的内联报告——临时文件（本次运行专用的工作目录）仅是执行状态，绝不是交付成果，且其路径不得出现在报告中。

默认非交互。 用户明确要求审查且提供了充分范围时，应不经步骤间确认，将每一步执行到底。发现和风险评估检查点是内部验证门槛，不是要求用户停下来的节点：自行验证后继续。仅当用户明确要求交互式检查点，或确实无法推断出必要的范围决策（例如，支柱范围请求含义模糊）时，才暂停并询问用户。

不可妥协的要求——所有模式（完整 / 快速 / 指定支柱 / 评分）：

• 第 4 步（ACQUIRE_CORPUS）不受模式影响：任何模式都必须先获取并验证实时语料清单，再进行评估；并依据冻结的清单读取问题/BP。不得基于不完整或未经验证的清单开始评估，也不得跳过第 4 步。
• 仅使用规范 ID——绝不编造 PILLAR##-BP## ID。如果语料获取无法生成 ID，应报告为错误，而不是自行编造缺失 ID。

不可妥协的要求——仅限完整审查：

• 冻结清单中的每个 BP 都必须且只能获得五种状态之一。
• 报告模板中的所有章节都必须包含（模板是权威清单——第 7 步中的编号条目只是需要重点回想的子集，并非完整清单：模板还要求执行摘要、架构概览、跨支柱权衡、后续步骤等章节）。报告必须以内联形式输出，首行为 # Well-Architected Review:。不得使用“请参阅文件”、附件或临时文件路径来代替报告内容。

第 1 步：定义工作负载范围

根据用户提供的信息确定工作负载：

• 工作负载名称和简要说明
• 需要分析的代码包/目录（IaC、应用程序代码、CI/CD 配置）
• 业务重要性（关键、高、标准、低）
• 当前痛点（可选）

如果用户已经提供架构详情，或当前代码库中包含 IaC，则无需询问，直接开始发现。如果没有可用代码或 IaC（用户通过口头描述架构），则以该描述作为证据继续；对于无法通过代码验证的发现，标记为“基于描述——请通过代码验证”。如果用户已提供足够上下文，能够开展有意义的审查，不要要求用户提供代码。

根据用户的措辞确定审查模式（完整 / 快速 / 指定支柱 / 评分）——阅读审查模式。判断工作负载是否匹配某个实时镜头；如果匹配，则阅读镜头指南。

第 2 步：基础设施发现

阅读并遵循发现流程。

第 3 步：应用程序架构发现

继续遵循发现流程，包括评估前的内部完整性门槛。

步骤 4：获取并冻结实时语料清单（ACQUIRE_CORPUS 门禁）

阅读并遵循实时语料清单流程。首先创建本次审查使用的运行本地工作目录，用于存放临时状态——即 corpus/ 文件夹，其中包含下文提到的 questions.jsonl、best-practices.jsonl 和 manifest.json。然后，通过有界、只读遍历规范框架页面，构建完整的实时语料清单（问题 + 最佳实践清单）；优先使用 aws___read_documentation（非 MCP HTTPS 回退方案请参阅参考文档），立即将每个页面转换为结构化记录，并验证清单。

门禁： 在 corpus/manifest.json 报告 valid: true 之前，MUST NOT 开始步骤 5。冻结的清单是评估、覆盖审计和报告中预期问题集与最佳实践集的唯一依据。

步骤 5：根据冻结清单评估每一项最佳实践

重要——不得生成简短审查。 最常见的失败是只引用部分最佳实践就停止。完整审查 MUST 评估冻结清单中的每一项最佳实践，并为每项提供五值词汇表中的一个状态及理由。

阅读并遵循评估流程。该流程定义了针对冻结清单的逐支柱评估、汇总、按模式调整以及覆盖审计（子步骤标记为 5a–5d）。对于每一项最佳实践，评估：

• 状态：只能是以下值之一：“Implemented”“Partially Implemented”“Not Implemented”“Not Applicable”“Cannot Determine”
• 证据：具体文件路径和行号（或“Based on description”）
• 差距：缺少什么或可以改进之处
• 风险：这些差距可能导致什么问题

根据冻结清单中的支柱名称、前缀和问题类别，评估每个支柱。

步骤 6：风险评估

阅读并遵循风险评估流程，包括其中的内部门禁。

步骤 7：生成报告

模式门禁： 对于评分模式，仅输出审查模式中的评分卡内容。对于快速和限定支柱范围的审查，应用审查模式中的模式调整。对于仅 Lens 请求（用户指定了单个 WA Lens，且未要求进行完整框架审查），生成独立的 Lens 报告——省略核心框架表格，交付内容为Lens Findings部分和 Lens 评分卡，并遵循Lens 指南；当 Lens 应用于完整审查之上时，保留完整结构并添加 Lens Findings 部分。其他情况下，即进行完整审查时，阅读报告模板，并严格按照该结构生成报告。报告模板是必需章节的权威清单；以下是最容易被能力较弱的模型遗漏、对回忆至关重要的章节（不得将其视为完整清单）：

1. 覆盖审计（来自评估流程的步骤 5d），置于执行摘要之前
2. 支柱评分卡，包含各支柱的评分（1-5）
3. 逐问题评估表——涵盖冻结清单中的每个问题，不得截断
4. 完整最佳实践台账——每项已评估最佳实践占一行，逐字合并各支柱评估内容
5. 按风险分类的发现（Critical/High 详细展开，Medium 精简呈现，Low 以表格列出）
6. 按艾森豪威尔矩阵优先级排序的补救计划（Do First / Plan / Delegate / Defer），并包含 SMART 目标

将报告直接作为最终回复输出，首行必须为 # Well-Architected Review:。不得将任何章节转移到文件中。

步骤 8：提供后续选项

交付报告后，提供以下选项：

你希望我：

• 深入分析某个特定支柱，并提供更详细的分析？
• 生成 IaC 模板以修复某项特定发现？
• 针对某项特定架构变更制定迁移计划？
• 根据某个特定的 WA Lens 对你的工作负载进行详细比较？
• 生成自动化检查（Config 规则、自定义指标），以持续满足合规要求？
• 生成 WA Tool 导入文件，以便在 AWS 控制台中跟踪？

评估校准指南

• 如果工作负载具备多可用区、加密、带回滚的 CI/CD、监控和自动扩缩，则属于成熟状态——大多数发现应归为改进项，而非严重问题
• 不要为设计良好的工作负载凭空制造严重问题——准确性比危言耸听更重要
• 当业务关键性为“低”或“标准”时，接受更简单的架构（内部工具采用单区域架构即可）
• 当业务关键性为“关键”时，采用更严格的标准（多区域 DR、混沌测试，预计 RTO 小于 1 分钟）
• 每项发现都必须有代码证据作为依据——不得提出缺乏依据的泛泛建议
• 如果无法从代码中确定某项信息，请说明“无法确定”，并解释需要哪些运行时数据或访谈信息
• 突出肯定优势——对于成熟的工作负载，应予以肯定，而不应一味批评

安全注意事项

在使用审查工具、分享发现或持久化制品之前，请阅读并遵循安全注意事项。