电商促销前迁移网站到云主机需先做好回滚方案

促销开始前迁移网站，最怕的不是部署慢，而是新环境出现问题后无法恢复。无论是独立商城、内容站还是带在线支付的业务系统，网站迁移到云主机步骤都应先从回滚方案开始设计，再安排正式切换。

一、先确定迁移边界和回滚条件

先列出需要迁移的对象：网站程序、数据库、用户上传文件、定时任务、证书、环境变量、邮件配置以及第三方接口参数。还要记录旧主机的操作系统、运行时版本、Web 服务配置、目录权限和计划任务，避免只复制代码却遗漏运行条件。

回滚条件应写成可以判断的规则。例如，新站切换后持续出现支付回调失败、登录异常、订单写入错误，或核心页面错误率明显高于旧站，就暂停继续观察，按预案恢复旧站。不要把“感觉不稳定”作为唯一标准。

需要提前确认的关键数据

• 域名解析服务的管理权限和当前记录值。
• 数据库名称、字符集、账号权限及备份恢复方式。
• 上传目录、静态资源目录和用户生成内容的总容量。
• 支付、短信、邮件、对象存储等外部服务的回调地址。
• 旧主机的登录方式、快照或整机备份是否仍可用。

二、按顺序执行网站迁移到云主机步骤

1. 准备新主机。选择与业务规模匹配的计算、内存、磁盘和网络配置，安装与原环境兼容的运行时、数据库客户端、Web 服务及必要扩展。若直接升级版本，应先在测试环境确认程序兼容性。
2. 建立完整备份。分别备份数据库、网站文件和上传内容。数据库备份完成后，应在独立目录进行恢复演练；压缩包要实际解压检查，不能只看文件大小。备份文件最好放在与新旧主机不同的位置，避免主机故障时同时丢失。
3. 部署程序和配置。导入代码、静态资源与上传文件，重新设置目录权限、环境变量、证书和定时任务。密钥、数据库密码等敏感配置不要直接写入公开代码仓库。
4. 导入数据库并校验。检查表数量、关键业务记录、字符显示、时间字段和索引状态。对订单、会员、库存等重要数据，至少抽样对比迁移前后的记录数量和内容。
5. 使用临时地址验收。通过 hosts 文件、测试域名或内网入口访问新站，依次测试首页、搜索、注册登录、购物车、下单、支付回调、后台操作和文件上传。支付测试应使用服务商提供的测试模式或小范围验证，避免产生真实交易。
6. 安排正式切换。在访问量较低的时段进入维护窗口，暂停会产生新数据的写入，完成最后一次数据库和上传文件同步，再修改域名解析。解析生效时间受 DNS 缓存影响，不能假定所有用户会同时进入新站。

三、回滚方案必须能在现场执行

正式切换前，把回滚步骤写成值班人员可以照做的清单：保留旧主机可访问状态，记录旧解析值；出现严重故障时，先暂停新站写入，再将域名解析恢复到旧站，随后处理新站期间产生的订单、会员或内容数据。

数据回滚是最容易被忽略的部分。如果新站已经接受订单，简单切回旧站可能造成重复订单或库存不一致。较稳妥的做法是记录切换时间、保存新站新增数据，并在旧站恢复后通过人工核对或一次性导入处理。涉及支付和库存时，应由业务人员确认每一笔异常记录。

切换前后的检查表

四、切换后观察重点

新站上线后不要立即释放旧主机。至少保留一个完整业务观察周期，具体时间取决于访问高峰和订单周期。重点查看 HTTP 状态码、应用日志、数据库连接、磁盘增长、队列积压和外部接口响应。对电商站点，还要核对支付成功但订单未落库、库存扣减异常、优惠规则失效等问题。

如果新云主机与旧环境的网络位置不同，部分第三方服务可能存在 IP 白名单。应提前更新允许列表，并确认 HTTPS 证书、跨域规则和回调地址均指向新环境。CDN 缓存也可能继续返回旧文件，发布后要按服务商规则刷新相关缓存。

网站迁移到云主机步骤的核心不是“切过去”，而是让切过去、验证、暂停写入和切回旧站都具备明确入口。

常见问题

1. 可以在促销当天迁移吗？

不建议。促销流量和订单量波动较大，问题定位和数据核对都会更困难，应预留测试和观察时间。

2. 只备份数据库是否足够？

不够。上传图片、附件、配置文件、证书和定时任务同样可能影响业务，至少要完成程序、数据库和用户文件的组合备份。

3. DNS 修改后多久能生效？

通常受 DNS TTL、递归解析缓存和客户端网络影响，可能从几分钟到更长时间不等，因此旧主机不能在修改后立即删除。

4. 什么时候可以关闭旧主机？

应在观察期结束、关键数据核对完成且回滚窗口关闭后再处理。若业务仍有低频访问或异步任务，关闭时间还要相应延后。

做好备份、暂停写入、数据核验和解析回退，才能让网站迁移到云主机步骤真正可控，避免促销期间把一次基础设施调整变成业务事故。