服务器迁移前该清点什么：一份能减少停机的迁移清单

迁移出问题，很少是因为技术手段不够，多数是因为漏掉了某个依赖。真正让迁移变顺利的不是操作技巧，而是迁移之前那份清单有多完整。

第一阶段：把依赖全部列出来

迁移的对象不是一台机器，而是一套正在运行的服务及其全部依赖。清点时容易漏掉的有这些。

外部服务的白名单。数据库白名单、第三方接口的 IP 白名单、支付或短信服务的回调来源限制，都绑定了当前服务器的地址。换了机器就换了地址，这些地方全部需要更新，而且往往需要对方配合，不是自己能立刻改完的。

定时任务。它们不在应用代码里，容易被整体忽略。要把任务列表、执行时间、依赖的脚本和环境变量一起记录下来。

证书与密钥。SSL 证书、SSH 授权密钥、第三方服务的凭据文件，都要确认新环境上已就位。

系统层配置。文件描述符上限、内核参数、时区、语言环境、挂载配置。这些通常是历史上逐步调出来的，不记录就还原不了。

反向依赖。有没有其他系统在直连这台机器的地址，而不是通过域名。这类调用方在切换时不会自动跟着走。

镜像不等于完整迁移

用镜像克隆一台机器，看起来是最省事的方案，但它有明确的边界。

镜像主要覆盖系统盘。独立挂载的数据盘、外部存储、数据库托管服务里的数据都不在其中。

如果制作镜像时系统仍在写入，得到的可能是一个不一致的状态。数据库尤其如此，文件层面的复制不保证事务一致，恢复后可能需要修复。

镜像里还会带上旧环境的痕迹：写死的地址、旧的主机名、指向旧资源的配置。这些在新环境里可能表现为难以定位的异常。

因此镜像适合用来快速得到一个相同的基础环境，但数据迁移和配置调整仍要单独做。

第二阶段：数据迁移要留出校验时间

数据迁移的关键不是搬得快，而是搬得对。

优先使用数据源本身提供的迁移或复制能力，而不是文件层面的拷贝。数据库有导出导入和主从复制机制，用它们能保证一致性。

大数据量的迁移应当分两步：先做一次全量，让它在业务照常运行时完成；再在切换窗口内做一次增量同步，把差异补上。这样切换窗口只需要覆盖增量部分，停机时间可以压得很短。

校验环节不能省。对比记录数量、抽样对比关键字段、验证关键业务流程能跑通。校验的时间要在计划里留出来，而不是等切换之后再说。

第三阶段：切换要能灰度和回滚

理想的切换是可以逐步进行的：先让一小部分流量进入新环境，观察错误率、响应时间、后台任务和日志；确认正常后逐步扩大比例；全量之后再观察一段时间。

如果切换依赖域名解析，要提前把解析的缓存时间调短，否则变更后仍会有客户端持续访问旧地址，而这段时间的长度不受控制。调短缓存时间需要在切换前若干时间就完成，让旧的长缓存先过期。

同时要接受一个事实：解析切换不是瞬时的。切换后一段时间内新旧两边都会有流量，所以旧环境不能立刻关停，两边最好都能正常处理请求，或者旧环境能把请求正确转发到新环境。

第四阶段：回滚方案要在切换前准备好

回滚不是"出问题再想办法"，而是切换前就要明确的路径：什么条件下决定回滚、由谁决定、具体怎么操作、需要多长时间。

技术准备包括：旧环境保持可用状态一段时间、迁移前的数据快照仍在保留期内、解析可以快速改回。如果迁移过程中做了不可逆操作，比如在旧库上执行了结构变更，那回滚就失去了可能，这类操作应当推迟到确认稳定之后。

切换完成后还有事要做

确认所有定时任务在新环境上正常执行了一轮。确认监控和告警已指向新环境，而不是还在监控旧机器。确认备份任务已覆盖新环境。确认外部白名单已全部更新完毕。最后再把旧资源清理掉，避免留下持续计费的闲置资源。

这些收尾工作容易在"迁移成功"的松懈中被跳过，而它们恰恰决定了新环境是不是真的处于可运维状态。

依赖清点可以按方向来做

把依赖分成"我依赖谁"和"谁依赖我"两个方向，能减少遗漏。

我依赖谁这一侧，包括数据库、缓存、对象存储、第三方接口、消息服务、时间源、软件源。这些在新环境里都要确认可达，而且对方如果有来源限制，需要提前更新白名单。

谁依赖我这一侧更容易漏，因为它不在自己的配置文件里。要确认的有：有没有其他系统直连本机地址、有没有外部服务的回调指向本机、有没有定时任务从别处访问本机、有没有监控探测点指向旧地址。这些调用方在切换时不会自动跟着走，需要逐个通知或修改。

清点方式除了看配置，还可以从网络连接和访问日志入手，看实际有哪些来源在访问这台机器、这台机器又在访问哪些目标。实际数据往往会暴露出文档里没有记录的依赖。

白名单更新要留出提前量

外部服务的来源限制是迁移里最容易造成延误的一项，因为它不完全由自己控制。

需要提前处理的原因有两个。一是有些平台的白名单变更需要走审核，不能立即生效。二是很多平台的白名单条目数量有限，可能需要先腾出位置，而不能简单地把新地址加上去。

推荐的做法是在切换之前就把新地址加入白名单，与旧地址并存一段时间。这样切换时不需要等待任何审核，切换后确认稳定再把旧地址移除。

如果某个平台的白名单只能容纳单个地址，无法并存，那么这一项就必须放在切换窗口内完成，并且要提前确认变更的生效时间。这类约束应当在制定切换计划时就识别出来，而不是在切换当晚才发现。

腾讯云国际和阿里云国际商品当前开放；AWS 与 Google Cloud 商品目前未开放，本文不提供相关导流。可用迁移工具、镜像能力与解析配置均以对应国际站控制台实时信息为准。

官方来源

常见问题

服务器迁移前该清点什么需要注意什么？

操作前先确认账号属于国际云对应站点，并备份关键数据或记录当前配置。按本文步骤完成后做一次验证。需要账号可申请账号，续费见自助充值。

出错后如何快速回滚或止损？

优先恢复到变更前的快照、镜像或原规则；若涉及计费或销毁类操作，先停止继续变更，再按官方控制台状态与工单路径处理。不确定时不要反复点击高危按钮。

没有对应云账号时怎么开始？

可先通过申请账号开通国际云账号，再用自助充值完成额度准备。新账号建议先完成 MFA、访问密钥收敛与费用告警，再部署业务。