云迁移 6R 策略
6R 迁移策略：Rehost/Replatform/Repurchase/Refactor/Retire/Retain 的决策、执行与 TCO 评估。
前置知识与学习目标
「要不要上云、怎么上云」不是一个问题，而是每个应用各自的问题： 存量系统里既有三年没动过的遗留单体，也有本该下线却没人敢删的僵尸 服务。6R 策略（源自 AWS 迁移框架，业界通用的扩展版本还有 7R——多了 Relocate）给每个应用一个迁移「处方」。
完成本文后，你应当能够：为单个应用判断适用哪个 R；估算迁移的 TCO 与 风险；理解数据迁移与切换验证这两个最难环节。
1. 六个 R 全景
| 策略 | 一句话 | 改动量 | 典型周期 | 适合 |
|---|---|---|---|---|
| Rehost 重新托管 | 原样搬（lift & shift） | 几乎为零 | 天-周 | 快速下机房 |
| Replatform 平台替换 | 小改造换托管件 | 低 | 周 | 想吃托管红利 |
| Repurchase 重新购买 | 换 SaaS 产品 | 中（数据迁移） | 周-月 | 商品化能力 |
| Refactor 重构 | 深度改造上云原生 | 高 | 月-年 | 核心且长生命周期 |
| Retire 退役 | 下线不再需要 | - | - | 僵尸应用 |
| Retain 保留 | 留在原地 | 零 | - | 合规/临退休 |
关键认知：成熟企业的迁移组合是 6R 的混合，而不是全量某一种。 行业普查的常见分布大致是：Rehost 与 Retain 占大头，Refactor 只留给 少数高价值应用——「先整体 Rehost 落地，再按需渐进优化（Replatform/ Refactor）」是风险可控的主流路径。
2. 六个 R 逐个拆解
2.1 Rehost：搬机器，不改代码
把物理机/虚拟机的镜像直接搬到云上（VM 导入工具，如 AWS Application Migration Service、Azure Migrate）。价值在快速结束机房合同；代价是 带着旧架构的缺点上云，前期往往「成本不降反升」。适合大量同质化的 存量系统。
2.2 Replatform：小手术换托管件
改动小但吃到托管红利：自建 MySQL 换 RDS、自建 MQ 换托管队列、 Tomcat 挂到容器平台。代码基本不动，主要是换掉运维重的中间件。 性价比最高的策略之一，适合多数中型应用。
2.3 Repurchase：不迁移，改采购
自建的邮件/CRM/工单系统，改用 SaaS（Salesforce、飞书、Workday）。 迁移的实质变成数据搬家 + 集成改造。判断标准：这个能力是不是 商品化的？商品化的东西自建就是负债。
2.4 Refactor：为云重新设计
把单体改造为微服务、改造为云原生架构，吃弹性伸缩、按量计费、 高可用的全部红利。成本与风险都最高，只值得投给：生命周期长、 业务波动大（弹性收益高）、且属于核心竞争力的应用。通常不是 「迁移前重构」，而是「先 Rehost 上云，再按业务节奏重构」。
2.5 Retire：发现的 10-20% 可以直接删
迁移评估的意外收获：盘点后发现有两位数百分比的应用其实没人用了 （业务下线了但系统还在跑）。直接退役，省下的预算补贴其他迁移。
2.6 Retain：光明正大地不动
因合规（数据必须留在本地）、许可证锁定、即将退役等原因暂不上云。 保留也是决策——把它写进迁移计划并定期复审，而不是无人负责地遗忘。
3. 迁移评估：决定每个应用走哪条 R
3.1 应用画像（评估维度）
| 维度 | 关键问题 | 指向 |
|---|---|---|
| 业务价值 | 还有多少活跃用户/交易？ | 低 -> Retire |
| 技术栈 | 中间件是否可替换为托管？ | 可 -> Replatform |
| 架构耦合 | 与其他系统的接口数量 | 高耦合 -> 先 Retain/Rehost |
| 数据引力 | 数据量与迁移窗口 | TB 级 -> 在线复制方案 |
| 合规约束 | 数据能否出本地/出境 | 不能 -> Retain/托管私有云 |
| 生命周期 | 还有几年寿命？ | < 2 年 -> Rehost 或 Retain |
3.2 TCO：别只比较电费
迁移 TCO 至少要含：计算存储网络费用、迁移工具与专线费、双跑期费用
（新旧环境并行 1-3 个月）、人力投入、上云后的运维组织变化、以及
预留/节省计划的采购策略。只拿「服务器电费 vs 云账单」比较会得出
「上云更贵」或「上云巨省钱」两个都错的结论。稳态负载的长期 TCO
未必低于自建（见 030-PublicCloudPrivateCloudHybridCloud），弹性负载
才有数量级优势。
3.3 风险评估
- 技术风险：OS/中间件版本过老，云平台不再支持 -> 升级先行；
- 数据风险：迁移窗口内的一致性（双写/停写）；
- 组织风险：运维团队技能转型，配合迁移安排培训。
4. 迁移执行：三个最难环节
4.1 分批迁移（Wave 规划）
Wave 1（试点）：低风险、独立的应用，验证流程与工具
Wave 2（主体）：按业务域分批，每批保留回退窗口
Wave 3（攻坚）：强耦合核心系统，待依赖迁完后进行依赖关系决定批次顺序：先迁「被依赖少的」，核心系统放最后。每个 Wave 都要设定明确的成功标准（性能基线、错误率、回退触发条件）。
4.2 数据迁移：最后一公里决定成败
| 方案 | 原理 | 适用 |
|---|---|---|
| 离线搬运 | 停机导出导入/物理设备 | 小数据量、可停机 |
| 在线复制 | CDC 持续同步（如 DMS） | 大数据量、小停机窗口 |
| 双写过渡 | 新旧库同时写再校验 | 高一致性要求（复杂度高） |
数据库迁移的标准姿势是 CDC（变更数据捕获）：先全量复制，再持续追 增量，切换时只需分钟级停写。大文件用离线设备（如 Snowball 类）， 避免走公网既慢又贵。
4.3 切换验证与回退
灰度切流（DNS 权重/LB 权重 1% -> 10% -> 50% -> 100%）
→ 每档观测核心指标：错误率、延迟、业务转化
→ 定义回退触发线（如错误率 > 1% 持续 5 分钟）
→ 回退预案演练过至少一次（没有演练过的回退方案等于没有）切换窗口选择业务低峰，保留旧环境完整运行至少 1-2 周再下线—— 这是你唯一的后悔药。
5. 常见坑实录
坑一：Rehost 落地即止，账单翻倍。 机器按本地物理规格 1:1 映射上云 （16 核 64G「照搬」），实际 CPU 利用率常年 10%；又在按量计费下跑稳态 负载。Rehost 的正确后续是 90 天内的 Right-sizing（降配到真实水位）与 预留实例/节省计划采购，否则「上云更贵」就成了自我实现的预言。
坑二：评估做成了资产盘点。 把 CMDB 导出一张表就算评估完成，回答的 全是「有多少台机器、什么配置」，没回答「业务价值、耦合度、合规约束」。 前者是搬运清单，后者才是 6R 处方——Retire 的机会恰恰藏在业务价值盘点 里，纯资产盘点永远发现不了。
坑三：大爆炸切换。 整个应用停写一晚、一次性切流、成功则罢失败则 整晚回滚。第 4.3 节的灰度切流之所以逐档放大，就是把「回退成本」控制 在每档都可承受的范围；不做灰度等于把回退成本压到最高。
坑四：双跑变双付。 切流完成后旧环境「再看看」，一看看了半年，两份 账单并行。双跑期必须在迁移计划里写成有截止日期的任务（通常 1-2 周）， 到期由明确的负责人拍板下线；没有 owner 与 deadline 的旧环境只会 一直付钱。
坑五：低估数据引力。 10 TB 数据走公网复制，按 100 Mbps 满速也要 10 天，流量费另算。TB 级以上先算「数据搬运账」：离线设备、专线、 CDC 增量追平，各方案的时间与费用差异是数量级的；数据窗口常常反过来 决定 Wave 排序。
6. 面试题思路
- 「给你一个应用，怎么决定用哪个 R？」：按硬约束收敛的顺序回答， 而不是背六个定义：先合规（数据不能出本地 -> Retain 直接排除大半 选项），再业务价值（没人用 -> Retire），再生命周期与耦合（寿命短、 耦合重 -> Rehost/Retain），最后才谈收益（弹性、托管红利 -> Replatform/Refactor）。把「排除法」讲清楚比「选一个」得分高。
- 「迁移最大的风险是什么？」：不要答「宕机」。宕机只是表象，真正 的高危项是两个：数据一致性（切换窗口内新旧库的分叉，答 CDC 追平与 双写校验），和回退预案没演练过（答 4.3 的回退触发线与演练要求）。 顺带补一句组织风险（运维技能断档）是加分项。
- 「上云一定省钱吗？」：标准答案是「看负载形状」。弹性负载（潮汐 明显、大促峰值）有数量级优势；稳态负载在算入双跑期、人力与迁移 成本后，3 年 TCO 与自建差距不大，省的是隐性成本（机房运维、硬件 生命周期管理）而不是电费。能提到预留/节省计划对稳态负载的修正， 说明真算过账。
7. 动手练习
练习一：选 R 演练（15 分钟）。
任务：给下面三个应用各选一个 R 并写出至少两条依据：
- 运行 20 年的 ERP，合同要求数据不出本地机房，预计 3 年内替换；
- 日均 10 万订单的电商单体，MySQL 自建且版本老，团队想尽快摆脱机房， 又要求高峰期数据库可弹性扩展；
- 三年前业务下线的报表系统，每月仍在产生服务器费用，无人认领。
提示：第 1 题先看合规与寿命两个硬约束；第 2 题注意「尽快下机房」 与「数据库要弹性」是两个诉求，允许组合策略；第 3 题先验证再动刀。
参考答案：1 Retain（数据不出本地是硬约束，且 3 年寿命不值得 投入；写进计划定期复审）。2 主路线 Rehost + 数据库 Replatform（应用 原样上云快速结束机房合同，数据库顺势换托管 MySQL 并配只读实例弹性 扩展；后续按业务节奏再评估 Refactor）。3 先确认为僵尸（访问日志、 业务方确认），走 Retire；确认前严禁直接停机，这是「先验证后退役」 的红线。
练习二：三年 TCO 对比（20 分钟）。
任务：某稳态系统自建方案为 20 台服务器（一次性 120 万、三年电力 带宽运维合计 45 万、专职运维人力 0.5 人年 x 3 约 60 万）。云方案为 同规格虚拟机三年按需计费 260 万；已知：上云需双跑 2 个月（另付 30%） 、迁移人力 40 万、签三年预留可再省 40%。分别算两个方案的三年 TCO， 回答「这个负载值不值得上云」；再答：若该系统流量呈潮汐形（峰值 5 倍 于均值），结论如何变化？
提示：先把成本项列全再算数——双跑费按「云费用 x 时长占比」计； 预留的 40% 节省只作用于三年云费用本身，不作用于迁移人力。
参考答案：自建 TCO = 120 + 45 + 60 = 225 万。云方案：按需 260 万 x 3 年负载里先叠双跑（260 x 30% x 2/36 约 4.3 万）+ 迁移人力 40 万， 签预留后云费用 260 x 60% = 156 万，合计约 200 万。结论：该稳态负载 上云三年约省 10-12%，属于「差距不大、省的是运维隐性成本」区间；决策 依据应转向机房退出、运维组织精简等战略项。若流量呈 5 倍潮汐，自建 必须按峰值买 100 台而均值利用率仅 20%，云上按量弹性后费用大致等于 均值负载 x 单价——此时上云从「省 10%」跳到「省一半以上」，负载形状 才是结论的分水岭。数字为教学设定，重点是成本项清单与「形状决定 结论」的推理。
练习三：Wave 规划（15 分钟）。
任务：10 个应用待迁移：A 核心交易（被 B、C 依赖）、B 商品中心 （被 D 依赖）、C 用户中心、D 营销活动、E 内部报表、F 文件服务（被 A 依赖）、G 邮件网关（无依赖、低风险）、H 旧版官网（待 Retire）、 I 数据看板（依赖 E）、J 客服工单（依赖 G）。排出三个 Wave 及理由。
提示：规则是「被依赖少的先行、试点用低风险无依赖的、核心殿后」； Retire 的 H 走的是盘点确认流程，不占迁移 Wave。
参考答案：Wave 1（试点）：G、E——无依赖或仅被依赖，风险低， 用来验证工具与流程；同时启动 H 的僵尸确认。Wave 2（主体）：F、B、 C、D——等 Wave 1 验证后并行推进，注意 F 虽被 A 依赖但它本身依赖 少，必须先于 A 完成；B 依赖 A 的读接口需临时双读方案。Wave 3 （攻坚）：A、I——A 是被依赖核心殿后，I 依赖 E 已在 Wave 1 完成。 验收要点：每个 Wave 写明成功标准（性能基线、错误率、回退触发线）， Wave 间设缓冲周处理遗留问题。
小结
- 初学者要点：6R 是按应用逐个选的「处方集」；多数企业的现实组合是 Rehost 为主 + Retire/Retain 收尾 + 少数 Refactor；评估看业务价值、 耦合度、合规与生命周期四个硬约束；执行上分 Wave 试点先行、数据 用 CDC 在线复制、灰度切流 + 演练过的回退预案。
- 进阶注意：Rehost 的常见后续是「成本不降反升」，要在上云后跟进
Right-sizing 与托管化改造（见
240-CloudCostOptimization）；TCO 必须 含双跑期与人力，弹性负载才谈得上数量级节省；核心系统的 Refactor 最好按业务节奏分阶段做，避免「大爆炸式重构 + 搬家」双重风险叠加。
自我检查
- 能用「合规 -> 业务价值 -> 生命周期与耦合 -> 收益」的排除顺序为一个 应用选 R，并说出每一步排除了哪些选项；
- 能列出 TCO 的全部成本项（含双跑、迁移人力、预留策略），并解释为什么 「电费对比」两种结论都错；
- 能描述 CDC 数据迁移的「全量 + 增量 + 分钟级停写」三段式，以及灰度 切流的档位与回退触发线；
- 能指出「双跑变双付」「Rehost 落地即止」这两个坑的责任机制缺口 （无 owner、无 deadline、无后续优化任务）；
- 能为一个 10 应用清单排出 Wave，并说明「被依赖少的先行、核心殿后」 的排序规则。