azure-well-architected-review

Azure 良好架构评审

此工作流会针对工作负载的 IaC 文件和已部署基础设施，开展结构化的 Azure 良好架构框架（WAF）评审。它会识别所有 5 个 WAF 支柱中的风险，并创建 GitHub issue 以跟踪整改工作。

前提条件

• 已配置并完成身份验证的 Azure CLI（az）
• 仓库中包含 IaC 文件（Bicep、Terraform 或 ARM 模板）
• 已配置并完成身份验证的 GitHub MCP 服务

工作流步骤

步骤 1：加载良好架构框架参考资料

获取最新的 Azure WAF 最佳实践：

• https://learn.microsoft.com/en-us/azure/well-architected/
• 正在使用的 Azure 服务的服务指南（https://learn.microsoft.com/en-us/azure/well-architected/service-guides/）
• 与工作负载类型（SaaS、关键任务、AI 等）相关的工作负载专属指导

如果 microsoft.docs.mcp MCP 服务可用，请使用它查询最新的支柱检查清单和特定于服务的建议。

步骤 2：发现 IaC 和架构

确定评审范围，然后盘点代码和实时环境：

1. 确认 Azure 范围：询问用户哪些订阅和/或资源组在范围内，或根据 IaC 参数推断并予以确认。
2. 扫描仓库中的 IaC 文件：
   • Bicep：**/*.bicep、bicepconfig.json
   • Terraform：**/*.tf（azurerm/azapi 提供程序）
   • ARM 模板：**/azuredeploy*.json、**/*.template.json、$schema 包含 deploymentTemplate 的文件
3. 盘点实时资源（即使存在 IaC，也始终执行）：az resource list --resource-group <rg> --output json（或针对整个订阅），并使用 az <service> show 定向调用，获取支柱检查所需的配置详情。
4. 将 IaC 与实时资源清单进行比较：标记偏差——Azure 中存在但 IaC 中没有的资源（通过门户创建）、IaC 中定义但尚未部署的资源，以及配置不匹配。记录偏差发现，供步骤 3 使用（这些通常对应卓越运营支柱）。

识别正在使用的关键 Azure 服务（计算、数据、网络、安全、可观测性），并生成 Mermaid 架构图。

步骤 3：逐个支柱进行评审

支柱 1：可靠性

• 为支持可用性区域的服务（VM、VMSS、AKS 节点池、App Service、SQL、Storage ZRS）启用可用性区域
• 生产 SKU 满足所需 SLA（关键路径上不使用 Basic/Free 层）
• 已为 Azure SQL / Cosmos DB 配置备份和时间点还原，并设置适当的保留期
• 在 RPO 有要求时配置异地冗余（GRS/RA-GRS 存储、SQL 故障转移组、Cosmos DB 多区域）
• 已为 App Service 计划、VMSS、AKS 配置自动缩放规则（生产环境不使用固定的单实例）
• 已为 Load Balancer / Application Gateway / Front Door 后端配置运行状况探测
• 已为 Service Bus 队列/订阅和 Event Grid 订阅启用死信处理
• 已实施具有指数退避的重试策略，以处理瞬时故障
• 已制定灾难恢复计划（记录 RTO/RPO 并测试故障转移）

支柱 2：安全性

• 使用托管标识，而非包含机密或连接字符串的服务主体
• IaC 或代码中没有硬编码的凭据、密钥或连接字符串
• 机密存储在 Azure Key Vault 中，并使用 RBAC 授权（而非访问策略）
• 存储帐户禁止公共 Blob 访问，并在可能的情况下禁用共享密钥访问
• PaaS 数据服务使用专用终结点（或至少使用服务终结点和防火墙规则）
• NSG 将入站流量限制为所需的最少端口/CIDR（没有 * → * 允许规则）
• 所有终结点均强制使用 TLS 1.2 或更高版本（minimumTlsVersion、httpsOnly）
• Azure RBAC 遵循最小特权原则（工作负载标识在订阅范围内没有 Owner/Contributor 角色）
• 为相关资源类型启用 Microsoft Defender for Cloud（az security pricing list）
• 为面向公众的 Web 终结点配置 Azure WAF（Application Gateway 或 Front Door）
• 诊断设置将安全日志发送到 Log Analytics / Microsoft Sentinel

支柱 3：成本优化

• 已评估为稳定状态的计算资源（VM、App Service、SQL）使用预留或节省计划
• 存储生命周期管理策略将 Blob 移至低频访问/存档层
• 根据实际使用情况选择合适的 SKU（没有规格过高的 VM/App Service 计划）
• 开发/测试环境使用自动关机计划，并在符合条件时采用 Dev/Test 定价
• 已配置 Azure 预算和成本警报（az consumption budget list）
• 已识别并移除未附加的托管磁盘和孤立的公共 IP
• 对负载波动大或用量低的工作负载使用按需计费/无服务器层（Functions、Container Apps、SQL serverless）
• 调整 Log Analytics 的保留期和数据上限设置，避免摄取量超限

支柱 4：卓越运营

• 所有基础设施均以 IaC 定义（不手动更改门户；在可行时使用拒绝分配或策略）
• 在所有资源中应用一致的标记策略（所有者、环境、成本中心）
• 为关键指标和服务运行状况定义 Azure Monitor 警报
• 配置自动化部署管道（GitHub Actions / Azure Pipelines，不手动部署）
• 将 Azure Activity Log 和资源诊断设置路由到 Log Analytics
• 为应用程序工作负载配置 Application Insights（或等效的 OpenTelemetry）
• 通过 Azure Policy 分配强制执行组织标准（允许的位置、SKU、标记）
• 提供运行手册或运维文档

支柱 5：性能效率

• 根据负载要求验证计算 SKU 的规格是否合适
• 在有益的情况下实施缓存（Azure Cache for Redis、CDN/Front Door 缓存）
• 使用 Azure Front Door 或 CDN 分发全球静态内容
• 根据负载指标而非固定实例数进行自动缩放
• 数据库性能层级适当（DTU 与 vCore、弹性池、Cosmos DB RU 自动缩放）
• 对延迟敏感的磁盘工作负载使用高级/区域冗余存储
• 数据库和 HTTP 客户端采用连接池和异步模式

步骤 4：风险分类

对每项发现进行分类：

• 高风险：安全漏洞、单点故障、没有备份/恢复
• 中风险：可靠性欠佳、成本效率低、性能问题
• 低风险：未遵循最佳实践、存在轻微的优化机会

步骤 5：用户确认

🏗️ Azure Well-Architected Review Summary

📊 Review Results:
• IaC Files Analyzed: X
• Azure Services Identified: Y
• Total Findings: Z
  • High Risk: A (immediate action required)
  • Medium Risk: B (should address soon)
  • Low Risk: C (nice to have)

🔴 Top High Risk Findings:
1. [Pillar]: [Finding] — [Why it matters]
2. [Pillar]: [Finding] — [Why it matters]

💡 This will create Z individual GitHub issues + 1 EPIC issue.

❓ Proceed with creating GitHub issues? (y/n)

关卡：只有在用户明确肯定答复（例如“y”“yes”）后，才能继续执行步骤 6–7。如果答复是否定的、含糊不清或缺失，不得创建任何 GitHub issue — 应将完整的发现以格式化的 Markdown 输出到控制台，然后停止。

步骤 6：为每项发现创建单独的 issue

添加标签“well-architected”和支柱名称（例如“security”“reliability”）。

标题：[WAF-<PILLAR>] [Brief Finding] — [Risk Level]

正文：

## 🏗️ Well-Architected Finding: [Brief Title]

**Pillar**: [Name] | **Risk Level**: [High/Medium/Low] | **Effort**: [Low/Medium/High]

### 📋 Description
[Clear explanation of the finding and why it matters]

### 🔧 Remediation

**IaC Fix** (preferred):
```bicep
// Bicep example
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageAccountName
  location: location
  sku: { name: 'Standard_ZRS' }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
    supportsHttpsTrafficOnly: true
  }
}
```

**Azure CLI fallback**:
```bash
az storage account update --name <name> --resource-group <rg> \
  --min-tls-version TLS1_2 --allow-blob-public-access false --https-only true
```

### 📚 Azure Reference
- [WAF Best Practice Link]
- [Microsoft Learn Documentation Link]

### ✅ Validation
- [ ] Change implemented in IaC and deployed
- [ ] Azure Policy compliance passes (if applicable)
- [ ] Microsoft Defender for Cloud recommendation resolved (if applicable)

**Well-Architected Recommendation**: [WAF checklist item this maps to]

步骤 7：创建 EPIC 跟踪问题

添加 "well-architected" 和 "epic" 标签。

标题：[EPIC] Azure Well-Architected Review — X findings across 5 pillars

正文：执行摘要，包含按支柱划分的表格（按风险级别统计发现数量）、Mermaid 架构图、链接到所有单个问题的优先级检查清单（高 → 中 → 低），以及成功标准：

• 所有高风险发现均已解决
• 中风险发现均有已接受的缓解计划
• 现有 Azure Monitor 警报或 Azure Policy 合规性未出现回归

错误处理

• 未找到 IaC 文件：仅通过 Azure CLI（az resource list）检查实时资源，并注明这一缺口
• Azure 权限不足：列出评审所需的只读角色（Reader、Security Reader）
• GitHub 创建失败：将所有发现以格式化 Markdown 输出到控制台

成功标准

• ✅ 已针对 IaC 和实时基础设施评审全部 5 个 WAF 支柱
• ✅ 所有发现均已按风险级别和支柱分类
• ✅ 每项发现均有可执行的修复步骤和 IaC 示例
• ✅ 已创建 GitHub 问题供团队跟踪
• ✅ 已生成用于 EPIC 上下文的架构图
• ✅ 已包含 Microsoft Learn 文档参考