机房里的物理服务器跑久了，扩容要排期，故障要靠人顶上去，运维越来越累。这时候把硬件传阿里云，也就是把本地服务搬到云上，是不少团队会考虑的路。不过迁移远不止把文件拷过去。前期没理清楚，切换那天最容易出现服务中断。下面按顺序说说要准备什么，并用一个案例把关键点串起来。
先盘点，别急着动手
盘点是最容易被低估的一步。有团队在迁移途中才发现，某台老服务器上还挂着一个没人记得的定时任务，每天凌晨准时跑一次，停掉就出问题。所以盘点要尽量细，至少包括下面几项：
- 硬件信息，包括CPU、内存、磁盘容量、网卡数量和操作系统版本。这些决定了云上规格怎么选，也决定了系统镜像能不能直接用。
- 业务依赖，包括服务之间怎么调用、连了哪些数据库、依赖哪些外部接口，以及域名解析在哪里配的。依赖关系没画清楚，切换时最容易漏。
- 数据量与变化频率。数据量大小决定全量同步要跑多久，变化频率决定增量同步要怎么排。写入很频繁的库，窗口要留足。
- 性能基线，记录高峰期的CPU、内存和磁盘IO。不要只看平均值，高峰时段的数据才是选规格的依据。
选对迁移方式
硬件传阿里云常见的做法有三种，适合的场景不一样，选错了后面会很被动。
- 整机镜像导入，把服务器系统打包成镜像，导入阿里云后直接创建ECS实例。系统环境复杂、不想逐项重装时可以用，前提是镜像兼容性要提前确认。
- 服务器迁移中心（SMC），通过Agent持续同步源服务器的磁盘数据，支持增量同步。切换窗口短，适合对停机时间敏感的业务。
- 应用层重新部署，在云上重新搭建环境，迁移代码和配置。周期最长，但可以顺便清理历史包袱，适合架构已经老旧的系统。
数据库最好单独处理。直接拷贝数据文件，很容易遇到一致性问题。更稳妥的做法是用数据传输服务（DTS）做结构迁移和增量同步，先保证数据对得上，再谈切换。
案例：某区域电商的迁移过程
某区域电商在本地机房跑着十几台物理服务器，承载订单、商品和会员三套系统。大促临近，他们希望两周内完成迁移，大促期间不再靠机房临时扩容。
团队先花了一周做盘点。结果发现订单服务的高峰QPS是平时的六倍，而磁盘IO主要集中在凌晨的对账任务上。于是他们按峰值来选ECS规格，同时配置了弹性伸缩，避免为了偶发的高峰长期占用大规格实例。数据库先通过DTS做全量同步，再保持两天增量同步，确认数据一致后才安排切换。
切换当晚，团队先把10%的流量指向云上环境，观察30分钟内的错误率和响应时间。没有异常后再逐步放量，整个过程不是一次性全切。整个过程大约40分钟，核心订单接口的中断时间控制在两分钟以内。
复盘时团队提到两点。第一，切换流程要提前演练，回滚方案要写进操作手册，而不是只存在某个人的脑子里。第二，域名解析的TTL要提前调低。否则DNS缓存会让新旧环境的流量混在一起，出了问题很难判断是哪边的锅。
迁移后别急着下线旧机器
服务切过去，迁移并没有结束。接下来两到四周，建议重点做这几件事：
- 持续盯着监控，重点看CPU、内存和慢查询。上云后的负载形态可能和原来不一样，有些问题要过几天才会暴露。
- 检查备份策略，确认云上快照和异地备份真正生效，最好做一次恢复演练。
- 梳理安全组和访问控制规则，只开放必要端口。迁移过程中临时放开的规则，记得收回来。
- 原机房环境先保留一段时间，确认没有遗漏再下线硬件，并妥善处理数据销毁，避免敏感数据留在废旧设备上。
做好前面的盘点，切换时留出灰度和回滚的余地，大多数业务都能平稳过渡。
