azure-upgrade

概览

什么是 azure-upgrade？

azure-upgrade 是面向现有 Azure 工作负载的引导式升级技能。它聚焦于就地或近似就地的更改，例如升级 plan、tier 和 SKU，或在保持在 Azure 内的前提下，在相关 Azure 服务之间迁移。

典型使用场景包括：

• 将 Azure Functions 从 Consumption 升级到 Flex Consumption
• 将 function app 迁移到不同的 hosting plan 或 service tier
• 更改现有 Azure 服务的 SKU
• 将后端工作负载从 App Service 迁移到 Azure Container Apps

该技能将结构化流程（Identify → Assess → Pre-migrate → Upgrade → Validate）与安全规则和最佳实践结合，让你在演进线上应用时无需凭经验“猜”。

azure-upgrade 适合谁使用？

azure-upgrade 主要面向：

• 负责 Azure 后端服务的开发者和 DevOps 工程师
• 负责 plan、tier 或 SKU 调整的平台和云运维团队
• 正在标准化采用 Flex Consumption，或从 App Service 现代化迁移到 Container Apps 的团队

如果你希望在不破坏生产环境的前提下调整 plan 或迁移到更新的 Azure 产品，这个技能能为你提供可重复、有文档可循的路径。

azure-upgrade 解决什么问题？

azure-upgrade 可以帮助你：

• 在修改任何线上资源之前，评估升级就绪度
• 基于当前环境 规划目标 plan/tier/SKU
• 按照预定义规则 自动化重复性的升级步骤
• 通过仓库中的 upgrade-status.md 文件 跟踪进度
• 借助严格的破坏性操作规则和用户确认 避免不安全操作

该技能专注于 Azure 内部 的更改。它 不 处理跨云迁移；如需跨云迁移，应使用 azure-cloud-migrate 等专门的迁移技能。

什么时候适合使用 azure-upgrade？

在以下场景中使用 azure-upgrade：

• 将正在运行的 Azure Functions 应用升级到 Flex Consumption
• 希望调整现有工作负载的托管 tier 或 SKU
• 正在将应用从 App Service 迁移到 Azure Container Apps
• 需要一个可追踪、分阶段的流程来做 Azure 运维升级

在以下情况中，它可能 不太适合：

• 将工作负载 迁出 Azure（跨云迁移）
• 搭建一个 全新 应用且还没有现有资源
• 只需要 CI/CD 流水线自动化（更适合使用 azure-deploy 等技能）

如果你的首要关注点是 Azure 升级过程中的安全发布、回滚选项和配置一致性，azure-upgrade 就是为这类工作设计的。

使用方法

1. 安装与初始化

要从 microsoft/azure-skills 仓库添加 azure-upgrade 技能，在你的 agent 环境中使用 skills CLI：

npx skills add https://github.com/microsoft/azure-skills --skill azure-upgrade

完成安装后，先了解几个定义该技能行为的关键文件：

• SKILL.md – 高层描述、触发条件和规则
• references/global-rules.md – 安全规则与最佳实践
• references/workflow-details.md – 详细流程阶段及状态跟踪说明

同时，确保你的 agent 已配置访问相关 Azure MCP 工具，例如 mcp_azure_mcp_get_bestpractices 和 mcp_azure_mcp_documentation，这些工具在技能规则中会被引用。

2. 理解升级工作流

azure-upgrade 遵循一套预定义顺序：

1. Identify – 明确源资源（例如当前 Functions plan）以及目标 plan、tier 或 SKU。
2. Assess – 生成关于升级就绪度和兼容性的评估。
3. Pre-migrate – 收集应用设置、配置、依赖项以及连通性信息。
4. Upgrade – 执行自动化步骤，应用新的 plan/tier/SKU，或创建新的目标资源。
5. Validate – 校验升级后的应用是否可用并准备好接收流量。

技能内置规则要求按顺序执行各阶段，明确不建议跳过 Assess 或 Pre-migrate 步骤，从而帮助你在生产环境中保持升级操作的安全性和可预测性。

3. 使用 upgrade-status.md 跟踪进度

该工作流使用一个简单的、仓库本地的跟踪文件，让升级过程可审计、可在团队中共享。

在工作区根目录创建 upgrade-status.md，其结构参见 references/workflow-details.md。至少应包含：

• 源应用名称及当前 plan
• 目标 plan 或服务
• Resource group 和 region
• 开始日期
• 工作流阶段清单（Identify、Assess、Pre-migrate、Upgrade、Validate）
• 关于问题、决策和错误的备注

随着 agent 完成各阶段，持续更新该文件。如果某一阶段失败，记录错误并在继续之前完成修复。

4. 遵守全局安全规则

references/global-rules.md 中定义了 azure-upgrade 的硬性防护规则，包括：

• Destructive Action Policy（破坏性操作策略） – 未经通过 ask_user 的明确确认，agent 不得删除应用、服务、resource group，也不得修改 DNS/custom domain。
• 用户确认检查 – 选择订阅或 region、创建新资源、修改网络限制等操作都必须经过明确的用户审批。
• 最佳实践 – 技能优先推荐使用 managed identity、现代运行时，并在新资源完全验证之前保持原始资源继续运行。

在自定义或扩展工作流时，请保持这些规则不变，以确保自动化在生产环境中仍然安全可控。

5. 运行常见升级场景

安装完成后，你可以通过自然语言意图与 azure-upgrade 交互，这些意图会匹配 SKILL.md 中定义的触发条件。示例请求包括：

• "Assess if my function app is ready to move from Consumption to Flex Consumption."
• "Automate the upgrade of my Functions plan to Flex Consumption in the same resource group."
• "Help me migrate this App Service API to Azure Container Apps and validate it before cutover."
• "Change the hosting plan for this function app and document each step in upgrade-status.md."

技能随后会：

1. 将你的意图解析为一个升级场景；
2. 加载相关场景说明和全局规则；
3. 使用 Azure MCP 工具查阅文档和最佳实践；
4. 提出或生成升级步骤，并在任何有影响的更改前向你确认。

6. 与相关技能协同

在完成升级和验证后，azure-upgrade 可以顺畅地交接给其他 Azure 相关技能：

• azure-validate – 用于更深入的升级后验证和测试。
• azure-deploy – 用于围绕新升级资源搭建或优化 CI/CD 流水线。

这样一来，azure-upgrade 专注于变更管理工作流，同时仍能融入更大的自动化体系。

常见问题（FAQ）

azure-upgrade 适合生产环境使用吗？

适合。azure-upgrade 在设计时就考虑了生产使用场景。全局规则明确要求：

• 按阶段执行（不得跳过评估环节）
• 对破坏性或不可逆操作进行确认
• 在升级版本完全验证之前保持原始应用/服务继续运行

在按预期使用并结合你自身的变更管理流程时，它可以支持在生产环境中安全地执行升级操作。

azure-upgrade 会处理跨云迁移吗？

不会。azure-upgrade 专注于 Azure 内部 的升级，例如 plan、tier 和 SKU 的调整，或在 App Service 与 Container Apps 等 Azure 服务之间迁移。如果要在不同云之间迁移工作负载，应使用 azure-cloud-migrate 等专门的迁移技能。

我可以用 azure-upgrade 升级哪些 Azure 服务？

该技能主要面向已有工作负载，例如：

• Azure Functions 应用（如 Consumption → Flex Consumption）
• 运行在 Azure App Service 上的应用
• 计划迁移到 Azure Container Apps 的工作负载

由于底层规则聚焦于 plan、tier 和 SKU，当你需要现代化托管方式或为后端服务调整容量时，它尤其有用。

azure-upgrade 如何记录已经执行的操作？

该技能依赖仓库中的 upgrade-status.md 文件（详见 references/workflow-details.md），该文件会记录：

• 关键资源信息
• 各阶段完成状态
• 错误及修复记录

这种轻量机制让升级过程便于审计和复盘，即便有多个团队成员或多个 agent 参与也不例外。

azure-upgrade 会删除我的原始资源吗？

不会在未经明确同意的情况下删除。references/global-rules.md 中定义了严格的 Destructive Action Policy：

• 删除应用、服务或 resource group
• 停止或禁用原始服务
• 修改 DNS 或自定义域绑定

上述操作都需要通过 ask_user 获取明确确认。你完全掌控在成功升级后何时（以及是否）下线原始资源。

我可以自定义 azure-upgrade 的工作流吗？

你可以调整自己 如何使用 该工作流（例如将状态文件与内部流程集成，或与其他内部工具组合使用），但预定义的阶段和安全规则旨在保持升级的可预测性与安全性。如果你对 azure-upgrade 进行扩展或包装，请保留：

• Identify → Assess → Pre-migrate → Upgrade → Validate 这一顺序
• 关于破坏性操作与确认的全局规则

这样可以确保任何自定义自动化仍然受益于内置的安全防护。

azure-upgrade 如何与 CI/CD 流水线配合？

azure-upgrade 专注于对现有资源进行一次性或周期性的 运维变更。完成升级与验证后，它可以交接给 azure-deploy 来：

• 配置或更新 CI/CD 流水线
• 将部署流程与新的 plan、tier 或服务对齐

你可以先用 azure-upgrade 安全地调整基础设施特性，再使用聚焦于流水线的技能处理后续持续部署。

使用 azure-upgrade 前需要准备什么？

在运行 azure-upgrade 之前，请确保你已具备：

• 目标 Azure subscription 和 resource group 的访问权限
• 对目标 plan/tier/SKU 或目标服务（如 Container Apps）的明确规划
• 已在 agent 环境中配置好 azure-upgrade 技能和 Azure MCP 工具

提前准备好这些信息，可以帮助 agent 更快完成 Identify 和 Assess 阶段，减少来回确认。