Azure Reliability Assessment & Configuration（azure-reliability）是 microsoft/azure-skills 提供的 Azure 可靠性评估与配置技能，用于评估和改善 PaaS 应用的可靠性状况。当前技能仅覆盖 Azure Functions 和 Azure App Service；对 Azure Container Apps 的支持已规划，但本版本尚未提供。
【适用场景】 当用户希望评估 Function 应用或 Web 应用的可靠性、检查某资源组内应用服务与 Functions 资源的可靠性、判断应用或应用服务计划是否区域冗余、为应用启用区域冗余、设置多区域故障转移、检查可靠性状况、查找单点故障、启用高可用、检查灾难恢复就绪情况或提升应用韧性时，可激活本技能。范围说明：本技能目前仅覆盖 Azure Functions 与 Azure App Service；若用户询问 Azure Container Apps 的可靠性，应说明该支持已规划但尚不可用，仅对范围内的 App Service 与 Functions 资源继续处理。
【前提条件】 用户需通过 az login 登录 Azure；评估需要目标订阅/资源组的 Reader 权限，配置更改需要 Contributor 权限；需安装 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，需先安装 resource-graph 扩展。
【评估工作流】 阶段 1：发现资源。确认范围（资源组、订阅或应用名称），查询范围内的全部资源，按服务类型分类。若发现 Container Apps，仅记录但不深入。所有查询必须限定在用户指定的资源组或订阅内。
阶段 2：评估可靠性。采用两步评估：先做平台级发现，再做逐服务深挖。平台检查涵盖区域冗余发现、存储冗余（跨服务）、多区域与全局负载均衡器、Front Door / Traffic Manager / App Insights 探测；随后针对发现的每个计算资源加载对应服务参考。本版本仅提供 Azure Functions 与 App Service 的逐服务参考：Azure Functions（microsoft.web/serverfarms 且 kind 含 functionapp）、Azure App Service（不含 functionapp 的 microsoft.web/sites 与 serverfarms）。Container Apps 标记为尚未发布。对不支持的资源，在发现摘要中列出并标记为未评估（已规划），跳过其修复步骤，不得编造 CLI 命令或 IaC 补丁。
阶段 3：生成可靠性检查清单。以特性为维度呈现，每行一个可靠性特性（计算区域冗余、区域冗余存储、健康探测、多区域故障转移），配一个状态指示符及相关资源。状态规则：🟢 ON 表示范围内所有相关资源均已完全启用；🟡 PARTIAL 表示部分资源具备或配置不完整；🔴 OFF 表示所有相关资源均缺失。存储行在相关时用当前 SKU 替代 OFF（如 🔴 LRS、🔴 GRS、🟢 ZRS、🟢 GZRS）；IaC 未设置 SKU 时标为 🔴 GRS（ARM/AVM 默认）并注明。不设数值评分、等级或点数。评估结束时提出一个是/否问题以启动分阶段修复流程；若应用已具备全部核心可靠性特性，则跳过修复问题直接进入多区域跟进，且未经明确同意不得开始任何多区域工作。
【配置工作流】 执行任何更改前必须先与用户确认，展示将发生的变化、成本影响及破坏性操作。 步骤 1：呈现修复计划并选择路径。列出每个可修复发现及具体操作，标注成本或破坏性变更，提供两条路径：A) 立即修复——对活动资源运行 az CLI 命令（一次性、立即）；B) 修补 IaC——更新 Bicep/Terraform 文件使更改在部署后保留（若使用 azd 或 Terraform 建议选 B）。 路径 A：对活动资源运行 az CLI 修复，先做快速改动，再做慢速存储迁移前询问。执行顺序：先计算区域冗余（应用计划上的就地属性更新），再健康探测（仅 Premium/Dedicated 为就地；FC1/Consumption 需按 configure-health-probes.md 的同意门槛处理），验证计算更改成功后再继续。随后停止并询问是否升级存储。存储迁移回答 yes 时运行 az storage account update --sku Standard_ZRS（或迁移启动），轮询 az storage account show --query sku.name 直至报告 Standard_ZRS；no/later 则保持现状并记入再评估。多区域不会自动运行。注意：若用户之后使用 azd up 或 terraform apply，仅 CLI 的更改可能被 IaC 定义覆盖，建议同时修补 IaC。 路径 B：修补 IaC。步骤 1 检测 IaC 类型（查找 infra/ 目录或根目录 .bicep、.tf；两者都存在时询问用户；无 IaC 则回退路径 A）。步骤 2 按风险分类：应用计划区域冗余为安全补丁（下次部署就地更新）；存储 LRS→ZRS 需预迁移（必须先完成活动存储迁移，不得与安全补丁捆绑，采用两次部署流程）；健康检查路径 Basic/Standard/Premium / Dedicated 为安全补丁（就地更新但导致应用重启）；FC1/Consumption 的健康检查路径仅限代码且需先询问（不支持 healthCheckPath，需在应用代码中新增 HTTP 触发 /api/health 函数，未经明确同意不得改动源代码，不修补 IaC）。步骤 3 分两次部署应用补丁（先快速改动）：部署 1 仅修补安全项，技能自行运行部署（检测部署工具并确认一次：AZD 项目运行 azd up；纯 Bicep 运行 az deployment group create；Terraform 运行 terraform plan -out tfplan 后 apply），失败则停止；部署 1 成功后停止并询问存储升级。步骤 4 存储迁移（仅当用户在步骤 3 回答 yes）：技能自行运行迁移命令并轮询直至完成，长迁移可向用户提示检查点。