Azure Validate

Azure Validate 是什么

Azure Validate 是 Microsoft 官方 Azure Skills 中的部署前验证环节。它不是简单运行一次语法检查，而是根据部署计划检查应用配置、基础设施代码、订阅上下文、资源提供程序、配额、RBAC 与托管身份权限，并使用 what-if 等只读能力预测资源变化。验证结果会回写到统一部署计划，作为是否允许进入真正部署阶段的证据。

适用场景与选择边界

适合已经通过 Azure Prepare 生成或整理好 azure.yaml、Bicep、Terraform 和部署计划的项目，也适合排查“部署前看起来正常、执行时才因权限或先决条件失败”的问题。它不负责创建新应用，也不负责真正执行 azd up、terraform apply 或资源部署；缺少准备产物时应先回到 Azure Prepare。

核心能力与工作机制

Skill 按项目所选配方加载相应检查，对 Azure Functions、Container Apps 等场景核对配置与基础设施，还会检查角色分配、托管身份、资源命名和订阅条件。关键原则是所有检查必须通过，不能把警告或失败当成可忽略状态；涉及真实云资源的检查优先保持只读，破坏性修复需取得明确授权。

实际工作流

先确认工作区存在 .azure/deployment-plan.md，且计划已经完成准备阶段；再读取选定订阅、区域、基础设施类型和服务清单。随后执行配置验证、IaC 验证、RBAC 与身份核查、what-if 或对应预检，记录每项证据。全部通过后把计划状态改为 Validated 并填写 Validation Proof，才允许交给 Azure Deploy。

输入、输出与交付物

输入包括部署计划、azure.yaml、Bicep 或 Terraform 文件、应用配置以及经过确认的 Azure 订阅和区域。输出不是部署后的资源，而是一份带检查结论、失败原因和验证证据的更新版部署计划；若有错误，还应给出可定位的文件或权限问题，方便回到准备阶段修正。

依赖、账号与权限

需要能够读取项目文件，并按检查范围使用 Azure CLI、azd、Terraform 或 Azure MCP 等工具。涉及云端验证时必须已登录并选择正确租户、订阅与环境；只读预检也可能需要读取资源、角色和配额的权限。不得把凭据、连接字符串或令牌写入部署计划与日志。

限制与安全风险

最大的风险是把错误订阅或错误环境的“通过”误当成目标环境结果，或在验证阶段擅自执行会改变资源的命令。what-if 也不是百分之百的运行时保证，外部策略、配额和权限可能随后变化。因此每条证据要带上下文，失败时停止部署，敏感修复与破坏性动作必须交由用户确认。

适合谁使用

适合使用 Azure Developer CLI、Bicep 或 Terraform 的开发者、平台工程师和 DevOps 团队，尤其适合希望把上线门禁标准化的项目。对还没有部署方案的初学者，它应与 Azure Prepare 配合；对只想查看某个线上故障的用户，则 Azure Diagnostics 更直接。

上手与验收建议

先从非生产环境执行一遍完整验证，确认计划里的订阅、区域、配方和服务与实际目标一致。验收时不只看“通过”字样，还要检查 Validation Proof 是否记录命令、目标环境与结果；任何失败或缺失都不进入部署。正式发布前重新验证，避免计划通过后代码或 IaC 又发生变化。

来源、版本与许可

依据 microsoft/azure-skills 固定提交中的完整 Azure Validate Skill、skills.sh 市场详情和仓库 MIT 许可证整理。官方来源未提供中文展示名，因此保留 Azure Validate。

常见问题

1. 它应在 Azure 部署流程的哪个阶段使用？

应在 Azure Prepare 完成项目准备之后、Azure Deploy 执行真实部署之前使用。它读取准备阶段留下的部署计划和基础设施文件，全部验证通过并写入证据后，才把状态交给部署环节。

2. 缺少部署计划时能直接验证吗？

不能把缺失计划当成普通警告。来源把 .azure/deployment-plan.md 视为前置条件；没有这份文件就无法确认配方、目标服务和环境，应停止并先运行准备流程，而不是猜测项目意图。

3. 会检查哪些基础设施内容？

会根据计划检查 Bicep 或 Terraform、azure.yaml、服务配置和 Azure 先决条件，并核对 RBAC 角色分配与托管身份权限。具体检查随所选服务和部署配方变化，不是固定的一张通用清单。

4. what-if 通过是否保证部署一定成功？

不保证。what-if 能预览资源层面的变化，但运行时策略、区域容量、配额、临时服务状态和部署后依赖仍可能失败，所以它是强门禁证据，不是对所有外部条件的永久承诺。

5. 验证发现错误后会自动部署修复吗？

不会。验证阶段应报告并定位失败，再回到准备或配置环节修正；任何可能改变云资源的动作，特别是删除、替换或权限调整，都不能借“验证”名义绕过用户确认。

6. 如何判断项目已可以交给 Azure Deploy？

所有要求的检查必须通过，部署计划状态必须改为 Validated，并且 Validation Proof 已记录可复核的结果。只有口头说明“看起来没问题”或只通过部分检查，都不满足部署前置条件。

7. 能用它排查已经上线的生产故障吗？

它主要解决部署前就绪性，不是生产事故诊断入口。线上高 CPU、冷启动、CrashLoop、连接失败或资源健康问题，应使用 Azure Diagnostics，再根据诊断证据决定是否修改部署。

8. 如何避免验证了错误的 Azure 环境？

开始前应明确租户、订阅、区域和 azd 环境，并把这些上下文写进验证证据。若存在多个订阅或计划与当前登录状态不一致，就应停下确认，不能默认选择第一个可用目标。