一、教材给的两个契机

教材举的两个场景，有一个共同的形状：

• 新系统的导入：从零要建一套东西。既然本来就没有，那就没有"搬迁成本"——从第一天就按云的方式建，比先自建、以后再搬要省事得多。
• 系统升级：现有服务器到了更换周期。既然旧机器要退休，接下来的钱花在哪就有了选择空间——反正要花一笔，花在自建还是花在云上，是同一笔预算的两种用法。

这两个场景的关键词都是"反正要动"。反过来理解：如果一套系统运行稳定、硬件还新、没人在抱怨，那它就不是上云的契机——迁移有成本、有风险，为了上云而上云是纯粹的折腾。

二、顺势延伸出来的四个场景

把"反正要动"这个逻辑推得更远，还有四种情况同样成立：

• 突发扩容：有个确定日期的活动（大促、开学、申报截止）。自建来不及，云按天扩。
• 业务萎缩要缩容：业务在收缩，但自建的机器退不掉。这时上云是一项"止损"动作。
• 短期项目：只要跑三个月的项目。项目结束机器就没用了——自建等于买一堆以后用不上的硬件。
• 试验性项目：试水一个新方向（比如上 AI），成败未知。花大钱买硬件赌一个不确定的东西，是典型的高风险决策；云上先租几台试试，成本低得多。

这四种的共同点不再是"反正要动"，而是"不值得为它做长期承诺"。教材没把它们列全，但逻辑是同一条。

三、三条判断维度

把上面六个场景抽象一下，就得到三条可打分的维度：

• ① 时间紧不紧：要得很急 → 云的强项（分钟级）；可以从容规划 → 自建也有机会。
• ② 需求确定不确定：量、形态、方向都还没定 → 云的强项（能改能退）；已经算得很清楚 → 自建可以精打细算。
• ③ 有没有明确期限：有终点（项目、活动、试用期）→ 云的强项（到点就退）；要长期跑下去 → 自建可能更省。

这三条其实在问同一件事：这件事的将来，我算得准吗？ 算不准的部分越多，云的价值越大；算得越准，自建越有优势。这也解释了为什么云在创业公司、新业务、试验性项目里渗透得最快——它们恰恰是"将来算不准"的典型。

四、动手 Demo：七个场景打分

下面这个 Demo 把七个场景按三条维度各打 0~2 分，总分给出建议。

# 三个维度各 0~2 分：时间紧 / 需求不确定 / 有期限
def advise(t, u, d):
    s = t + u + d
    if s >= 4:
        return "优先考虑云"
    if s >= 2:
        return "可评估"
    return "自建更划算"

实跑输出：

==================================================================================================
D3 七个场景：什么时候该考虑云服务
==================================================================================================
  三个维度各打 0~2 分：① 时间紧不紧　② 需求确定不确定　③ 有没有明确期限

  场景                          时间紧    需求不确定    有期限    合计    建议
  ----------------------------------------------------------------------------------------------
  新系统导入（从零建一套）      2         2             0         4       优先考虑云
  系统升级（现有硬件到期）      1         1             1         3       可评估
  大促前临时扩容（活动 5 天）   2         2             2         6       优先考虑云
  业务萎缩要缩容                1         2             1         4       优先考虑云
  3 个月的短期项目              2         1             2         5       优先考虑云
  试水 AI，不知道成不成         2         2             1         5       优先考虑云
  稳定跑了 10 年的老系统        0         0             0         0       自建更划算

  ④ 判据：合计 ≥ 4 分 → 优先考虑云；2~3 分 → 两条路都算一遍；≤ 1 分 → 自建更划算。
     注意【缩容】也是契机：自建的机器不能退，云上不用了就关掉、下个月账单就少了。
     教材把这一条和【新系统导入】【系统升级】并列，就是提醒你：
     上云的时机不只在【要变大】的时候，【要变小】和【还没定】的时候同样成立。

读这个输出：最值得注意的反而是唯一那条低分——"稳定跑了 10 年的老系统"拿 0 分，建议是自建更划算。这不是说云不好，而是说：迁移有成本，而这个系统没有需要云来解决的问题。同一张表里，"业务萎缩要缩容"拿了 4 分，因为它的痛点是自建带来的（机器退不掉）。所以这张表判的不是"云好不好"，是"你现在有没有非动不可的理由"。

五、⚠️ 2026 现状

教材的思路没变，但今天有两个新变化值得知道：

• "系统升级"这个契机比过去更常见了。软件与硬件的支持周期在缩短，也出现了因授权方式变化而被迫重新规划的情况（比如虚拟化平台的授权调整让一批企业重新评估基础设施）。每次被迫重规划，都是一次重新选路的机会——这正是教材这条判据最现实的用法。
• 又多了一个教材没写的强契机：AI。很多企业第一次真正要动基础设施，是因为要跑大模型或做数据分析，而这类负载算力需求大、方向变化快、还有明显的试验性质——三条维度全部指向云。今天"试水 AI"已经是现实中最高频的上云入口之一。
• 反过来，有一条教材时代的理由今天要打个问号：单纯为了"省运维人力"而上云，收益已经不如从前——因为云上的成本治理本身也是活。上云的理由，越来越要靠"弹性"和"算不准"，而不是"省人"。

30 秒实验

想一件你手上正在犹豫的事——不一定与技术有关，装修、换车、招人都行。问三句：

1. 这事要得很急吗？
2. 结果我算得准吗？
3. 它有明确的终点吗？

三条里占了两条以上，你会发现"先租后买"这类可退的方案更合适——这正是教材这两条契机的日常版本：在算不准的阶段，别做长期承诺。

常见误区

1. 错误：上云是"升级"，所以越早越好。——纠正：上云不是升级，是选路。它换掉的是资源的获取方式，不是系统的高低。一个运行稳定、成本已摊平的老系统搬上云，很可能既没省钱、又承担了一次迁移风险——Demo 里那条 0 分场景说的就是这件事。

2. 错误：只有业务变大的时候才需要考虑云。——纠正：变小的时候同样是契机，而且更急。业务萎缩时自建的机器退不掉，成本卡在原地；这时候上云是止损，不是扩张。教材把"缩容"和"新系统导入"并列，用意正在此。

3. 错误：新系统反正要用云，先自建以后再搬也一样。——纠正："以后搬"的成本常常被低估。系统一旦按本地的方式写（依赖固定 IP、本地路径、绑定的中间件），迁移就变成改造。新系统导入的最大红利，是可以在第一天就按云的方式设计——省下的不是钱，是后面那次不想做的改造。

4. 错误：把"要不要上云"当成一个技术问题。——纠正：它首先是一道时间题和确定性题。技术选型是后面的事；先回答"这件事我算得准吗、急不急、有没有终点"，答案往往自己就出来了。先问业务的不确定性，再问技术方案——这个顺序错了，后面全是返工。

• ☐ 下一节（1-4 数据中心与云服务：数据中心、主机租用、机房租用、主机托管）

相关笔记

• 云服务的特点 —— 上一篇：这一篇是那两条特点反过来用的结果
• 数据中心与云服务 —— 下一篇：不做云、只租地方，有哪几种做法
• 从基础设施看云计算的优越性 —— 自建到底要花哪些钱，是"要不要自建"的那一半答案
• 云服务的市场规模 —— 为什么这些年上云越来越普遍，数字在这里
• ☁️ 云计算 · 索引 —— 全课路线图