Azure 可靠性评估与配置

快速参考

| 属性 | 详情 | |---|---| | 适用场景 | 可靠性状况评估、启用区域冗余、设置多区域故障转移 | | 主要能力 | 可靠性评估表、区域冗余配置、多区域 IaC 生成 | | 支持的服务 | Azure Functions、App Service（计划在未来版本中支持 Container Apps） | | MCP 工具 | Azure Resource Graph 查询、Azure CLI 命令 |

何时使用此 Skill

用户有以下需求时，激活此 skill：

• "评估我的 Function 应用的可靠性"
• "评估我的 Web 应用的可靠性"
• "检查我的资源组的可靠性"（仅限 App Service 和 Functions 资源）
• "我的应用是否具备区域冗余？"（仅限 App Service 和 Functions 资源）
• "我的 App Service 计划是否具备区域冗余？"
• "为我的应用启用区域冗余"（仅限 App Service 和 Functions 资源）
• "为我的 App Service 计划启用区域冗余"
• "为我的应用设置多区域故障转移"（仅限 App Service 和 Functions 资源）
• "检查我的可靠性状况"
• "查找单点故障"（仅限 App Service 和 Functions 资源）
• "为我的应用启用高可用性"（仅限 App Service 和 Functions 资源）
• "检查灾难恢复就绪情况"
• "提高我的应用的弹性"（仅限 App Service 和 Functions 资源）

范围说明： 此 skill 当前仅涵盖 Azure Functions 和 Azure App Service。如果用户询问 Azure Container Apps 的可靠性，请说明已计划提供支持但目前尚不可用，并且只继续处理适用于范围内 App Service 和 Functions 资源的部分。

先决条件

• 身份验证：用户已通过 az login 登录 Azure
• 权限：对目标订阅/资源组具有读取者访问权限（用于评估）
• 权限：具有参与者访问权限（用于配置更改）
• Azure Resource Graph 扩展：az extension add --name resource-graph

MCP 工具

| 工具 | 用途 | |------|---------| | mcp_azure_mcp_extension_cli_generate | 生成用于资源查询和配置的 az CLI 命令 | | mcp_azure_mcp_subscription_list | 列出可用订阅 | | mcp_azure_mcp_group_list | 列出资源组 |

主要查询方式：通过 az graph query 使用 Azure Resource Graph（需要 az extension add --name resource-graph）。

评估工作流

阶段 1：发现资源

1. 确定范围 — 向用户询问资源组、订阅或应用名称
2. 查询 Azure Resource Graph，发现范围内的所有资源
3. 按服务类型对资源分类（Functions、存储等）。如果发现非 Functions 计算资源（不是 Function 应用的 App Service 站点、Container Apps），请记录但不要深入分析 — 这些服务计划在此 skill 的未来版本中支持。

重要： 始终将查询范围限定为用户指定的资源组或订阅。将以下筛选器添加到每个 Resource Graph 查询：

• 资源组：| where resourceGroup =~ '<rg-name>'
• 订阅：在 az graph query 中使用 --subscriptions <sub-id> 标志
• 应用名称：| where name =~ '<app-name>'

阶段 2：评估可靠性

两步评估：先进行平台级发现，再按服务深入分析。

步骤 1 — 平台发现（了解有哪些资源）。 使用以下内容枚举范围内的资源，并检测跨服务的可靠性缺口：

| 平台检查 | 参考 | |---|---| | 区域冗余 — 发现 | [references/zone-redundancy-checks.md](references/zone-redundancy-checks.md) | | 存储冗余（跨服务） | [references/storage-redundancy-checks.md](references/storage-redundancy-checks.md) | | 多区域和全局负载均衡器 | [references/multi-region-checks.md](references/multi-region-checks.md) | | Front Door / Traffic Manager / App Insights 探测 | [references/health-probe-checks.md](references/health-probe-checks.md) |

步骤 2 — 按服务深入分析。 对步骤 1 中发现的每个计算资源，加载匹配的服务参考文档。服务参考文档是该服务的计划/SKU 规则、评估查询、CLI 命令、IaC 补丁（Bicep + Terraform + AVM）及报告提示的唯一可信来源。

此 skill 版本仅提供 Azure Functions 和 App Service 的按服务参考文档。下面明确列出了其他计算服务，以确保分派逻辑清晰无歧义：如果资源与不受支持的行匹配，不得尝试加载参考文档、编造 CLI 命令或为其生成 IaC 补丁。

| 检测到的服务 | 参考文档 | |---|---| | Azure Functions（microsoft.web/serverfarms，且满足 kind contains 'functionapp'） | [references/services/functions/reliability.md](references/services/functions/reliability.md) | | Azure App Service（非 Functions 站点：microsoft.web/sites 不满足 kind contains 'functionapp'，microsoft.web/serverfarms 不满足 kind contains 'functionapp'） | [references/services/app-service/reliability.md](references/services/app-service/reliability.md) | | Azure 容器应用（microsoft.app/containerapps、microsoft.app/managedenvironments） | ⚪ 尚未发布 — 计划在未来版本中提供 |

处理不受支持的服务： 如果资源与上面的不受支持行匹配，请在发现摘要中列出该资源，在阶段 3 的表格中将其标记为 ⚪ not assessed (planned)，并跳过该资源的按服务修复步骤。不得尝试为这些服务编造 CLI 命令或 IaC 补丁。

阶段 3：生成可靠性检查清单

将发现结果以功能为主维度的表格呈现：每项可靠性功能一行（计算资源区域冗余、区域冗余存储、运行状况探测、多区域故障转移），包含一个状态指示符以及与该功能相关的具体资源。这可以避免每个资源一行、且大多数单元格都是 n/a 所产生的冗余信息。不得给出数值评分或等级。

🔍 Reliability Assessment — {scope}
─────────────────────────────────────────────────────────────────────────────────────────────
Reliability Feature              Status      Resources
─────────────────────────────────────────────────────────────────────────────────────────────
Zone redundancy — compute        🔴 OFF      • plan-web-ii5trxva2ark4 (P1v3)
                                              • plan-ii5trxva2ark4 (FC1)

Zone-redundant storage           🔴 GRS      • stii5trxva2ark4 (defaulted; no SKU set in IaC)

Health probes                    🔴 OFF      • func-api-ii5trxva2ark4 — needs code change (FC1)
                                              • app-web-ii5trxva2ark4 — no health check path

Multi-region failover            🔴 OFF      • Single region (eastus) only — Front Door not configured
─────────────────────────────────────────────────────────────────────────────────────────────

Want me to fix the 🔴 items? I'll do the quick wins first (App
plan zone redundancy + health checks on supported plans), then ask before
storage migration and multi-region setup. (yes/no)

表格规则：

• 按以下顺序列出四个功能行： 区域冗余 — 计算资源 · 区域冗余存储 · 运行状况探测 · 多区域故障转移。仅当某项功能不可能适用于范围内的任何资源时，才完全省略对应行。
• 状态列由一个符号和一个简短单词组成，不包含其他字符：
• 🟢 ON — 该功能已在范围内的所有相关资源上完全启用
• 🟡 PARTIAL — 部分资源已启用，部分资源未启用（或仅完成部分配置，例如只有存活探测）
• 🔴 OFF — 该功能在所有相关资源上均未启用
• 对于存储，请在适用时将 OFF 替换为当前 SKU（🔴 LRS、🔴 GRS、🟢 ZRS、🟢 GZRS）。如果 IaC 中未设置 SKU，则标记为 🔴 GRS（ARM/AVM 的默认值），并在资源行中注明这一点。
• 资源列仅列出与该功能相关的资源，每个资源使用一个项目符号：
• 对于“需要修复”的资源，请附上简短的行内原因（(FC1)、(defaulted; no SKU set)、liveness only、needs code change (FC1)）。
• 对于该功能已经启用的资源，请在同一行中列出，并添加 — already ON，让用户看到哪些配置已正确启用。
• 不得包含 n/a、— 或空单元格。如果某项功能不适用于范围内的任何资源，请删除该行。
• 不得包含数值评分、等级或总分。
• 评估结束时仅提出一个是/否问题，以启动分阶段修复流程。不得在此处按资源逐项列出修复清单 — 用户回答“是”后会看到该清单（配置工作流步骤 1）。

UX 注意事项： 如果评估发现应用已经具备所有核心可靠性功能（区域冗余、ZRS/GZRS 存储、运行状况探测），请跳过修复询问，直接转到配置工作流的[步骤 3](#step-3-both-paths-multi-region-followup--ask-and-wait)（多区域后续操作）。未经用户明确同意，不得启动任何多区域工作。

配置工作流

当用户希望修复评估中发现的问题时：

⛔ 执行任何更改前，都必须先获得用户确认。 说明将更改的内容、任何成本影响以及任何破坏性操作（例如重新创建环境）。

步骤 1：提供修复计划并选择路径

评估后，如果用户说“修复它”/“提高可靠性”/“启用区域冗余”时：

1. 列出每个可修复的问题及其具体操作
2. 标明任何成本影响或破坏性变更
3. 询问用户希望选择哪条路径：

I'll start with the quick wins (no downtime, fast):

1. ✏️  Enable zone redundancy on plan-ii5trxva2ark4 (Flex Consumption — no cost change)
2. ✏️  Set health check path to /api/health on func-api-ii5trxva2ark4

Then, separately, I'll ask if you want to upgrade storage:

3. 🕒  Upgrade stii5trxva2ark4 from LRS → ZRS (small cost increase, migration takes hours)
   — Required for full zone redundancy, but I'll confirm with you before starting.

How would you like to apply these changes?

  A) Fix now — Run az CLI commands against your live resources (immediate, one-time)
  B) Patch my IaC — Update your Bicep/Terraform files so changes persist across deploys

(If you use azd or Terraform, option B is recommended so `azd up` won't overwrite changes.)

路径 A：立即修复（CLI）

使用 az CLI 命令对正在运行的资源执行修复。先处理可快速见效的修复项，然后在执行耗时的存储迁移前询问用户。

每项服务的准确 CLI 命令都位于按服务提供的参考文档中 — 请选择与阶段 2 中发现的资源匹配的参考文档：

| 修复项 | 参考文档 | |---|---| | 启用区域冗余/配置运行状况探测（Functions） | [references/services/functions/reliability.md](references/services/functions/reliability.md) | | 启用区域冗余/配置运行状况探测（App Service） | [references/services/app-service/reliability.md](references/services/app-service/reliability.md) | | 升级存储复制设置（跨服务） | [references/configure-storage.md](references/configure-storage.md) | | 设置多区域（跨服务） | [references/configure-multi-region.md](references/configure-multi-region.md) | | 平台概览/验证 | [references/configure-zone-redundancy.md](references/configure-zone-redundancy.md), [references/configure-health-probes.md](references/configure-health-probes.md) |

执行顺序 — 始终先处理可快速见效的修复项：

1. 计算资源的区域冗余（速度快，对应用计划进行就地属性更新）。
2. 运行状况探测（仅限高级版/专用版 — 就地更新；对于 FC1/消耗计划，请遵循 [configure-health-probes.md](references/configure-health-probes.md) 中的用户同意确认要求）。
3. 验证计算资源更改是否成功，再执行任何其他操作。
4. ⛔ 停止 — 询问是否升级存储。 计算资源现在已实现区域冗余，但存储仍可能使用 LRS 或 GRS。请明确询问用户：

``` ✅ Compute is now zone-redundant.

To be fully zone-redundant, your storage account also needs to be upgraded: • stii5trxva2ark4: currently Standard_LRS → needs Standard_ZRS

⚠️ This is a live storage redundancy conversion: • Takes hours to days depending on data volume • Small ongoing cost increase (~$0.01/GB/month more) • Only supported for Standard general-purpose v2 accounts

Do you want me to start the storage migration now? (yes / no / later) ```

• 是 → 运行 az storage account update --sku Standard_ZRS（必要时运行 migration start）；轮询 az storage account show --query sku.name，直到其报告 Standard_ZRS。
• 否 / 稍后 → 保持存储不变；在重新评估中注明 ZR 存储仍是一个缺口。

1. 多区域 — 不得自动运行。重新评估后，将其作为明确的后续操作，按下方步骤 3处理。

⚠️ 警告：如果用户稍后使用 azd up 或 terraform apply，仅通过 CLI 进行的更改可能会被 IaC 定义覆盖。建议还在完成 CLI 修复后修补 IaC。

路径 B：修补 IaC

更新用户的 Bicep 或 Terraform 文件，使可靠性设置持久生效。

步骤 1：检测 IaC 类型

1. 在项目根目录中查找 infra/ 文件夹
2. 如果未找到，请在项目根目录中检查 *.bicep 或 *.tf 文件
3. 如果仍未找到，请询问用户：“您的 IaC 文件位于何处？”
4. 检查是否有 *.bicep 文件 → 使用 Bicep 修补
5. 检查是否有 *.tf 文件 → 使用 Terraform 修补
6. 如果两者都存在，请询问用户要修补哪一种
7. 如果不存在 IaC，则回退到路径 A（CLI）并告知用户

步骤 2：按风险等级对每个修复项进行分类

| 修复项 | 风险等级 | 具体变化 | |-----|-----------|--------------| | 可用区冗余（应用计划） | 🟢 安全补丁 | 下次部署时就地更新属性 | | 存储 LRS → ZRS | 🟡 需要预迁移 | 必须先完成在线存储迁移，才能部署 IaC SKU 更改。禁止与安全补丁捆绑 — 使用步骤 3–5 中的两次部署流程。 | | 健康检查路径（基本/标准/高级 / 专用） | 🟢 安全补丁 | 就地更新，但会导致应用重启 | | 健康检查路径（FC1 / 消耗计划） | ⚪ 仅修改代码 — 必须先询问 | 不支持 healthCheckPath。添加健康检查端点需要在应用代码中添加一个由 HTTP 触发的 /api/health 函数。接触源代码前，必须始终征得用户明确同意。 不得修补 IaC。 |

步骤 3：分两次部署应用补丁（先处理快速见效项）

IaC 修补框架（检测、AVM 模块指南、部署顺序规则、存储 SKU 补丁）位于：

| IaC 类型 | 框架参考 | |---|---| | Bicep | [references/iac-patching-bicep.md](references/iac-patching-bicep.md) | | Terraform | [references/iac-patching-terraform.md](references/iac-patching-terraform.md) |

实际的针对各服务的计算资源补丁（Function App 计划 ZR、App Service 计划 ZR 等）位于各服务参考文档中 — 从阶段 2 加载匹配的服务文件，以获取准确的 Bicep / Terraform / AVM 代码片段。此 skill 版本中，只有 Azure Functions 和 App Service 提供各服务参考文档；Container Apps 不在范围内。

部署 1 — 仅处理快速见效项。 修补 🟢 安全项（App Service/Function App 计划的可用区冗余，以及基本/标准/高级 / 专用计划上的健康探测）。本次部署中不得包含存储 SKU 补丁。

修补后，skill 会自行运行部署（不得停止并让用户自行运行）。检测部署工具，并在执行前确认一次：

📦 Patches applied to your IaC. Ready to deploy:
   Tool detected: azd (found azure.yaml)
   Command:       azd up

Proceed with deployment? (yes / no)

若选择是，运行相应命令，将输出流式返回给用户，并在成功后继续下一步：

• AZD 项目（包含 azure.yaml）：azd up
• Bicep-only: az deployment group create --resource-group <rg> --template-file infra/main.bicep --parameters @infra/main.parameters.json
• Terraform：terraform plan -out tfplan →（显示计划摘要）→ terraform apply tfplan

若选择否，停止并报告已修补的文件；不得继续执行步骤 4 / 重新评估。

如果部署失败，请向用户显示错误并停止 — 不得继续执行存储步骤。

⛔ 停止 — 在部署 2 前询问是否升级存储。 部署 1 成功后，明确询问用户：

✅ Quick-win patches deployed. Compute is now zone-redundant.

To be **fully zone-redundant**, your storage account also needs to be upgraded:
  • stii5trxva2ark4: currently `Standard_LRS` → needs `Standard_ZRS`

⚠️  This is a two-part change:
   1. Live storage migration (`az storage account migration start`) — takes hours to days
   2. A second deploy to update your IaC's storage SKU to match

Do you want me to start the storage migration now? (yes / no / later)

• 是 → skill 自行运行迁移命令，轮询至完成，然后修补 IaC 中的存储 SKU 并运行部署 2（此时为无操作确认）。用户无需手动运行任何操作。
• 否 / 稍后 → 保持存储 SKU 补丁未应用。在重新评估中注明 ZR 存储仍是一个缺口；建议稍后再处理。

步骤 4：存储迁移（仅当用户在步骤 3 中选择“是”时）

skill 自行运行这些命令 — 不得要求用户运行。执行期间显示进度：

🔄 Starting storage migration (this can take up to 72 hours)...

   az storage account migration start --name stii5trxva2ark4 \
     --resource-group rg-example --sku Standard_ZRS --no-wait

   Polling: az storage account show --name stii5trxva2ark4 --query sku.name
   ...
   ✅ Migration complete: sku.name = Standard_ZRS

对于耗时很长的迁移，可以向用户显示一个检查点（“此操作仍在运行，请稍后再查看”），而不是阻塞整个对话。

步骤 5：部署 2 — 存储 SKU 补丁

迁移完成后，skill 修补 IaC 中的存储 SKU，并运行与步骤 3 相同的部署命令（例如 azd up）。此次部署是一次无操作确认，用于确认 IaC 与实际状态一致。执行前向用户确认一次，然后直接运行。

步骤 2（两种路径）：重新评估

通过 CLI 应用更改或通过 IaC 部署更改后，自动重新运行评估，并显示与阶段 3 相同的以功能为维度的表格，更新每个功能行的状态以反映新状态。简要说明与上一次运行相比发生了哪些变化。

🔄 Reliability Re-Assessment — rg-eventhubs-python-jan13 (eastus)
───────────────────────────────────────────────────────────────────────────────────────
Reliability Feature              Status      Resources
───────────────────────────────────────────────────────────────────────────────────────
Zone redundancy — compute        🟢 ON       • plan-ii5trxva2ark4 (FC1)              — now ON
                                             • plan-web-ii5trxva2ark4 (P1v3)         — now ON

Zone-redundant storage           🟢 ZRS      • stii5trxva2ark4                       — GRS → ZRS

Health probes                    🟡 PARTIAL  • func-api-ii5trxva2ark4                — still off (FC1, code change declined)
                                             • app-web-ii5trxva2ark4                 — now ON

Multi-region failover            🔴 OFF      • Single region (eastus) only
───────────────────────────────────────────────────────────────────────────────────────

What changed: Function App and App Service plan zone redundancy, storage replication and health probes on App Service.
(Multi-region offered next — see Step 3.)

步骤 3（两种路径）：多区域后续操作 — 询问并等待

多区域部署是成本和复杂性均显著增加的一步。不得自动启动。重新评估后，只有在所有核心单区域可靠性功能均为 🟢 ON（实现区域冗余的计算资源、ZRS/GZRS 存储、运行状况探测）时，才应明确询问用户，并在执行任何操作前等待用户响应：

🟢 Your app is now fully zone-redundant in {region}.

The next step (optional) is multi-region failover with Azure Front Door:
   • Deploys compute + storage in a second region (paired region recommended)
   • Adds Azure Front Door for global load balancing with health-probe-driven failover
   • Protects against full region outages
   • Estimated additional cost: ~2x compute (active-passive); Front Door ~$35/month base

Do you want me to set up multi-region failover now? (yes / no / later)

• 是 → 按照 [references/configure-multi-region.md](references/configure-multi-region.md) 继续操作。与用户确认次要区域的选择，然后：

1. 生成多区域 IaC（为次要区域 + Front Door 添加 Bicep / Terraform 配置）。
2. 向用户确认一次：📦 Multi-region IaC generated. Ready to deploy with \azd up\。是否继续？（是 / 否）
3. On yes, the skill runs the deploy itself (azd up / az deployment group create / terraform apply) 并流式输出结果。不得停止操作并要求用户自行运行部署。
4. 部署成功后，执行最后一次重新评估，让用户看到多区域故障转移变为 🟢 ON。

• 否 / 稍后 → 保持当前部署不变。说明具备区域冗余的单区域部署是一种可靠的最终状态；多区域部署可随时重新考虑。

⛔ 不得跳过等待。在用户明确同意之前，不得生成多区域 IaC、部署 Front Door 或修改任何文件。如果核心可靠性功能尚未全部为 🟢，则不得询问是否采用多区域部署，而应先解决核心缺口。

优先级分类

| 优先级 | 条件 | 操作 | |---|---|---| | 严重 | 无区域冗余且为生产工作负载 | 立即修复 | | 高 | 已实现区域冗余的计算资源使用 LRS 存储 | 数日内修复 | | 中 | 未采用多区域部署（单区域但已实现区域冗余） | 纳入下一个迭代计划 | | 低 | 缺少运行状况探测或存在监控缺口 | 跟踪并修复 |

错误处理

| 错误 | 消息 | 修复措施 | |---|---|---| | 需要身份验证 | "请登录" | 运行 az login 并重试 | | 访问被拒绝 | "禁止访问" | 确认已分配读取者/参与者角色 | | 服务计划不支持 ZR | "需要升级" | 告知用户服务计划的升级路径和成本差额 | | 区域不支持 AZ | "区域限制" | 建议选择受支持的区域 |

最佳实践

• 每次重大基础设施变更后都执行可靠性评估
• 定期测试故障转移场景（至少每季度一次）

Skill 边界

| 操作 | 此 skill 可以执行 | 转交给 | |---|---|---| | 评估可靠性状况 | ✅ 是 | — | | 提出改进建议 | ✅ 是 | — | | 启用区域冗余（CLI 命令） | ✅ 是 | — | | 修补 Bicep/Terraform 的可靠性配置 | ✅ 是 | — | | 生成多区域 IaC | ✅ 是（为次要区域 + Front Door 添加配置） | azure-prepare，用于完整搭建新应用的 IaC 脚手架 | | 部署用于可靠性变更的 IaC | ✅ 是（经用户确认后，自行运行 azd up / terraform apply / az deployment） | azure-deploy，用于常规部署或非可靠性部署 | | 部署前验证 | 仅执行可靠性检查 | azure-validate，用于完整验证 |