2-1 优先考虑云服务的时代 · 波仔的云计算课

📄 一句话概括

【优先考虑云服务】不是让你一律上云，而是把默认动作反过来——立项时先问【为什么不上云】，只有找到站得住的理由才自建；Society 5.0 从需求侧推、日本版 FedRAMP 从合规侧筛，两条线一起把这件事变成了惯例。

📝 本节和前面几节的关系

上一章（云服务的市场规模）走完了【云是什么】——从三条判据一直到市场规模。从这一节起，问题换了：知道云是什么之后，什么时候该用它？

其实第一章的考虑使用云服务的契机已经碰过这个问题，但那时的角度是【单个项目该不该动】。这一节的角度更大：整个社会的默认选项正在变——政策、合规、行业惯例一起把云推到了第一顺位。先看清这个背景，后面十二节讲的那些具体选择（云原生、IaaS 还是 PaaS、区域怎么选）才有落点。

一、先把"优先考虑"四个字说清楚

教材用的原词是【优先考虑云服务】，它对应的是一条已经写进不少国家政府采购文件里的原则——云优先（Cloud by Default）。

这四个字最容易被误读成【一律上云】，那是不对的。它真正的意思是一道顺序：

旧的顺序：要建新系统 → 先估算自建要多少钱 → 实在嫌麻烦再问问云。
新的顺序：要建新系统 → 默认按云来做方案 → 只有在明确不适用时才改回自建。

差别在哪里？在举证责任。旧顺序里，你要证明"上云更划算"才能上云；新顺序里，你要证明"这件事不能上云"才能自建。这不是技术选择变了，是流程默认值变了——而默认值比口号有力得多，因为它直接决定了大多数人不去想的那一步。

二、Society 5.0：从需求侧推

【Society 5.0】是日本在 2016 年提出的社会构想。它的前四个阶段是：狩猎社会、农耕社会、工业社会、信息社会。第五个阶段的关键词是超智能社会——把物理世界的传感器数据和网络世界的计算结果打通，让数据跨行业流动起来。

这套构想和云的关系很直接：数据要跨行业流动，就不可能每家各建各的机房。制造、医疗、交通、物流的数据放在各自的机房里，谁也看不见谁；只有都放到能互通的基础设施上，所谓【融合】才成立。

所以 Society 5.0 是需求侧的力量——它不是命令谁上云，而是提出了一个"不上云就做不到"的目标。这比任何行政要求都难违抗。

三、日本版 FedRAMP：从合规侧筛

教材提到的【日本版 FedRAMP】，就是日本的 ISMAP（政府信息系统安全评估制度）。

它的由来和美国的 FedRAMP 一样：政府要采购云服务，如果每个部门各自审核安全性，既慢又浪费——同一家云厂商会被反复审很多遍。于是改成统一评估、集中公开：云厂商自愿申请，通过第三方审计后进入公开名单，各政府机关直接从名单里选。

对采购方来说，这一改的价值在于：合规这道最麻烦的关，被人提前替你过了一遍。你不用再去问"这家云的安全性够不够"，只用问"我的业务需要到哪个级别"。

四、两条线怎么合到一起

力量	来自哪里	它做了什么	对你的影响
Society 5.0	需求侧	提出【数据必须跨行业流动】的目标	不上云就接不进生态
日本版 FedRAMP	合规侧	把云的安全门槛统一评估、公开	合规这道关被提前过完
云优先原则	流程侧	把【先按云做方案】变成默认	举证责任反转到自建一方

三者叠加的结果，就是教材说的【优先考虑云服务的时代】：不是云一下子变好了多少，而是不选云开始需要理由了。

五、动手 Demo：立项时先问三句话

既然默认值反过来了，那么实际做一个项目时，怎么把这道顺序落到纸面上？下面这个 Demo 把它拆成三条可以打分的维度——时间紧不紧、需求会不会变、有没有明确期限。三条都是分越高越该考虑云。

# 三条维度各打 0~2 分，合计分数越高，越该优先考虑云
def judge(time_pressure, req_change, deadline):
    s = time_pressure + req_change + deadline
    if s >= 4:
        return "优先考虑云"      # 先按云做方案
    if s >= 2:
        return "先看能不能上云"  # 拿不准就两边都估一遍
    return "维持自建"           # 找不到非动不可的理由

实跑输出：

==================================================================================================
D1 优先考虑云服务的时代：从 Society 5.0 到立项时的第一问
==================================================================================================
  【一】五个社会阶段，看 IT 扮演的角色怎么变

  阶段                    年代          靠什么运转        IT 的角色
  --------------------------------------------------------------------------------
  Society 1.0 狩猎社会    远古          人与自然共生      无
  Society 2.0 农耕社会    13 世纪起     组织与定居        无
  Society 3.0 工业社会    18 世纪起     机械化与量产      自动化工具
  Society 4.0 信息社会    20 世纪起     信息化            系统与网络
  Society 5.0 超智能社会  2016 年提出   数据与 AI 融合    云＋AI（基础设施）

  【二】立项时先问三句：时间紧不紧、需求变不变、有没有期限
     三条各打 0~2 分，得分越高越该优先考虑云；合计 ≥4 分就基本定了。

  项目                          时间压力    需求变化      期限明确    得分  结论
  ------------------------------------------------------------------------------------------
  新客户门户（3 个月上线）      2           1             2           5     优先考虑云
  引入 AI 客服（无先例）        2           2             1           5     优先考虑云
  五年期数据仓库                1           1             2           4     优先考虑云
  政府数据平台（合规先行）      1           1             1           3     先看能不能上云
  已稳定跑 8 年的计费系统       0           0             0           0     维持自建
  老 ERP 小改版（无期限）       0           0             0           0     维持自建
  产线工控系统改造              0           0             0           0     维持本地

  ④ 得分 0~1 维持自建；2~3 先看能不能上云；≥4 优先考虑云。
     【优先考虑云】的意思是：立项时先问【为什么不上云】，
     而不是先问【能不能上云】。Society 5.0 与日本版 FedRAMP
     从两个方向把这件事变成了默认动作——前者要求数据跨行业流动，
     后者要求政府用的云先过审。一个推着业务上云，一个先替你把合规筛一遍。

读这个输出：最值得看的是最后三行。「已稳定跑 8 年的计费系统」拿 0 分，不是因为它上云不好，而是因为找不到非动不可的理由——三条维度都是 0，说明眼下既没有时间压力、需求也稳定、也没有期限逼着。这种系统如果硬搬上云，风险全是你自己承担，收益却看不见。

反过来，「引入 AI 客服」能在两个维度拿满分：需求会怎么变谁也说不清（所以试错成本越低越好）、上线时间又紧（所以不能等采购）。这正是云最擅长的那类事——不追求一次做对，追求改得快。

六、⚠️ 2026 现状

教材 2022 年出版，两条线的走向都值得补：

ISMAP 已经成形，并且还在改。到 2026 年 2 月初，公开名单上的服务数已到 88 项；AWS、Microsoft Azure、Google Cloud、Oracle、Sakura Internet 都在名单内，Snowflake 于 2025 年底、Cloudflare 于 2026 年 1 月陆续完成注册。日本政府的云服务利用率（实际使用的服务里来自名单的比例）大约在 IaaS 89%、PaaS 90%、SaaS 69% 这一档。制度本身也在调：一边简化外部审计负担、缩短审查周期，一边在准备管理基准的整体重订。
"名单上有外国厂商"这件事本身值得记一笔。ISMAP 从制度设计上并不排斥境外云厂商——它审的是能力和证据，不是国别。所以在讨论【数据主权】时，一个常见的推论错误是：以为换成本国厂商就等于更安全。安全要看你具体需要达到的级别，而不是看厂商的注册地（这一点在 2-11 讲海外法律时会再展开）。
云优先原则的应用范围在扩大。它最初主要针对政府信息系统，现在越来越多的民营企业在立项流程里也照抄了这一条——不是被要求，而是发现"先按云估一遍"能省下前期评估的时间。

30 秒实验

回想你最近经手的一个项目（或者你听说过的任何一个），对下面三句话各打 0~2 分：

它有没有一个不能晚的交付时间？ 有且很紧 → 2 分；有但不紧 → 1 分；没有 → 0 分。
它的需求在做的过程中还可能变吗？ 大概率会大改 → 2 分；可能会小改 → 1 分；基本不会变 → 0 分。
它有没有一个明确的期限或截止点（比如项目结束就归还）？ 有 → 2 分；不确定 → 1 分；没有 → 0 分。

加起来看：如果超过 4 分而当初还是自建的，那么这次立项的默认值就设反了。

常见误区

错误：优先考虑云服务就是要求一律上云。——纠正：它改的是顺序，不是结论。默认按云做方案，但如果发现某个系统确实不能上（比如产线上的工控设备），照样可以自建——只是这时候需要写出理由。默认值和强制要求的差别就在这里：前者让你去论证例外，后者不给你论证的机会。
错误：既然默认要上云，那就不用做评估了。——纠正：恰恰相反，评估这一步现在更关键。默认值的意义是省掉"要不要考虑云"这个反复讨论，把精力集中到"这个系统适不适合"上。Demo 里那三条维度就是评估用的——不做评估的默认，到最后会变成拍脑袋。
错误：日本版 FedRAMP 是给日本厂商设的门槛。——纠正：它是给云服务设的门槛，不看国别。名单上的服务来自各国厂商，包括几家全球性的大厂。它的作用是【统一评估口径】，不是【保护本地市场】。 这一点在选型时很有用：当客户或上级要求"安全要达标"时，你可以先问清是哪个制度的哪一级，而不是直接假定"必须换成某一家"。
错误：Society 5.0 是个口号，离实际工作很远。——纠正：它是需求侧的约束条件。当你的公司要接进某个行业的数据平台、或者客户要求系统能和别家的数据互通时，那个"互通"的技术前提往往就是双方都在云上。口号离得远，但由它推出的接口要求离得很近。

自测三问（点开对答案）

1. 【优先考虑云服务】把举证责任反转到哪一方了？ —— **反转到了"要自建"的那一方**。旧顺序里，上云的人要证明自己划算；新顺序里，自建的人要说明为什么不能用云。**这个反转的直接效果，是省掉每次立项都要从头讨论一遍"要不要考虑云"的时间**——因为答案已经默认是"要考虑"了。 2. 为什么说 Society 5.0 是"需求侧"的力量，而 ISMAP 是"合规侧"的？ —— 因为**它们作用的环节不同**。Society 5.0 提出的是目标（数据要跨行业流动），它让"不上云"在业务上变得不可行；ISMAP 处理的是准入（安全怎么证明），它让"上云"在流程上变得可操作。**一个让你不得不选，一个让你选了之后少走弯路**——两个方向的力合起来，才把云推成默认选项。 3. 【老系统上云不好】和【老系统不该优先考虑云】，这两句话差在哪？ —— 差在判断的对象。前者在评判云这个东西，后者在评判**这次动作的必要性**。Demo 里那些 0 分项目，三条维度都指向"眼下没有非动不可的理由"——**问题不在云好不好，而在没有要动的理由时，任何搬迁都只是凭空多出一份风险**。搞清楚这一点，就不会把"不搬"误当成"云不行"。

☐ 下一节（2-2 云原生的真正含义：云原生、容器、微服务）