云架构升级｜郭亿易

它解决什么问题

当业务系统在 Azure 上运行一段时间后，架构通常会面临两类压力：一是依赖的服务与运行时版本老化，比如虚拟机镜像陈旧、支撑库不再更新；二是流量增长后，原有单区域、小规格的部署方式开始出现性能瓶颈。这类升级的难点不在于"知道要升级"，而在于升级路径的拆解——先评估哪些组件可以原地更新、哪些需要先迁移存储、哪些依赖顺序一旦颠倒就会引发故障。

云架构升级｜郭亿易 面向这一场景，作为一个大模型技能（@user_8d36cde0/guoyiyi-v085-azure-upgrade），帮助工程师把"升级一个云架构"这件模糊的大任务，拆成可逐步执行的步骤。

核心能力与工作方式

• 现状梳理：输入现有架构的描述（资源清单、依赖关系、目标版本），技能先输出一份现状评估，标出哪些组件属于"可原地升级"，哪些属于"需要替换或迁移"。
• 方案拆解：基于评估结果，技能把升级拆成有序的任务列表，包括依赖处理的先后顺序与回滚考虑。
• 风险标注：对高风险步骤（如数据迁移、服务切换）给出提示，并说明应在哪个节点做验证。

典型的一次升级会话遵循以下步骤：

1. 提供当前架构与目标架构的说明；
2. 技能输出升级计划与任务拆解；
3. 针对每个任务节点，技能给出执行建议与验证方法；
4. 工程师执行后反馈结果，技能据此调整后续步骤。

适用边界

• 技能的输出是规划与建议，实际的资源操作仍需工程师通过 Azure Portal、az CLI 或基础设施即代码工具完成。
• 升级方案的有效性取决于输入架构描述的准确性。如果资源清单缺失关键依赖信息，拆解结果可能不完整。
• 涉及合规、安全审计的架构变更，需结合组织内部的审批流程单独评估，技能输出不能替代这类评审。
• 跨云或混合云的复杂迁移场景不在当前覆盖范围内，建议先将其拆解为云内升级任务再处理。