云迁移

先演练切换、留好退路的云迁移。

基础设施迁移的难点，大多在没人写下来的地方：隐藏的依赖、难以搬动的数据，以及形态会改变的成本。我们盘点正在运行的内容，设计目标环境，用代码描述它，并在生产环境迁移前演练切换和回退。

确定云迁移范围 →

服务概要

云迁移是把约定的工作负载迁入云端、在服务商之间迁移，或迁出到自建基础设施。服务包括盘点、目标架构、基础设施即代码、带回退方案的切换演练，以及新环境成本的可见性。

适合这些情况

希望从手工管理的服务器转向可复现环境的团队
因成本或可控性考虑更换服务商，或把工作负载迁回自建环境的企业

其他服务可能更合适

加固一个你打算继续使用的环境
在迁移过程中重写应用本身

先想清楚为什么迁，再决定迁到哪里

成本、可控性、数据存放地点、即将到期的合同，或者平台已不再合适，都是合理的理由，而每个理由都会改变目标环境。迁移可以是迁入云端、在服务商之间迁移，也可以是迁出云端到自建服务器。如果现有环境本身没有问题，只需要更安全的访问和恢复，云安全服务更合适。构建与发布流水线中的控制属于 DevSecOps 服务。如果应用本身需要改变架构，请按遗留系统现代化来规划；在迁移的同时重写应用，会让每一步的风险翻倍。

把现在运行的内容，变成可以重建的目标环境

服务商和平台是否适配，在确定范围时确认。我们不预设一种通用的多云服务。

盘点与依赖

工作负载、数据存储、DNS、证书、定时任务、外部集成、IP 白名单，以及每一项的负责人。

目标架构

按工作负载选择托管服务、容器、虚拟机或自建服务器，并把成本、厂商锁定和运维投入之间的权衡写清楚。

基础设施即代码

用版本化的代码描述目标环境（例如 Terraform 或 OpenTofu），使其可以审查、重建和交接。

成本可见性

为资源打标签，设置预算和告警，并把预期账单与旧环境对比。在真实流量运行之前，估算始终只是估算。

演练切换和回退

每一批迁移都包括：数据传输或同步方案、DNS 和证书步骤、必要时的变更冻结、证明新环境正常服务的检查，以及指定负责人的回退触发条件。切换后写入的数据不一定能自动回流，因此方案会写明回退在多长时间内仍然可行、需要付出什么代价。如需停机窗口，会提前约定。

示例验收：在预发布副本上演练切换

在预发布副本中，团队按照切换手册把流量切到新环境，执行约定的功能和数据检查，然后再切回。记录包括手册版本、耗时、数据检查、发现的问题和限制。这是验收方式的示例，不是客户成果，也不是零停机承诺。

规划、分批迁移、交接

每个阶段开始前确认范围和报价。持续运维是另一项职责，不是迁移项目的默认延伸。

评估与规划
获得盘点结果、附带权衡说明的目标方案、分批迁移计划，以及列明假设的成本估算。
构建与迁移
获得基础设施代码、已迁移的工作负载，以及每次切换的验证记录。
交接
获得运行手册、访问权限模型和成本报告。之后由谁运维哪些部分会明确约定；Wavect 不提供全天候运维中心，也不提供可用性 SLA。

准备账单、架构资料和有权批准变更的人

我们首先需要账户和托管环境的只读访问权限、架构说明、当前账单、数据量、数据存放要求、可接受的维护窗口，以及有权批准生产变更的人。如果迁移发生在供应商交接之后，可查看软件接管中的运营独立性演练，其现有适用条件和条款不变。迁移完成后对应用的持续照料属于软件维护。

// 实证

现有工程项目中的基础设施迁移实践

Hyperstate AI 案例记录了把一台手动部署、GPU 负载很重的单一服务器迁移为容器化、编排化的服务，并用托管方案替换自行维护的高算力库。Twinsoft AI 案例记录了在打造可用于试点的重建版本时，同步构建的 Terraform 基础设施。IKB 案例记录了扩展运行 ChirpStack 的 Kubernetes 集群，这是 Wavect 在 IKB 自有项目内部参与的工程工作，并已完整移交给 IKB 团队。这些案例都不是完整的跨服务商数据中心迁移，属于相关的基础设施工作，不保证取得相同结果。