波仔
🕸️ 第六章 Web与云计算的关系
📄 一句话概括

迁移不是一个动作，是六种策略的分配；把所有应用当成同一种来搬，是这类项目最常见的失败原因。

📝 本节和前面几节的关系

前面七节讲的是云【是什么、怎么卖、落在哪、怎么管】。这一节回到动手：手头已有的系统，怎么搬过去。 教材 6-8 的并列关键词只有一个【迁移】。

一、迁移的六种策略

教材只讲了一个词【迁移】。真动手时，它会被拆成六种做法，业内叫 6R：

关键认识：每一种都有它正当的位置。 百分之百重写是错的，百分之百原样搬也是错的。这是一个分配问题，不是选一个动词。

二、一份组合大概怎么分

真实项目里，一份 100 个应用的组合常见这么分（口径 A）：Rehost 40 个、Replatform 25 个、Refactor 15 个、Repurchase 10 个、Retire 或 Retain 10 个。

给中小企业的口径（口径 B）也差不多：Rehost 35%~50%、Replatform 20%~30%、Repurchase 10%~15%、Refactor 5%~10%、Retire 5%~10%、Retain 5%~10%。

两个口径都在说同一件事：Rehost 占大头，Refactor 永远是少数。

为什么？ 因为 Refactor 最贵、最慢、风险最高。主流做法是：先用 Rehost 把系统搬上云站稳，之后再把少数几个真正值得重写的挑出来做。

【全部重写一遍】的方案之所以危险：它把【迁移】和【现代化】两件事同时做，工期容易失控、预算容易翻倍，而且——搬之前你就没法验证云到底给你带来了什么。

三、Retire 为什么最容易被忽略

六种策略里，Retire 是唯一一个【不干活】的——而它恰恰最容易被跳过。

因为要发现哪些系统该退役，就得先老老实实做清点。 而清点是最枯燥的一步，很多项目为了赶进度直接跳过，结果把一堆死系统也搬上了云。

举个真实的量级：100 个应用里如果有 10 个是没人用的死系统，直接关掉就等于省下全部工作量的 10%。

这不是省钱，是省【命】——迁移最缺的从来不是预算，是人。 把人力从【搬一个没人用的系统】里省出来，投到核心业务上，这才是 Retire 的价值。

四、搬迁的工具与节奏

三家厂商各有自己的搬迁工具：AWS 的 Application Migration Service（MGN）、Azure Migrate、GCP 的 Migration Center。它们都能做自动发现、评估和复制，比自己写脚本可靠得多。

整个过程的节奏一般是五步：

  1. 摸家底：几周到几个月，这一步最容易被跳过，也最不该跳过
  2. 搭落地区：账号结构、网络、权限、安全基线——迁移前必须完成
  3. 分批搬：3 ~ 6 波，12 ~ 24 个月，按依赖关系分组
  4. 持续优化：搬完才刚开始——调规格、买预留、挪存储层
  5. 现代化：只对少数值得重写的应用做

整体 2 ~ 5 年。 凡是承诺【三个月全部上云】的，都要打个问号。

还有一个数字要记住：搬回本地的情况是存在的——IDC 欧洲 2026 说 14% 的欧洲企业搬回过一部分负载，Flexera 2025 说 21% 的云负载已经回迁。原因前两位是成本 42%、合规 38%。 另外，49% 的生产负载一直留在本地，从来没搬过。

所以【搬到云上】不是终点，【放到合适的地方】才是。

五、动手 Demo：六种策略怎么分

把一份 100 个应用的组合自己分配一遍——看看【不干活】的那一档，能省下多少。

plan = [("Rehost", 40), ("Replatform", 25), ("Refactor", 15),
        ("Repurchase", 10), ("Retire / Retain", 10)]
total = 0
for name, n in plan:
    total += n
    print("  %-16s %2d 个" % (name, n))
print("  合计 %d 个" % total)
print()
print("  假如 Retire 那一档里有 10 个是死系统：")
print("    直接关掉 = 省下 10 个应用的迁移工作量 = 全部工作的 10%")

实跑输出：

--------------------------------------------------------------------
迁移的六种策略（6R）
--------------------------------------------------------------------

  教材只讲了一个词【迁移】。真动手的时候，它会被拆成六种做法：

  策略          做什么                            改动量
  ------------------------------------------------------------
  Rehost        原样搬上云（lift and shift）      几乎没有
  Replatform    小改一下，换成托管服务            小
  Refactor      重写成云原生                      大
  Repurchase    换成 SaaS                         中
  Retire        直接关掉                          无
  Retain        先留在原地                        无

  一份 100 个应用的组合，常见的分法（口径 A）：

  策略               个数    占比
  -------------------------------------
  Rehost             40      40%
  Replatform         25      25%
  Refactor           15      15%
  Repurchase         10      10%
  Retire / Retain    10      10%

  合计正好 100 个。另一份给中小企业的口径长这样（口径 B）：

    Rehost        35 ~ 50%
    Replatform    20 ~ 30%
    Repurchase    10 ~ 15%
    Refactor       5 ~ 10%
    Retire         5 ~ 10%
    Retain         5 ~ 10%

  两个口径都在说同一件事：Rehost 占大头，Refactor 永远是少数。
  凡是【全部重写一遍】的方案，工期和预算都会失控——这条有大量前车之鉴。

  Retire 到底省多少：

    100 个应用里，假如有 10 个是没人用的死系统。
    直接关掉 = 省下 10 个应用的迁移工作量 = 全部工作的 10%

    这不是省钱，是省【命】——迁移最缺的从来不是预算，是人。

  搬回去的情况：

  来源                        说法
  --------------------------------------------------------------------
  IDC 欧洲 2026               14% 的企业搬回过一部分负载
  Flexera 2025                21% 的云负载已经回迁

  原因前两位：成本 42%、合规 38%。
  另外 49% 的生产负载，一直留在本地，从来没搬过。

  三家厂商各自的搬迁工具：

  厂商        工具
  --------------------------------------------------------
  AWS         Application Migration Service（MGN）
  Azure       Azure Migrate
  GCP         Migration Center / Migrate to VMs

  大迁移的节奏，一般是这样的：

    摸家底      几周到几个月（这一步最容易被跳过）
    搭落地区    迁移前必须完成，否则后面全是补丁
    分批搬      3 ~ 6 波，12 ~ 24 个月
    持续优化    搬完才刚开始
    现代化      只对少数几个值得重写的应用做

  整体 2 ~ 5 年。凡是承诺【三个月全部上云】的，都要打个问号。

看前六行：Rehost 40%、Replatform 25%——前两项就占了 65%。这就是真实项目的形状：大头是【搬】，不是【重写】。 看最后两行：不干活的 Retire，能省下 10% 的工作量。而它的前提是先老老实实做清点——这是最枯燥、也最值钱的一步。 带走这一章的最后一句：迁移不是一次搬迁，是一次分配。 搬到云上不是目的，把每个系统放到它最合适的地方才是。这也是 6-3 讲【回迁】时那句话的另一面。

30 秒实验

  1. 数一下你手机里装了多久没打开过的 App——这就是个人版的 Retire。
  2. 想想你们公司的系统里，有几个是【没人说得清干什么用】的。
  3. 查一下你常用的网站的服务条款，看它有没有写明数据存放在哪个区域。

常见误区

  1. 错误：迁移就是【把程序搬过去】。——纠正：搬之前要先分类。 十个应用可能对应六种做法。用同一种做法处理全部，是这类项目最常见的失败原因。
  2. 错误：Refactor 最彻底，所以应该优先做。——纠正：它最贵、最慢、风险最高。 主流实践是先 Rehost 上云站稳，再把少数真正值得重写的挑出来。真实组合里 Refactor 通常只占 5%~15%。
  3. 错误：Rehost 没技术含量，是低端做法。——纠正：它有明确的价值——快。 数据中心要到期、合同要终止、或者要先离开本地再慢慢优化，Rehost 都是对的选择。 它不是低级，是【先站稳】。
自测三问（点开对答案） 1. 6R 分别是哪六个？ —— **Rehost**（原样搬）、**Replatform**（小改）、**Refactor**（重写）、**Repurchase**（换成 SaaS）、**Retire**（关掉）、**Retain**（先留着）。 2. 为什么【全部重写一遍】是危险方案？ —— 因为 **Refactor 最贵、最慢、最容易失控**，真实组合里通常只占 5%~15%。**把核心业务挑出来重写、其余先搬上云**，才是主流节奏。 3. 迁移整体大概要多久？为什么？ —— **2~5 年**。要分 3~6 波、12~24 个月搬完，再加上前期的摸底和后期的优化。**任何承诺【三个月全部上云】的方案，都要打个问号。**

相关笔记