很多团队的业务涨到一定规模后，都会碰上服务器迁移的问题。旧机房租约到期，性能跟不上访问量，运维成本一点点往上走，几件事叠在一起，就得做决定。迁移的步骤并不复杂，但前期没规划细，切换当天很容易乱套。这里结合一个实际案例，说说腾讯云服务器迁移时哪些地方容易出问题，以及切换应该怎么排。
迁移前先盘点
动手之前，先把现有环境摸清楚。这类事故往往出在一个不起眼的依赖上，漏掉了就很难发现。建议至少盘点下面几项：
- 服务清单：每台服务器上跑了什么应用，开了哪些端口，有哪些定时任务和守护进程。
- 数据规模：数据库容量、文件存储大小和每天的增长量。据此估算同步需要多久。
- 外部依赖：域名解析、第三方接口的 IP 白名单、支付回调地址、对象存储的访问密钥。这些一旦漏掉，切换后最先出问题的往往就是它们。
- 性能基线：记录迁移前 CPU、内存、磁盘 IO 和带宽的峰值，迁移后拿来对比。
盘点完成后，画一张简单的架构图，标出每个组件的位置和它们之间的通信关系。出问题排查时，这张图比翻文档快得多。
案例：一家家居用品电商的迁移过程
这是一家做家居用品的中小电商团队。原有业务部署在自建机房，包括 3 台应用服务器、1 台 Nginx 负载均衡机和一台 MySQL 主库。大促期间访问量涨了几倍，旧机房的带宽和扩容能力慢慢跟不上，于是他们决定迁到腾讯云，目标是切换时不影响用户。整个过程分三个阶段。
第一阶段：搭环境，做预同步
团队先在腾讯云上建了一个和旧环境结构一致的私有网络（VPC），按子网把应用层和数据层分开。应用服务器用镜像复制系统环境，避免手动装依赖时版本对不上。数据库用数据传输服务做了全量加增量同步，保证正式切换前两端数据基本一致。这一阶段大约持续两周，业务没有受到影响。
第二阶段：功能验证和压测
新环境搭好后，测试人员通过修改本地 hosts 文件直接访问新环境做验证，不影响线上用户。重点检查的是最容易出问题的几个功能，包括支付回调、订单导出和图片上传。另外用压测工具模拟了日常两倍的流量，观察响应时间和数据库连接数的变化。压测时发现一处连接池配置偏小，调大之后问题消失。这种问题在日常流量下很难暴露，压一下才能看出来。
第三阶段：正式切换
切换选在凌晨流量最低的时段，分四步走。
- 把旧站点设为只读，暂停新订单写入。
- 等数据库增量同步的延迟归零，确认两端数据一致。
- 修改 DNS 解析记录，把域名指向腾讯云负载均衡实例。
- 观察十分钟内的错误日志和核心指标，没有异常后，再关闭旧环境的写入权限。
整个切换窗口大约二十分钟。第二天核对下来，订单量和转化率与迁移前基本持平，页面加载速度提升了将近三分之一。
迁移中容易踩的坑
这次迁移中，团队也遇到了几个值得记下来的问题。
- DNS 缓存：部分用户的本地缓存会在一段时间内继续指向旧 IP。切换前把 TTL 调低，并且保留旧服务器一段时间做兜底。
- 定时任务漏配：一个每天凌晨运行的对账脚本没有迁到新环境，结果第一天的报表缺了数据。迁移时要对照旧服务器的 crontab 逐条核对，不能只看应用本身。
- 安全组策略：新环境的安全组默认策略比旧机房严格，内部服务之间的部分端口需要手动放行。否则表现出来的往往是间歇性超时，排查起来很费时间。
- 数据库账号来源：服务器 IP 变了，数据库账号的访问来源限制也要重新检查，否则连接会被直接拒绝。
迁移之后的收尾
切换完成不等于迁移结束。建议新环境稳定运行一到两周后，再下线旧服务器。下线前先做一份完整的数据快照，同时保留配置文件和部署文档。然后更新运维手册，把新环境的拓扑、监控告警和备份策略写清楚，方便之后接手的人快速上手。
腾讯云服务器迁移不必一次做到完美。评估做细，预同步和验证做扎实，切换窗口控制在能接受的范围内，大部分中小团队都能平稳过渡。过程中留些余量，比一味赶速度更稳。
