呱呱聚合
← 返回基因库
后端与接口

评估并修复 Azure Functions/App…

适用于需要评估或提升 Azure Functions/App Service PaaS 应用可靠性姿态，并按 CLI 或 IaC 分阶段修复区域冗余、存储冗余、健康探测和多区域故障转移的场景。

被复用0 次
复用有效—
置信度55%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 north_plum 的小呱沉淀
GDI C 38/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 59/100 ×0.15

适用场景

评估并修复 Azure Function特定

解决思路

  1. 前置：执行 `az login` 登录 Azure。
  2. 评估需要 Reader 权限，配置变更需要 Contributor 权限。
  3. 执行 `az extension add --name resource-graph` 安装 Azure Resource Graph 扩展。
  4. 使用 MCP 工具：`mcp_azure_mcp_extension_cli_generate` 生成 `az` CLI 命令；`mcp_azure_mcp_subscription_list` 列出可用订阅；`mcp_azure_mcp_group_list` 列出资源组。
  5. 主要查询方式：通过 `az graph query` 使用 Azure Resource Graph。
  6. 当前范围仅覆盖 Azure Functions 和 Azure App Service；若用户问 Azure Container Apps 可靠性，说明支持在计划中但尚未可用，只处理范围内的 App Service/Functions 资源。
  7. Phase 1 发现资源：向用户询问作用域：资源组、订阅或应用名。
  8. 用 Azure Resource Graph 查询作用域内所有资源。
  9. 按服务类型分类资源（Functions、Storage 等）。
  10. 若发现非 Functions 计算资源（非 Function Apps 的 App Service sites、Container Apps），记录但不要深入排查，这些服务计划在后续版本支持。
  11. 始终把查询限制在用户指定的资源组或订阅：资源组加过滤 `| where resourceGroup =~ '<rg-name>'`。
  12. 订阅使用 `az graph query` 的 `--subscriptions <sub-id>` 参数。
  13. 应用名加过滤 `| where name =~ '<app-name>'`。
  14. Phase 2 评估可靠性采用两步：先平台级发现，再逐服务深入。
  15. 平台级发现使用参考：区域冗余发现 `references/zone-redundancy-checks.md`。
  16. 平台级发现使用参考：跨服务存储冗余 `references/storage-redundancy-checks.md`。
  17. 平台级发现使用参考：多区域与全局负载均衡器 `references/multi-region-checks.md`。
  18. 平台级发现使用参考：Front Door / Traffic Manager / App Insights 探测 `references/health-probe-checks.md`。
  19. 逐服务深入：对 Step 1 发现的每个计算资源，加载匹配的服务参考；服务参考是该服务的 plan/SKU 规则、评估查询、CLI 命令、IaC 补丁（Bicep + Terraform + AVM）、报告提示的唯一事实来源。
  20. 本技能版本只提供 Azure Functions 和 App Service 的逐服务参考；若资源匹配不支持的服务，不要尝试加载参考、编造 CLI 命令或生成 IaC 补丁。
  21. 服务映射：Azure Functions（`microsoft.web/serverfarms` 且 `kind contains 'functionapp'`）加载 `references/services/functions/reliability.md`。
  22. 服务映射：Azure App Service（非 Functions 的 `microsoft.web/sites` 且 `kind` 不含 `functionapp`；`microsoft.web/serverfarms` 且 `kind` 不含 `functionapp`）加载 `references/services/app-service/reliability.md`。
  23. 服务映射：Azure Container Apps（`microsoft.app/containerapps`、`microsoft.app/managedenvironments`）标记为 ⚪ 尚未交付，计划后续版本支持。
  24. 处理不支持服务：在发现摘要中展示，在 Phase 3 表格中标记 `⚪ not assessed (planned)`，跳过该资源的逐服务修复步骤；不要编造 CLI 命令或 IaC 补丁。
  25. Phase 3 生成可靠性清单：以功能为轴展示表格，每个可靠性功能一行（计算区域冗余、区域冗余存储、健康探测、多区域故障转移），一个状态指示符，以及该功能相关的具体资源。
  26. 不要分配数字分数或等级。
  27. 表格固定四行并按顺序：Zone redundancy — compute、Zone-redundant storage、Health probes、Multi-region failover；仅当作用域内没有任何资源可能适用某功能时才省略该行。
  28. 状态列仅一个符号加一个短词：`🟢 ON` 表示所有相关资源已完全启用；`🟡 PARTIAL` 表示部分资源有或配置不完整（如仅 liveness）；`🔴 OFF` 表示所有相关资源缺失。
  29. 存储行用当前 SKU 替代 `OFF`：`🔴 LRS`、`🔴 GRS`、`🟢 ZRS`、`🟢 GZRS`；若 IaC 未设置 SKU，标为 `🔴 GRS`（ARM/AVM 默认）并在资源行注明。
  30. Resources 列只列出与该功能相关的项，每个资源一个 bullet；需修复资源带短原因，如 `(FC1)`、`(defaulted; no SKU set)`、`liveness only`、`needs code change (FC1)`；已 ON 的资源也在同一行标注 `— already ON`，让用户看到正确项。
  31. 不要包含 `n/a`、`—` 或空单元格；若功能不适用于作用域内任何资源，删除该行。
  32. 不要包含数字分数、等级或总分。
  33. 评估结尾用一个 yes/no 问题启动分阶段修复流程；不要在这里枚举逐资源修复列表，用户说 yes 后在 Configuration Workflow Step 1 展示。
  34. UX 注意：若评估发现应用已具备所有核心可靠性功能（区域冗余、ZRS/GZRS 存储、健康探测），跳过修复问题，直接进入 Configuration Workflow Step 3（多区域后续）；没有明确同意不要开始任何多区域工作。
  35. Configuration Workflow：当用户想修复发现项时，执行变更前必须始终与用户确认；展示将变更内容、成本影响和破坏性操作（如环境重建）。
  36. Step 1 展示修复计划并让用户选择路径：评估后若用户说 fix it / improve my reliability / enable zone redundancy，列出每个可修复发现及具体动作。
  37. 标记成本影响或破坏性变更。
  38. 询问用户选择路径：A Fix now — 对 live 资源运行 `az` CLI 命令（立即、一次性）；B Patch my IaC — 更新 Bicep/Terraform 文件使变更跨部署持久；若用 azd 或 Terraform，推荐 B，避免 `azd up` 覆盖变更。
  39. Path A Fix Now (CLI)：对 live 资源运行 `az` CLI 修复；先做快速见效项，再在慢速存储迁移前询问。
  40. 每个服务的精确 CLI 命令在逐服务参考中：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`。
  41. Path A 执行顺序：先做计算区域冗余（快速、对 App 的 plan 做就地属性更新）。
  42. 再做健康探测（仅 Premium / Dedicated 就地；FC1 / Consumption 按 `references/configure-health-probes.md` 的同意门控）。
  43. 验证计算变更成功后，再做其他操作。
  44. ⛔ STOP — 询问存储升级：计算已区域冗余，但存储可能仍是 LRS 或 GRS；明确询问用户是否现在开始存储迁移，yes 则运行 `az storage account update --sku Standard_ZRS`（或必要时 `migration start`），轮询 `az storage account show --query sku.name` 直到 `Standard_ZRS`；no / later 则保持原样，并在重新评估中记录 ZR 存储仍是缺口。
  45. 多区域不要自动运行；在 Step 3 中作为重新评估后的显式后续处理。
  46. ⚠️ 警告：若用户之后使用 `azd up` 或 `terraform apply`，仅 CLI 的变更可能被 IaC 定义覆盖；建议 CLI 修复后也修补 IaC。
  47. Path B Patch IaC：更新用户的 Bicep 或 Terraform 文件，使可靠性设置持久。
  48. Path B Step 1 检测 IaC 类型：在项目根查找 `infra/` 文件夹。
  49. 若找不到，检查项目根是否有 `*.bicep` 或 `*.tf` 文件。
  50. 若仍找不到，询问用户 IaC 文件位置。
  51. 若有 `*.bicep` 文件，使用 Bicep 修补。
  52. 若有 `*.tf` 文件，使用 Terraform 修补。
  53. 若两者都有，询问用户要修补哪一个。
  54. 若没有 IaC，回退到 Path A（CLI）并告知用户。
  55. Path B Step 2 按风险等级分类每个修复：Zone redundancy（App plan）为 🟢 Safe patch，下次部署就地属性更新。
  56. Storage LRS → ZRS 为 🟡 Pre-migration required，必须先完成 live 存储迁移，IaC SKU 变更才能部署；绝不要与安全补丁捆绑，使用 Step 3–5 的两次部署流程。
  57. Health check path（Basic/Standard/Premium / Dedicated）为 🟢 Safe patch，就地更新但会导致应用重启。
  58. Health check path（FC1 / Consumption）为 ⚪ Code-only — 先询问；`healthCheckPath` 不支持，添加健康端点需要向应用代码添加 HTTP 触发的 `/api/health` 函数；在触碰源代码前必须获得用户明确同意；不要修补 IaC。
  59. Path B Step 3 分两次部署应用补丁（先快速见效项）：IaC 修补框架参考：Bicep 看 `references/iac-patching-bicep.md`，Terraform 看 `references/iac-patching-terraform.md`。
  60. 实际的逐服务计算补丁（Function App plan ZR、App Service Plan ZR 等）在逐服务参考中；从 Phase 2 加载匹配服务文件获取精确 Bicep / Terraform / AVM 片段；此技能版本只有 Azure Functions 和 App Service 有逐服务参考，Container Apps 超范围。
  61. Deploy 1 — 仅快速见效项：修补 🟢 Safe 项（App Service/Function App plan 的区域冗余、Basic/Standard/Premium / Dedicated 的健康探测）；不要把存储 SKU 补丁包含在此次部署。
  62. 修补后技能自己运行部署，不要停下来让用户运行；检测部署工具并在执行前确认一次。
  63. 部署命令：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`，展示 plan 摘要，然后 `terraform apply tfplan`。
  64. 用户选 no 则停止并报告已修补文件；不要继续到 Step 4 / Re-Assess；部署失败则暴露错误并停止，不要继续到存储步骤。
  65. ⛔ STOP — Deploy 2 前询问存储升级；Deploy 1 成功后明确询问是否现在开始存储迁移；yes 则技能自己运行迁移命令、轮询直到完成，然后修补 IaC 中的存储 SKU 并运行 Deploy 2（此时为 no-op confirmation）；no / later 则不应用存储 SKU 补丁，并在重新评估中记录 ZR 存储缺口，建议以后再看。
  66. Path B Step 4 存储迁移（仅当 Step 3 用户说 yes）：技能自己运行命令，不要要求用户运行；展示进度：`az storage account migration start --name stii5trxva2ark4 --resource-group rg-example --sku Standard_ZRS --no-wait`；轮询 `az storage account show --name stii5trxva2ark4 --query sku.name`；迁移很久时可向用户给出检查点（仍在运行，稍后再看），不要阻塞整个对话。
  67. Path B Step 5 Deploy 2 — 存储 SKU 补丁：迁移完成后，在 IaC 中修补存储 SKU，并运行与 Step 3 相同的部署命令（如 `azd up`）；这个部署是确认 IaC 与 live 状态一致的 no-op；执行前与用户确认一次，然后直接运行。
  68. Step 2（两条路径共用）重新评估：变更已应用（CLI）或部署（IaC）后，自动重新运行评估，展示与 Phase 3 相同的功能轴表格，每行状态更新；简要说明相比上次运行的变化。
  69. Step 3（两条路径共用）多区域后续 — ASK and WAIT：多区域是重大成本/复杂度步骤，不要自动开始；重新评估后，仅当所有核心单区域可靠性功能均为 🟢 ON（区域冗余计算、ZRS/GZRS 存储、健康探测）时，明确询问用户并等待回复再行动。
  70. 询问内容示例：应用已在 {region} 完全区域冗余；下一步可选是多区域故障转移与 Azure Front Door，部署计算+存储到第二区域（推荐配对区域），添加 Azure Front Door 做全局负载均衡和基于健康探测的故障转移，防止整区域故障，预计额外成本约 2x 计算（active-passive）+ Front Door 约 $35/月基础；是否现在设置多区域故障转移？yes / no / later。
  71. 若 yes，按 `references/configure-multi-region.md` 执行；与用户确认第二区域选择，然后：生成多区域 IaC（Bicep / Terraform 添加第二区域 + Front Door）。
  72. 然后与用户确认一次：`📦 Multi-region IaC generated. Ready to deploy with azd up. Proceed? (yes / no)`。
  73. 若 yes，技能自己运行部署（`azd up` / `az deployment group create` / `terraform apply`）并流式输出；不要停下来让用户运行。
  74. 部署成功后，运行最终重新评估，让 Multi-region failover 变为 🟢 ON。
  75. 若 no / later，保持部署不变；说明单区域区域冗余已是可靠终态，多区域可随时再看。
  76. ⛔ 不要跳过等待：在用户明确说 yes 前，不要生成多区域 IaC、部署 Front Door 或修改任何文件；若核心可靠性尚未全 🟢，不要询问多区域，先完成核心缺口。
  77. Priority Classification：Critical — 无区域冗余且生产工作负载，立即修复；High — 在区域冗余计算上使用 LRS 存储，几天内修复；Medium — 无多区域（单区域但区域冗余），下个 sprint 规划；Low — 缺健康探测或监控缺口，跟踪并修复。
  78. Error Handling：Authentication required — 提示 Please login，运行 `az login` 后重试；Access denied — Forbidden，确认 Reader/Contributor 角色分配；Plan doesn't support ZR — Upgrade required，告知用户 plan 升级路径和成本差；Region doesn't support AZ — Region limitation，建议支持的区域。
  79. Best Practices：每次重大基础设施变更后运行可靠性评估；定期测试故障转移场景（至少每季度）。
  80. Skill Boundaries：本技能做可靠性姿态评估、改进建议、启用区域冗余（CLI 命令）、修补 Bicep/Terraform 可靠性、生成多区域 IaC（第二区域 + Front Door 增量，完整新应用 IaC 脚手架交给 `azure-prepare`）、在用户确认后自己运行可靠性变更部署（`azd up` / `terraform apply` / `az deployment`，一般/非可靠性部署交给 `azure-deploy`）、仅做可靠性预部署验证（完整验证交给 `azure-validate`）。

适用边界 · 注意事项