Back to Details

wa-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Well-Architected Review

Well-Architected 评审

Step 1: Define the workload scope

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

Ask the user to describe the workload:
What workload would you like me to review? Please share:
  • Workload name and brief description
  • Architecture diagram or description (services, data flows, integrations)
  • Business criticality (revenue-generating, internal tool, compliance-sensitive, etc.)
  • Current pain points (optional — anything you already know is problematic)
If the user has already provided architecture details, skip the prompt and proceed.
请用户描述工作负载：
您希望我评审哪个工作负载？请分享：
  • 工作负载名称及简要描述
  • 架构图或架构说明（服务、数据流、集成方式）
  • 业务关键性（创收型、内部工具、合规敏感型等）
  • 当前痛点（可选——您已知的任何问题）
如果用户已提供架构细节，跳过此提示直接进行下一步。

Step 2: Identify applicable lens

步骤2：确定适用的视角（Lens）

Determine if a specialized WA Lens applies:
  • SaaS, Serverless, Data Analytics, Machine Learning, IoT, SAP, Games, Financial Services, Healthcare, etc.
If a lens applies, note it and incorporate lens-specific questions in the review.
判断是否适用专门的WA视角：
  • SaaS、Serverless、数据分析、机器学习、IoT、SAP、游戏、金融服务、医疗保健等
如果适用某一视角，记录下来并在评审中加入该视角的特定问题。

Step 3: Evaluate each pillar

步骤3：评估每个支柱

For each of the six pillars, assess the workload against key best practices:
针对六大支柱中的每一个，对照关键最佳实践评估工作负载：

Operational Excellence

运营卓越

  • How are changes deployed? (CI/CD, IaC, rollback strategy)
  • How is the workload monitored? (metrics, alarms, dashboards)
  • How are operational events handled? (runbooks, on-call, post-incident reviews)
  • Is there a continuous improvement process?
  • 如何部署变更？（CI/CD、IaC、回滚策略）
  • 如何监控工作负载？（指标、告警、仪表盘）
  • 如何处理运营事件？（运行手册、值班安排、事后复盘）
  • 是否有持续改进流程？

Security

安全性

  • How are identities and permissions managed? (IAM, least privilege, federation)
  • How is data protected? (encryption at rest/transit, key management)
  • How are security events detected and responded to? (GuardDuty, Security Hub, incident response)
  • Is network segmentation in place? (VPC, WAF, private subnets)
  • 如何管理身份与权限？（IAM、最小权限原则、联邦身份）
  • 如何保护数据？（静态/传输中加密、密钥管理）
  • 如何检测与响应安全事件？（GuardDuty、Security Hub、事件响应）
  • 是否已实施网络分段？（VPC、WAF、私有子网）

Reliability

可靠性

  • How does the workload handle component failures? (multi-AZ, retries, circuit breakers)
  • How is capacity managed? (auto-scaling, load testing, quotas)
  • How are changes managed to avoid outages? (deployment strategies, health checks)
  • Are backups and DR tested?
  • 工作负载如何处理组件故障？（多可用区、重试机制、断路器）
  • 如何管理容量？（自动扩缩容、负载测试、配额）
  • 如何管理变更以避免中断？（部署策略、健康检查）
  • 备份与灾难恢复（DR）是否经过测试？

Performance Efficiency

性能效率

  • Are the right resource types and sizes selected? (instance types, storage tiers, Graviton)
  • How is performance monitored? (latency percentiles, bottleneck identification)
  • Are there opportunities for caching, CDN, or async processing?
  • Are database access patterns optimized?
  • 是否选择了合适的资源类型与规格？（实例类型、存储层级、Graviton）
  • 如何监控性能？（延迟百分位数、瓶颈识别）
  • 是否有缓存、CDN或异步处理的优化机会？
  • 数据库访问模式是否已优化？

Cost Optimization

成本优化

  • Are resources right-sized? (utilization metrics, Savings Plans, Reserved Instances)
  • Are there idle or orphaned resources?
  • Is the pricing model appropriate? (on-demand vs spot vs reserved, serverless vs provisioned)
  • Is cost visibility and allocation in place?
  • 资源是否已合理调整规格？（利用率指标、Savings Plans、预留实例）
  • 是否存在闲置或孤立资源？
  • 定价模型是否合适？（按需 vs 竞价 vs 预留，Serverless vs 预置）
  • 是否具备成本可见性与分配机制？

Sustainability

可持续性

  • Is resource utilization maximized? (right-sizing, scaling to zero)
  • Are managed services used where possible?
  • Is data lifecycle managed? (tiering, expiration, compression)
  • Are efficient compute options used? (Graviton, serverless)
  • 是否最大化了资源利用率？（合理调整规格、缩容至零）
  • 是否尽可能使用托管服务？
  • 是否管理了数据生命周期？（分层、过期、压缩）
  • 是否使用了高效计算选项？（Graviton、Serverless）

Step 4: Classify findings

步骤4：分类发现结果

For each finding, assign:
  • Severity: 🔴 High Risk Issue (HRI) | 🟡 Medium Risk Issue (MRI) | 🟢 Improvement opportunity
  • Pillar: Which pillar it belongs to
  • Impact: What could go wrong if not addressed
  • Effort: Low / Medium / High to remediate
  • AWS Services: Which services to use for remediation
Calibration guidance:
  • If the architecture already follows best practices (multi-AZ, WAF, canary deployments, encryption, monitoring), most findings should be 🟢 Improvement opportunities — not 🔴 HRI
  • A mature architecture should score 4–5 on most pillars. Resist over-flagging where good practices exist.
  • For well-architected systems, focus on advanced improvements: chaos engineering, multi-region DR, cost modeling, game days, sustainability gains
  • Acknowledge existing strengths explicitly before listing gaps
针对每个发现结果，分配以下属性：
  • 严重程度：🔴 高风险问题（HRI）| 🟡 中风险问题（MRI）| 🟢 改进机会
  • 所属支柱：该结果属于哪个支柱
  • 影响：若不解决可能出现的问题
  • 修复工作量：低 / 中 / 高
  • AWS服务：修复可使用的AWS服务
校准指南：
  • 如果架构已遵循最佳实践（多可用区、WAF、金丝雀部署、加密、监控），大多数发现结果应为🟢改进机会——而非🔴高风险问题
  • 成熟的架构在大多数支柱上应得4–5分。对于已采用良好实践的部分，避免过度标记
  • 对于架构完善的系统，聚焦进阶改进：混沌工程、多区域灾难恢复、成本建模、故障演练、可持续性提升
  • 在列出差距前，明确认可现有优势

Step 5: Produce the report

步骤5：生成报告

Output a structured report:
markdown
undefined
输出结构化报告：
markdown
undefined

Well-Architected Review: {Workload Name}

Well-Architected 评审：{工作负载名称}

Summary

摘要

  • Date: {date}
  • Pillars reviewed: 6/6
  • Lens applied: {lens or "General"}
  • Findings: {X} HRI, {Y} MRI, {Z} Improvements
  • 日期：{date}
  • 评审支柱数：6/6
  • 适用视角：{lens或"通用"}
  • 发现结果：{X}个高风险问题，{Y}个中风险问题，{Z}个改进机会

Pillar Scorecard

支柱评分卡

PillarScore (1-5)Key Gap
Operational Excellence{score}{gap}
Security{score}{gap}
Reliability{score}{gap}
Performance Efficiency{score}{gap}
Cost Optimization{score}{gap}
Sustainability{score}{gap}
支柱评分（1-5）关键差距
运营卓越{score}{gap}
安全性{score}{gap}
可靠性{score}{gap}
性能效率{score}{gap}
成本优化{score}{gap}
可持续性{score}{gap}

High Risk Issues

高风险问题

{For each HRI: pillar, description, impact, recommendation, effort, AWS services to use}
{每个高风险问题：所属支柱、描述、影响、建议、工作量、可使用的AWS服务}

Medium Risk Issues

中风险问题

{For each MRI: pillar, description, impact, recommendation, effort, AWS services}
{每个中风险问题：所属支柱、描述、影响、建议、工作量、AWS服务}

Improvement Opportunities

改进机会

{For each improvement: pillar, description, benefit, recommendation, AWS services}
{每个改进项：所属支柱、描述、收益、建议、AWS服务}

Prioritized Remediation Plan

优先级修复计划

Quick Wins (< 1 week)

快速见效项（<1周）

{Low-effort, high-impact fixes — configuration changes, enabling services}
{低工作量、高影响的修复——配置变更、启用服务}

Foundation (1-4 weeks)

基础项（1-4周）

{Core architectural improvements — multi-AZ, monitoring, CI/CD}
{核心架构改进——多可用区、监控、CI/CD}

Strategic (1-3 months)

战略项（1-3个月）

{Major changes — re-architecture, multi-region, compliance programs}
{重大变更——重构、多区域部署、合规项目}

Next Steps

下一步行动

{Concrete actions the team should take this week}
undefined
{团队本周应采取的具体行动}
undefined

Step 6: Offer follow-up

步骤6：提供后续支持

After delivering the report, offer:
Would you like me to:
  • Deep-dive into any specific pillar?
  • Create an implementation plan for a specific finding?
  • Generate IaC templates to remediate an issue?
  • Compare alternative approaches for a recommendation?
  • Run a focused assessment (security, reliability, cost, etc.)?
交付报告后，提供以下选项：
您是否需要我：
  • 深入分析特定支柱？
  • 为特定发现结果制定实施计划？
  • 生成IaC模板以修复问题？
  • 对比建议方案的替代方法？
  • 开展专项评估（安全、可靠性、成本等）？