深色模式
云迁移步骤
摘要：迁移失败大多是准备不足而非技术难题。本文把一次上云拆成评估、迁移、验证三个阶段，给出每阶段的具体动作、验收标准和回滚预案，适用于从自建 IDC 或其它云迁移的场景。
适用环境
bash
# 源端（待迁移机器）与目的端（云上机器）均需可 SSH
ssh -o ConnectTimeout=5 ops@<源端IP> uptime
ssh -o ConnectTimeout=5 ops@<目的端IP> uptime
# 迁移数据同步工具
which rsync mysqldump pg_dump rclone1
2
3
4
5
2
3
4
5
操作步骤
一、阶段一：评估（占总工作量 40%）
1. 资产盘点
bash
# 在源端采集机器规格与负载基线，作为云上选型的依据
nproc; free -g; df -h; ip addr | grep inet
cat /proc/loadavg
# 连续采样 24 小时更能反映真实峰值
sar -A -o /tmp/baseline.sa 60 1440 2>/dev/null || echo "安装 sysstat 后重试"1
2
3
4
5
2
3
4
5
2. 依赖关系梳理
必须画出「谁访问谁」，尤其是：
- 内网 IP 硬编码的配置文件
- 数据库主从、缓存、消息队列的地址
- 依赖的第三方服务与 IP 白名单
- 定时任务、批处理作业
bash
# 找出硬编码 IP（迁移后最容易漏改的地方）
sudo grep -rInE "\b10\.[0-9]+\.[0-9]+\.[0-9]+|\b192\.168\.[0-9]+\.[0-9]+" \
/etc /opt /home 2>/dev/null | head -301
2
3
2
3
3. 确定迁移策略（6R 简化版）
| 策略 | 适用 | 收益/代价 |
|---|---|---|
| 原样搬迁（Lift & Shift） | 时间紧、应用无法改造 | 快，但省不了钱 |
| 换托管服务 | 数据库、缓存、对象存储 | 省运维，需改造连接 |
| 容器化 | 应用可改造 | 弹性好，改造量大 |
| 保留/下线 | 无法迁移或已废弃 | 别忘了下线也能省钱 |
二、阶段二：迁移
1. 先搭好目标环境
bash
# 云上先建好 VPC、子网、安全组，创建实例并用自定义镜像初始化
# 网络打通（VPN/专线）后再做数据同步1
2
2
2. 数据同步：全量 + 增量
bash
# 文件类数据：先全量
rsync -aHAX --numeric-ids -e ssh /data/ ops@<目的端IP>:/data/
# 再增量（多次执行，逐步缩小差距）
rsync -aHAX --numeric-ids --delete -e ssh /data/ ops@<目的端IP>:/data/
# 数据库：全量导出 + 增量靠 binlog/复制
mysqldump --single-transaction --routines --triggers --set-gtid-purged=OFF \
-h <源库> -u root -p appdb > appdb.sql
mysql -h <目的库> -u root -p appdb < appdb.sql
# 配置主从让目的库追平，切换时停写即可1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
危险
rsync --delete 会删除目标端多余文件。首次同步务必先加 --dry-run 预演，确认删除范围后再执行，避免误删目标端已有数据。
3. 双跑与灰度
不要一次性切流。推荐顺序：
- 云上环境部署完成，用内网直接访问验证功能
- 把 1% 流量导入云上，观察错误率与响应时间
- 逐步放量到 10% → 50% → 100%
bash
# 用 DNS 权重或负载均衡权重做灰度
# 观察关键指标：错误率、P95 延迟、慢查询数1
2
2
三、阶段三：验证与切换
bash
# 1) 功能验证：核心链路全跑一遍
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://<新入口>/api/health
# 2) 数据一致性：对比行数与最新记录
mysql -h <源库> -e "SELECT COUNT(*) FROM app.orders" -N
mysql -h <目的库> -e "SELECT COUNT(*) FROM app.orders" -N
# 3) 性能对比：压测同一接口对比 P95
ab -c 50 -n 5000 https://<新入口>/api/list
# 4) 观察日志有无新类型报错
sudo tail -n 500 /var/log/app/error.log | grep -i "error\|exception" | tail -201
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
四、回滚预案（切之前先写好）
text
回滚触发条件：错误率 > 1% 持续 5 分钟 / 核心接口不可用 / 数据不一致
回滚动作 ：把 DNS 权重或 LB 权重切回源站（DNS 需预留较短 TTL）
回滚前准备：切换前把 DNS TTL 提前调到 60 秒，否则回滚要等数小时生效1
2
3
2
3
注意
DNS 切换是最常见的迁移方式，但 TTL 决定回滚速度。切换前 24 小时务必把 TTL 降到 60 秒，迁移完成稳定后再调回。
验证
- [ ] 资产清单、依赖关系图已产出并评审
- [ ] 数据同步后源端与目的端行数一致、最新记录一致
- [ ] 灰度期间错误率与 P95 延迟不劣于源站
- [ ] 回滚预案文档化，且实际演练过一次 DNS 回切
- [ ] 源站保留至少 7 天不删除
常见坑
- 低估依赖梳理：上线后才发现某个定时任务还连着源站的数据库。
- 不降 TTL 就切 DNS：出问题回滚要等几小时，灾难级失误。
- 数据同步后就停止跟进：切换前几小时产生的新数据没同步，导致数据丢失。
- 迁完就删源站：至少保留一到两周，并保留最后一次全量备份。
- 忽略 IP 白名单：第三方服务只认源站 IP，出口 IP 变了导致接口全挂。