指南 · 云
企业云迁移手册：从评估到切换
迁移是一连串的决策，其中大部分在任何服务器迁移之前就已做出。本手册阐述迁移的各个阶段、区域与数据驻留的选择，以及让切换周末平稳度过的实践方法。
实战手册的作用
企业很少只迁移一次。通常先迁移第一个系统，从中积累经验，再迁移接下来的十个。实战手册记录这些经验，使第二批迁移比第一批更快、更安全：如何评估系统、着陆区是什么样子、如何执行切换，以及“完成”的标准是什么。本指南是我们与客户合作时的起点，应根据您的组织加以调整，而不是照搬。
贯穿始终的有两条原则。第一，迁移的是业务功能而不是服务器：关键问题在于应用及其数据如何持续为用户服务，而不是如何复制一台虚拟机。第二，在有意将某一步骤固定下来之前，每一步都应保持可逆。
各个阶段
每个阶段都以一项指导委员会能够认可的决策结束。各批次的阶段相互交叠：在迁移第一批的同时评估第二批。
- 1
评估
盘点每个应用及其负责人、依赖关系、数据分类、集成、许可和现有基础设施。按依赖关系和风险将应用分为若干批次。为每个应用确定处置方式：重新托管（原样迁移）、更换平台（小幅调整，例如改用托管数据库）、重构（容器化或重新设计架构）、替换（SaaS）或停用。产出：包含处置方式的分批计划，以及首份业务论证。
- 2
规划
针对第一批，为每个应用设计目标架构、从您的机房出发的网络路径、身份体系（人员使用 SSO，工作负载使用角色）、数据迁移方法和切换模式。在此阶段写好验收标准：需要哪些测试、哪些用户参与、哪些报表必须一致。产出：每个应用的设计方案和运行手册框架。
- 3
构建着陆区
在任何工作负载进入之前，以代码形式创建账户结构、网络、身份、日志、安全基线、备份和成本控制。这是后续所有批次的基础，值得一次性认真建好。产出：一个由 Terraform 管理并能通过自身合规检查的环境。
- 4
分批迁移
先迁移非生产环境，再迁移生产环境，每次一批。在切换模式需要时持续复制数据，在目标环境中使用真实数据运行验收测试，并在影响到其他人之前修复出现的问题。产出：已通过验收的目标环境，同时旧系统仍在运行。
- 5
切换
执行已演练过的运行手册：冻结变更、完成最终数据同步、切换流量、验证并发布通知。在约定期限内保持源环境原封不动，随时可以回滚。产出：生产系统在目标环境中运行，并已明确越过回滚决策点。
- 6
优化
系统稳定后，对出于安全考虑而超额配置的资源进行合理调整，将适合的工作负载迁移至托管服务或容器，对用量可预测的部分采用承诺用量定价，并下线源系统。产出：运行成本基线，以及反馈到迁移手册中、供下一批次使用的经验。
区域选择与数据驻留
首先要选择区域。如果所在国家已有本地区域，它可提供多个可用区以保障韧性，并为本地用户提供低延迟。AWS 亚太（曼谷）区域（ap-southeast-7）就是一例：它为拥有泰国用户的组织提供了云时代大部分时间里都不存在的选择，无需再从新加坡为泰国提供服务。对于延迟敏感的系统，以及其政策或监管机构倾向于数据留在境内的组织，本国区域是默认的起点。
有两点需要注意。新区域上线时并不提供所有服务；在做出决定前，请逐一核对设计中每项托管服务是否在该区域的服务列表中，并准备备选方案（换用其他服务，或将该组件部署到其他区域）。数据驻留首先是政策决定，其次才是技术决定：PDPA 等个人数据保护法律允许在满足条件时跨境传输，而金融服务等行业的监管机构可能还有各自的要求。请书面列明哪些数据类别必须留在境内、哪些可以为灾难恢复复制到境外，并由法务和合规团队确认。然后将其编写为组织策略中的区域限制，使放错位置的资源被事先阻止，而不是事后才被发现。
灾难恢复同样需要明确。在区域内，多个可用区可防范单个设施故障。若要防范区域级事件，需要决定是否可以使用第二个区域存放备份或作为备用、应选择哪个区域，以及业务愿意为怎样的恢复时间和恢复点投入资金。
Terraform：以代码定义着陆区
着陆区中凡是能以代码定义的内容都应如此：账户和组织策略、网络和路由、身份和角色、日志和审计跟踪、加密密钥、备份策略、预算和告警。我们首选 Terraform，因为它是声明式的、不绑定特定云服务商，并且可以与应用代码在同一个拉取请求流程中审查。
以下几项实践有助于保持可控。将状态文件远程存储并加锁，每个环境、每个逻辑组件各用一份状态，使一处出错不会波及他处。为反复创建的资源（例如一个服务及其容器定义、负载均衡规则、IAM 角色和日志组）编写小而命名清晰的模块，并进行版本管理。通过统一的标签模块为每个资源标注负责人、环境、应用和成本中心，因为日后的成本控制有赖于此。每次变更都运行 plan，要求审查，并从流水线而非个人电脑执行 apply。定期检测配置漂移，将在控制台手动所做的更改视为需要纠正的事件，而不是新常态。
结果是，第二批的环境只需一个拉取请求，而不是一个项目。
切换模式对比
按应用而不是按整个项目选择模式。可容忍的停机时间、数据量以及流量到达系统的方式，决定了哪种模式适用。
| 模式 | 工作方式 | 最适合 | 停机与回滚 |
|---|---|---|---|
| 一次性切换（离线） | 停止源系统，复制数据，启动目标系统，切换 DNS 或端点。 | 小型系统、批处理工作负载、有维护窗口的内部工具。 | 停机时间等于复制时间。回滚很简单：重新指向未改动的源系统即可。 |
| 先复制，再切换 | 在源系统保持运行的同时，将数据库持续复制到目标环境（例如使用托管复制服务）；在切换时完成最终同步并切换。 | 无法接受长时间中断、但可容忍短暂中断的数据库和 ERP。 | 停机数分钟。回滚需要反向复制，或接受切换后数据的丢失；须事先决定。 |
| 蓝绿部署 | 在源环境旁边完整构建并测试目标环境；通过负载均衡器或 DNS 一步切换流量。 | 无状态和 Web 层工作负载；数据层已完成迁移的应用。 | 接近零停机。只要数据层是共享或同步的，回滚就是反向执行同一次切换。 |
| 金丝雀 / 加权 | 将一小部分流量（按权重、区域或用户群）导向目标环境，随着信心增强逐步加大比例。 | 用户众多、面向客户的应用；在所有人受影响之前发现问题。 | 设计上无停机。回滚即降低权重。需要处理好会话，并保证两侧数据一致。 |
| 绞杀者模式（渐进式） | 每次将一项功能路由到目标环境中的新服务；旧系统逐步缩小，直至停用。 | 正在重构的大型单体应用；为期多年的现代化改造项目。 | 每一步均无停机。按功能回滚。整体最慢，每次变更的风险最低。 |
演练回滚
每份运行手册都有回滚章节，但很少有团队真正执行过。请在非生产环境中，由同一批人员、按同一份检查清单并计时，至少完整演练一次切换，然后再演练回滚。在切换日之前确定是否继续的判定标准（哪些测试必须通过、哪些相关方必须确认、截止到什么时间），并指定唯一的决策人。明确设定不可回头点：过了这一刻，新交易只存在于目标环境中，回滚就意味着要手工核对数据。
在正式切换期间，应按固定时间沟通，而不是出了状况才沟通：每三十分钟发一次状态通报，即使只是报告一切按计划进行，也能让业务部门安心、让团队保持专注。切换完成后，趁细节记忆犹新时开一次简短的复盘会，并更新实战手册。
从第一天起控制成本
云账单默认只会增长，只有专人负责时才会下降。请在第一个生产工作负载上线前，建立以下控制措施。
- 按账户和应用设置带告警的预算，应用负责人和财务部门均可查看。
- 通过策略强制使用标签，使所有支出都可归属。
- 非生产环境在工作时间以外定时关闭，或按需通过 Terraform 创建。
- 每批迁移完成一个月后进行规格优化审查，因为迁移时的资源规格以安全为先，而非以效率为先。
- 只有在用量稳定且已摸清规律后，才采用承诺用量定价（节省计划或预留容量）。
- 存储生命周期规则：日志、备份和快照按计划转入更便宜的存储层并到期删除。
- 在确能节省运维成本的地方使用托管服务和容器；降低成本并不以重新设计架构为前提。
- 每月进行成本审查，严谨程度与可用性审查相同。