2. Azure迁移方法论与评估框架
迁移项目失败，很少是因为“不会用 Azure”，而是因为缺少一套从业务目标到技术落地的共同语言。Azure 官方提供了两套互补的方法论：Cloud Adoption Framework（CAF，云采用框架）解决“如何组织一次云迁移与现代化改造”，Well-Architected Framework（WAF，架构良好框架）解决“迁移后的架构是否可靠、安全、经济”。本节把两者串成一条可执行的评估链路，并给出就绪度检查与现代化改造决策树。
一、CAF：迁移的“项目管理骨架”
CAF 把云采用划分为若干阶段，迁移场景下最常用的是四个：策略（Strategy）→ 计划（Plan）→ 就绪（Ready）→ 采用（Adopt），其中“采用”又分为迁移（Migrate）与创新/现代化（Innovate）。它的价值在于把技术动作挂到业务动机上：
- 策略：明确迁移动机（降本、退出数据中心、合规、加速创新）与预期业务成果，形成可度量的成功指标，例如“12 个月内关闭 A 机房，年度基础设施成本下降 30%”。
- 计划：建立云采用计划，核心产物是数字资产清单（Digital Estate）与合理化分析（Rationalization），即对每个应用/服务器给出迁移策略（常称 6R）。
- 就绪：搭建 Azure 登陆区（Landing Zone），包括管理组、订阅、网络拓扑、身份、策略（Azure Policy）、日志与安全基线。没有登陆区就迁移，后期返工成本极高。
- 采用：按批次迁移，并通过治理（Govern）与运营管理（Manage）持续收敛。
需要强调：CAF 不是瀑布流程，而是可迭代的循环。一个常见做法是先用 4～6 周完成“策略+计划”的最小闭环，同时并行搭建登陆区，再启动第一批试点迁移。
二、WAF：迁移后的“架构质量标尺”
WAF 提供五个支柱，用于评审目标架构与迁移方案：
| 支柱 | 迁移场景关注点 | 典型检查项 |
|---|---|---|
| 可靠性 Reliability | 可用区/区域冗余、备份与恢复 | RTO/RPO 是否明确；是否跨可用区部署；恢复演练是否做过 |
| 安全性 Security | 身份、网络隔离、密钥与数据保护 | 是否用托管标识替代密钥；是否启用 Defender for Cloud；私有终结点覆盖情况 |
| 成本优化 Cost | 规格合理性、预留与混合权益 | 是否有闲置资源；是否启用 Azure Hybrid Benefit；是否评估预留实例 |
| 卓越运营 Operational Excellence | IaC、CI/CD、可观测性 | 是否用 Bicep/Terraform 管理；是否有集中日志与告警 |
| 性能效率 Performance | SKU 选型、缓存、数据层吞吐 | 是否做过容量基线；存储层级与数据库层是否匹配负载 |
实践中，WAF 评审应作为迁移批次上线前的“质量门”，而不是事后补文档。
三、迁移评估维度：把“能不能迁”量化
评估不是简单看 CPU/内存，而是多维度打分。建议至少覆盖六个维度，并给出 1～5 分评级：
- 业务关键性：停机窗口、SLA、影响用户范围。
- 技术依赖：操作系统版本、数据库引擎、中间件、硬编码 IP、本地文件共享。
- 性能基线：峰值 CPU、内存、IOPS、网络吞吐，用于选型。
- 安全与合规：数据分级、加密要求、行业监管。
- 集成复杂度：与 AD、ERP、第三方系统的接口数量与协议。
- 现代化潜力：是否适合容器化、PaaS 化或重构。
例如某内部报表系统：业务关键性 2 分（可接受周末停机）、技术依赖 4 分（Windows Server 2012 + SQL Server 2014）、性能基线中等、合规低、集成少、现代化潜力高。综合判断可先“重新托管”上云，再在第二阶段改造为 Azure SQL 托管实例与容器化应用。
四、就绪度检查与现代化改造决策树
就绪度检查回答“现在能不能开始迁”。建议在启动第一批迁移前完成以下核对：
- 登陆区是否就绪：管理组、订阅配额、网络（Hub-Spoke 或 Virtual WAN）、DNS、防火墙出口。
- 身份是否就绪：Microsoft Entra ID 与本地 AD 的同步、条件访问策略、特权身份管理。
- 治理是否就绪：命名规范、标签策略、Azure Policy 基线、成本管理范围。
- 运营是否就绪：Log Analytics 工作区、备份保管库、监控告警、值班流程。
- 人员是否就绪：云平台团队、应用团队、安全团队的角色与职责（RACI）。
当就绪度达标后，对每个工作负载使用下面的决策树判断迁移策略。决策树的核心逻辑是：先问“是否还需要保留”，再问“是否值得改造”，最后才问“怎么迁”。
决策树的使用要点：先做减法（退役、替换），再做加法（重构、重建），最后才考虑平移。很多团队一上来就选“重新托管”，结果把技术债原封不动搬进云里，后续优化成本更高。对于生命周期短、即将被替换的系统，重新托管是合理的；对于核心且长期演进的系统，应优先评估平台化或重构。
五、把框架落到一次迁移批次上
假设要迁移 40 台虚拟机与 12 个应用，可按以下节奏组织：
- 用 2 周完成数字资产清单与 6R 初判，输出每个工作负载的评估分与目标策略。
- 用 3～4 周搭建登陆区，完成网络、身份、策略、日志基线，并通过就绪度检查表逐项确认。
- 选择 2～3 个低风险应用做试点，验证迁移流水线、回滚方案与监控告警。
- 按业务域分批迁移，每批上线前做一次 WAF 五支柱快速评审。
- 迁移后 30 天内完成成本与性能复盘，识别可平台化或可退役的遗留资源。
总结来看，CAF 提供“从策略到运营”的组织方法，WAF 提供“架构是否合格”的评审标尺，评估维度与就绪度检查把两者变成可打分的输入，决策树则把输入转化为每个工作负载的迁移策略。四者组合，才能让迁移从“搬机器”升级为“有依据的现代化改造”。