一、这道坎有多高

2026 年 200 多个迁移项目的复盘结果：

65% 按时且按预算完成（比 2022 年的 54% 好了不少，工具和方法论都成熟了）。

38% 超出预算，平均超 23%——成本意外是【最常见的体验】，不是例外。

31% 超出工期，头号原因是老系统太复杂——是结构性的，不是执行不力。

18% 至少回滚了一部分工作负载（2026 年 9 月另有一份研究口径是 37%）。

还有一组：84% 的企业把云成本管理列为头号挑战，64% 说成本预测是首要运营难题。也就是说，连成熟团队都预测不准自己的账单。

二、回迁：搬回来的人越来越多

不同调查给出的【至少把一个负载搬回本地】的比例，从 25% 一直排到 53%——口径差别很大，但方向是一致的：回迁已经变成主流现象，不再是边缘案例。

回迁的三大理由（按提及率）：成本 54%、性能 31%、数据主权 27%。

还有一份 2026 年的调查说，86% 的 CIO 计划把至少一部分负载从公有云搬回私有基础设施或本地机房，是有记录以来最高的一次。

不过要公平地说另一面：三家超大规模云的收入同期都在两位数增长，而且它们都推出了混合云方案（AWS Outposts、Azure Arc、Google Distributed Cloud）。所以真正的趋势不是【彻底离开云】，而是【按负载重新分配】——把弹性的、需求起伏大的留在公有云，把稳定的、合规敏感的搬回自有基础设施。

三、账单为什么会失控

最典型的翻车现场是这样：一台本地每年 30 万美元的工作负载，原样搬到云上，变成每年 80 万美元。 功能一样、架构一样，账单翻了 2.7 倍。

这不奇怪。本地机房的成本是按【采购】算的——买一次，用五年，每年折旧。云的成本是按【用量】算的——每一小时、每一 GB 出网流量都在计费。一个常年满载的稳定负载，恰好是云最贵的那种客户。

另外两个相关数字：云浪费（没用起来但一直在付钱的资源）约 29%，是五年来的最高点；而 81% 的组织在云上超支超过 30%。

反过来的一组数据：迁移前做过正式就绪评估的项目，成功率是没做过的 2.4 倍。 这条是这一节最有操作性的一句——省钱的不是搬得早，是搬之前看清楚。

四、虚拟服务器：最常见的做法，也是最大的误会

教材 5-4 的并列关键词是【虚拟服务器】，说的正是最常见的搬法：先把物理机转成虚拟机，再把整台虚拟机搬上云（也就是常说的 lift and shift）。

这个做法本身没错——它的问题在于容易被当成终点。搬完之后你会得到一个【跑在云上的老系统】：

毛病没修：单点故障、硬编码的 IP、本地磁盘依赖，全都还在。

账单更贵：原来买的机器可以一直满载，现在按用量算，闲置也付钱。

失去弹性：云的最大好处是【随用随扩】，但一个不敢动的老系统，你连重启都不敢，更别说自动扩缩。

所以行业里的共识是：lift and shift 是一个过渡手段，不是终点。 迁移后 12 个月的实际云成本普遍比预估高 23%，主因就是没有重新调整规格。

五、动手 Demo：一笔五年期的迁移账

把这一节最有名的那个场景算成一张五年期的账：同一台负载，三种做法。

local_cost = 30          # 万美元/年
cloud_cost = 80          # 万美元/年，原样搬迁
refactor_cost = 48       # 万美元/年，重构后约降 40%
years = 5

print("  迁移成绩单：按时按预算 65%%、超预算 38%%、超期 31%%、回滚 18%%")
print("  %-14s %d 万 × %d 年 = %d 万美元"
      % ("留在本地", local_cost, years, local_cost * years))
print("  %-14s %d 万 × %d 年 = %d 万美元"
      % ("原样搬上云", cloud_cost, years, cloud_cost * years))
print("  多花 %d 万美元" % ((cloud_cost - local_cost) * years))
print("  %-14s %d 万 × %d 年 = %d 万美元"
      % ("重构后上云", refactor_cost, years, refactor_cost * years))
print("  回迁过的企业比例 25%% 至 53%%，首因是成本 54%%")

实跑输出：

--------------------------------------------------------------------
D4 上云的四道坎
--------------------------------------------------------------------
  教材 5-4 讲把现有系统迁到云端的障碍，并列关键词是【虚拟服务器】。
  先看这道坎在行业里的真实高度（2026 年 200 多个项目复盘）：

  环节                真实比例      说明
  ----------------------------------------------------------------------------------
  按时且按预算完成    65%           比 2022 年的 54% 好了一截
  超出预算            38%           平均超 23%
  超出工期            31%           头号原因是老系统太复杂
  需要部分回滚        18%           性能、成本或兼容性问题
  至少回迁一个负载    25% 至 53%    不同调查口径差别极大

  回迁的三大理由（按提及率）：

  ----------------------------------------------------------------------------------------
    成本        54%
    性能        31%
    数据主权    27%
  ----------------------------------------------------------------------------------------

  再看账单本身。抬起来就搬（lift and shift）最典型的翻车现场是：

  ----------------------------------------------------------------------------------------
    一台本地每年 30 万美元的工作负载，原样搬到云上 → 每年 80 万美元
    功能一样、架构一样，账单翻了 2.7 倍
  ----------------------------------------------------------------------------------------

  一笔 5 年的账：

  做法                    5 年总支出                说明
  --------------------------------------------------------------------------------
  留在本地不动            30 万 × 5 = 150 万美元    硬件 5 年一换，成本可预测
  原样搬上云              80 万 × 5 = 400 万美元    功能没变，账单翻了 2.7 倍
  上云并重构后            48 万 × 5 = 240 万美元    重构能压下约 40%

  结论：**上云省不省钱，不取决于【云】这个字，取决于这个负载的形状。**
  弹性负载（白天忙、夜里闲）在云上省；稳定高负载搬上去只会更贵。

  教材 5-4 的并列关键词【虚拟服务器】，说的正是最常见的做法：
  先把物理机转成虚拟机，再整台搬上云。
  **代价是老系统的毛病一个没修，只是换了个房东。**

  迁移后 12 个月的实际云成本，普遍比预估高 23%，
  主因是没有重新调整规格（right-sizing）。
  反过来的一组数据：迁移前做过正式就绪评估的项目，成功率是没做过的 2.4 倍。

三行并列看最清楚：150 万、400 万、240 万。原样搬上去比留在本地多花 250 万；就算重构能压下 40%，五年下来还是比本地贵 90 万。 那为什么还有人上云？因为这笔账里没算进去的东西才是关键：不用提前买硬件、业务高峰期不用等采购、全球部署不用建机房、开发测试环境随手就开。这些不是省钱，是省时间——而时间在有些行业里比钱贵。 所以结论要说得准确一点：上云省不省钱取决于负载的形状。白天忙夜里闲的弹性负载，在云上能省；常年满载的稳定负载，搬上去只会更贵。

30 秒实验

1. 找一个你公司内部系统的服务器，问一下它每天的负载是不是稳定（稳定就意味着云化不一定划算）。
2. 打开任何一家云厂商的定价页，算一台 4 核 8G 的虚拟机跑一年要多少钱。
3. 想一下你所在行业里，有哪些是【弹性负载】、哪些是【稳定负载】。

常见误区

1. 错误：上云一定更便宜。——纠正：要看负载形状。原样搬迁的稳定负载，账单可能是本地的 2 到 3 倍；2026 年有 25% 到 53% 的企业已经开始把部分负载搬回来。
2. 错误：虚拟化搬迁（lift and shift）就等于云化。——纠正：它只是换了房东。老系统的问题一个没修，还多付了按用量计费的钱。它应该是过渡手段，不是终点。
3. 错误：迁移失败是因为团队能力不行。——纠正：头号原因是老系统本身太复杂。所以 31% 超期是结构性的；做过正式就绪评估的项目成功率是不做评估的 2.4 倍。

• ☐ 下一节（5-5 与Web系统兼容的电子邮件服务器：SMTP、POP3）

相关笔记

• 无法变成Web系统的系统 —— 上一节讲哪些搬不动，这一节讲搬的时候会撞上什么
• 导入过程的差异 —— 上云的过程为什么差别这么大
• 运行和管理服务器 —— 内部部署与云服务的成本逻辑
• 云服务的费用 —— 计费方式变了，账也就变了
• 🕸️ Web技术原理 · 索引