azure-reliability

Azure 可靠性评估与配置

快速参考

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

何时使用此技能

当用户希望执行以下操作时，启用此技能：

• “评估我的 Function 应用的可靠性”
• “评估我的 Web 应用的可靠性”
• “检查我的资源组的可靠性”（仅适用于 App Service 和 Functions 资源）
• “我的应用是否具有区域冗余？”（仅适用于 App Service 和 Functions 资源）
• “我的应用服务计划是否具有区域冗余？”
• “让我的应用具有区域冗余”（仅适用于 App Service 和 Functions 资源）
• “让我的应用服务计划具有区域冗余”
• “为我的应用设置多区域故障转移”（仅适用于 App Service 和 Functions 资源）
• “检查我的可靠性态势”
• “查找单点故障”（仅适用于 App Service 和 Functions 资源）
• “为我的应用启用高可用性”（仅适用于 App Service 和 Functions 资源）
• “检查灾难恢复就绪情况”
• “提升我的应用的弹性”（仅适用于 App Service 和 Functions 资源）

**范围说明：**此技能目前仅涵盖 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、Storage 等）。如果发现 Container Apps，请记录，但不要深入分析。

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

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

阶段 2：评估可靠性

分两步评估：先在平台级别发现资源，再深入评估每项服务。

步骤 1 — 平台级别发现（查明现有资源）。 使用以下检查，列出范围内的资源，并发现跨服务的可靠性缺口：

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

步骤 2 — 深入评估各项服务。 对于步骤 1 中发现的每项计算资源，加载对应的服务参考资料。服务参考资料是该服务计划/SKU 规则、评估查询、CLI 命令、IaC 补丁（Bicep + Terraform + AVM）和报告提示的唯一事实来源。

此技能版本仅提供 Azure Functions 和 App Service的服务参考资料。下方明确列出了其他计算服务，以确保派发逻辑清晰无误：如果资源符合不受支持的行，不要尝试加载参考资料、编造 CLI 命令或为其生成 IaC 补丁。

检测到的服务	参考资料
Azure Functions（microsoft.web/serverfarms，且 kind contains 'functionapp'）	references/services/functions/reliability.md
Azure App Service（非 Functions 站点：microsoft.web/sites 且 kind 不包含 'functionapp'，microsoft.web/serverfarms 且 kind 不包含 'functionapp'）	references/services/app-service/reliability.md
Azure Container Apps（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 步（多区域后续步骤）。未经明确同意，不要开始任何多区域工作。

配置工作流

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

⛔ 执行更改前务必先征得用户确认。 说明将进行哪些更改、可能产生的费用以及任何破坏性操作（例如重新创建环境）。

第 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
启用区域冗余 / 配置运行状况探测（App Service）	references/services/app-service/reliability.md
升级存储复制（跨服务）	references/configure-storage.md
设置多区域（跨服务）	references/configure-multi-region.md
平台概述 / 验证	references/configure-zone-redundancy.md、references/configure-health-probes.md

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

1. 计算资源启用区域冗余（速度快，在 App 的计划上原位更新属性）。

2. 运行状况探测（仅适用于 Premium / Dedicated——原位更新；对于 FC1 / Consumption，请遵循 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 存储仍是一个缺口。

5. 多区域——不要自动运行。在下方的第 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 步：按风险等级对每项修复进行分类

修复项	风险等级	结果
区域冗余（App 计划）	🟢 安全修改	在下一次部署时原位更新属性
存储 LRS → ZRS	🟡 需要预先迁移	IaC SKU 更改部署前，必须先完成实时存储迁移。绝不要与安全修改打包——请使用第 3–5 步中的两次部署流程。
运行状况检查路径（Basic/Standard/Premium / Dedicated）	🟢 安全修改	原位更新，但会导致应用重启
运行状况检查路径（FC1 / Consumption）	⚪ 仅修改代码——先询问	不支持 healthCheckPath。添加运行状况端点需要在应用代码中添加一个由 HTTP 触发的 /api/health 函数。**修改源代码前，务必先征得用户明确同意。**不要修改 IaC。

第 3 步：分两次部署应用修改（先处理快速见效的项目）

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

IaC 类型	框架参考文档
Bicep	references/iac-patching-bicep.md
Terraform	references/iac-patching-terraform.md
每项服务实际使用的计算修补（Function App 计划 ZR、App Service Plan ZR 等）位于各项服务的参考文档中——从 Phase 2 加载匹配的服务文件，以获取准确的 Bicep / Terraform / AVM 代码片段。此技能版本中，只有 Azure Functions 和 App Service 有各自的服务参考文档；Container Apps 不在范围内。

部署 1 — 仅处理快速见效项。 应用 🟢 安全项修补（App Service/Function App 计划的区域冗余，以及 Basic/Standard/Premium / Dedicated 上的运行状况探测）。此部署中不要包含存储 SKU 修补。

修补完成后，由此技能自行运行部署（不要停下来让用户运行）。检测部署工具，并在执行前确认一次：

📦 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：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

用户回答否时，停止并报告已修补的文件；不要继续执行 Step 4 / Re-Assess。

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

⛔ 停止 — 执行部署 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)

• 是 → 此技能自行运行迁移命令，轮询直至完成，然后修补 IaC 中的存储 SKU 并运行部署 2（此时只是确认操作，无实际变更）。用户无需手动运行任何操作。
• 否 / 以后再说 → 不应用存储 SKU 修补。在重新评估中注明 ZR 存储仍是一个差距；建议稍后再处理。

Step 4：存储迁移（仅当用户在 Step 3 中回答是时）

此技能自行运行以下命令——不要让用户运行。过程中展示进度：

🔄 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

对于非常耗时的迁移，可以向用户提供进度提示（“仍在运行，请稍后再查看”），而不必让整个对话一直等待。

Step 5：部署 2 — 存储 SKU 修补

迁移完成后，此技能修补 IaC 中的存储 SKU，并运行与 Step 3 相同的部署命令（例如 azd up）。此部署用于确认 IaC 与实时状态一致，不会产生变更。执行前与用户确认一次，然后直接运行。

Step 2（两条路径均适用）：重新评估

应用更改（CLI 路径）或完成部署（IaC 路径）后，自动重新运行评估，并显示与 Phase 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 步（两种路径均适用）：多区域后续步骤——询问并等待

多区域会显著增加成本和复杂性。不要自动启动此步骤。重新评估后，只有在所有核心单区域可靠性功能均已🟢启用（区域冗余计算、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)

• yes → 按照 references/configure-multi-region.md 继续。与用户确认次要区域的选择，然后：
  1. 生成多区域 IaC（为次要区域添加 Bicep / Terraform 配置，以及 Front Door）。
  2. 向用户确认一次：📦 Multi-region IaC generated. Ready to deploy with \azd up`. Proceed? (yes / no)`
  3. 如果用户回答 yes，则由此技能自行运行部署（azd up / az deployment group create / terraform apply）并输出执行结果。不要停下来让用户运行命令。
  4. 部署成功后，进行最终重新评估，让用户看到多区域故障转移已变为🟢启用。
• no / later → 保持部署现状。说明单区域区域冗余是可靠的最终状态；之后随时可以重新考虑多区域。

⛔ 不要跳过等待。 在用户明确表示 yes 之前，不要生成多区域 IaC、部署 Front Door 或修改任何文件。如果核心可靠性功能尚未全部🟢启用，不要询问多区域事宜——先补齐核心功能。

优先级分类

优先级	标准	操作
Critical	无区域冗余，且承载生产工作负载	立即修复
High	区域冗余计算使用 LRS 存储	在数天内修复
Medium	无多区域（单区域但采用区域冗余）	计划在下一个冲刺中处理
Low	缺少运行状况探测或监控存在缺口	跟踪并修复

错误处理

错误	消息	解决方法
需要身份验证	"Please login"	运行 az login 并重试
访问被拒绝	"Forbidden"	确认已分配 Reader/Contributor 角色
计划不支持 ZR	"Upgrade required"	告知用户升级计划的途径及费用差额
区域不支持 AZ	"Region limitation"	建议使用受支持的区域

最佳实践

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

技能边界

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