7-2 将希望装在云上的系统明确化

📄 一句话概括

上一节把导入变成了四道选择题，而第一题（这个系统要不要上云）在现实里根本没法一句话回答——因为公司不是【一个系统】，而是几十上百个系统。所以这一步要做的，是先把家底列成一张表，再给每一个系统单独判一次：原样搬、小改后搬、重写、换掉、关掉，还是留在原地。教材把这个动作叫【系统企划工程】，而它的产物就是一份清单。

📝 本节和前面几节的关系

它把 7-1 的第一道选择题从【一个系统】展开成了【一整个系统群】——上一节的账（峰值均值比）是算给单个负载的，这一节要给每个负载都算一遍，还要排出一个先后。

它同时呼应了 2-3 的【混合云】：盘点之后总会剩下几个【不该搬】的系统，正是它们构成了混合云里【留在本地】的那一半。

一、先盘点，再搬迁

这一步最容易被跳过，因为它的动作看起来【什么也没做】——不买服务、不写代码、不搭环境，就是坐下来列一张表。

但它防的是整个项目最容易翻车的一件事：把【我们有一套 ERP】当成【我们有一个系统】。

现实是：那套 ERP 背后可能挂着报表系统、EDI 对接、一个十年前没人碰过的打印服务、还有一个只有财务在用的导出脚本。你要是按【一个系统】去规划，等到搬的时候，这四个附件会一个一个跳出来。

所以盘点的产出是一份具体的清单，每个系统一行，至少要写清四件事：

要写清什么	为什么必须写
它是什么、谁在用	决定它能不能被关掉
它跟谁有连接	决定它能不能单独搬
它的负载形状	决定它值不值得上云（沿用 7-1 的账）
它的合规与延迟要求	决定它能不能上公有云

四栏填完，每个系统的【该走哪条路】基本就自己浮出来了。

二、动手 Demo：60 个系统的 6R 盘点

看到什么算成功：

==================================================================================================
【Demo 2】把希望装在云上的系统明确化：系统企划工程
==================================================================================================

  【一】先盘点，再搬迁

  一家公司有 60 个业务系统。
  不要先问【哪些能上云】，先问【每个系统该走哪条路】。

  6R          含义                系统数    占比      说明
  --------------------------------------------------------------------------------------------
  Retire      直接关掉            9         15.0%     没人用了，还在花维护费
  Repurchase  换成 SaaS           6         10.0%     换成现成产品
  Rehost      原样搬迁            18        30.0%     最快，但拿不到弹性
  Replatform  小改后再搬          15        25.0%     换托管服务，性价比高
  Refactor    重写成云原生        8         13.3%     投入大，长期收益大
  Retain      留在本地            4         6.7%      延迟 / 合规，本就不该搬
  合计                            60        100.0%

  【二】两个最常被跳过的 R

    Retire（关掉）：9 个系统早没人用了，却还在续维护费
      假设每个一年维护 4 万元 → 一年直接省下 36 万元
      这是全表里【最快见效】的一笔，但盘点时它最容易被跳过。

    Retain（留在本地）：4 个系统留在机房
      它们不是【搬迁失败】，而是【一开始就不该搬】——
      延迟敏感 / 合规约束 / 刚升级过，三条里占一条就够了。

  【三】如果一律 Rehost，会丢掉什么

    把 60 个系统统统原样搬：
      能关掉的 9 个继续养着，还把技术债原样搬进云
      该换 SaaS 的 6 个自己维护，放弃了现成产品
      该重构的 8 个原样搬，拿不到弹性，账单反而涨了

    → 最短的计划，往往不是最好的计划。
      盘点这一步的价值，就是【不让最省事的那个答案变成唯一答案】。

读结果：

注意表里的分布。真正【原样搬】的只有 30%，其余七成各有各的去处。如果规划时默认【全都 Rehost】，等于把一个七成不同的决定，压成了同一个动作。 这正是盘点要防的事。
【Retire】那一行是整张表里最反直觉的——9 个系统（15%）直接关掉。它的意义不只是省钱，更是让后面的工作量少掉六分之一。而且关掉是唯一一个【先做完再搬】都来得及的动作，所以盘点时它该排在第一位。
【Retain】那一行容易被误读成失败。Demo 特意写明了：它们不是搬不动，而是一开始就不该搬。 一条【延迟敏感】就足以否决上云——这类系统留在本地是算出来的结论，不是妥协。

三、两个最常被跳过的 R

6R 里有四个是【往前搬】（Rehost、Replatform、Refactor、Repurchase），另外两个是【不搬】——而恰恰是这两个，在真实的盘点里最容易被划掉。

为什么会被跳过：

被跳过的 R	跳过的理由	代价
Retire	关系统要走流程、要签字	白交好几年维护费
Retain	【既然要上云了，怎么能留着】	硬搬一个不该搬的，两头不讨好

两行的共同点：它们都不是技术判断，而是心理判断。 关掉一个系统要有人承担责任（万一还有人用呢？），留下一个系统看起来像没完成作业。所以这两个 R 能不能落地，考的是项目负责人的位置和权限，不是技术能力。

而这也是盘点必须由【懂业务】的人参与的原因：只有业务方才能拍板【这个没人用了】，也只有业务方才能确认【这个必须留在本地】。 纯技术视角盘点，最后大概率会得出【全都 Rehost】。

四、这份清单，就是【企划】的产物

【系统企划工程】这个名字听起来很大，但它的产物就是上面那张表——一份【每个系统走哪条路】的清单。

它之所以叫【工程】，是因为它要同时满足三个约束：

预算约束：Refactor 很贵，60 个系统不可能全重构——表里的分布本身就是预算的分配。
依赖约束：被很多系统依赖的，要排在后面搬（先搬的，往往是没有上游依赖的小系统）。
风险约束：越关键的越要谨慎——上线窗口、回滚方案，都得提前留出来。

这三个约束合起来决定了搬的顺序。所以清单不是终点，它还是【排期表】的底稿——先关掉能关的（Retire），再搬简单的（Rehost、Repurchase），最后动复杂的（Replatform、Refactor）。

至于【哪些该先做】、依据是什么，就是下一节要接上的事。

30 秒实验

打开你电脑上的【设置 - 应用】（或者手机上的应用列表），做一件事：

数一数你装了多少个应用，然后分成三堆：

常用（每周至少打开一次）
偶尔（一个月都开不了一次，但还舍不得删）
早就忘了（看到才想起来装过）

做完你多半会发现第三堆最大。 这就是本节那张 60 个系统表在你个人设备上的缩影——15% 的【Retire】，在哪儿都成立。而差别在于：个人删掉一个应用只省一点空间，公司关掉一个系统省下的是每年真金白银的维护费。

常见误区

错误：盘点就是列个清单，谁列都行。——纠正：清单可以谁都能列，但判断必须业务方来下。本节第三段说过，Retire 和 Retain 这两个决定考的不是技术，而是【谁有权拍板】——一个系统没人用了，只有业务方敢签字；一个系统必须留下，只有业务方知道原因。 技术团队能做的是提供事实（谁在访问、连接了谁、负载多大），决定要业务方做。否则清单列得再漂亮，最后还是会滑回【全都 Rehost】。
错误：Retain 就是【暂时没搬】，早晚要搬。——纠正：Retain 是一个终态，不是一个过渡态。它针对的是那些云在原理上就不合适的负载——延迟要求以毫秒计、合规要求数据不出楼、或者刚完成一笔大升级。对这类系统，【早晚要搬】这个想法本身才是风险：它会让团队反复投入评估成本，却永远得不到收益。正确做法是给它写一个明确的复核日期（比如两年后重看一次），到期之前不再讨论它。
错误：先把容易搬的搬完，难的以后再说。——纠正：顺序本身就是一个决策，不能只看难易。正确的排序要同时看三件事：依赖关系（下游没搬完，上游搬了也没用）、业务影响（关键系统要在窗口期搬）、参考价值（第一批搬的会变成后面的模板，所以最好挑【有代表性但不致命】的）。只看难易，容易搬完一堆边角系统，核心的一直没动——而清单里真正有价值的信息，恰恰在难的那几个里。
错误：只要搬过去了，就说明盘点做对了。——纠正：盘点的目的是让每个系统走对它该走的路，而不是让所有系统都上路。如果一次盘点之后，15% 被关掉、7% 留在本地，那这两笔恰恰是盘点最有价值的部分——关掉的省了钱，留下的避免了折腾。 反过来，如果盘点结果是【100% 都要上云】，那多半不是盘点做得好，而是盘点被跳过了。

自测三问（点开对答案）

1. 为什么【Retire】这一行应该排在盘点的最前面处理？ —— 因为**它是唯一一个【先做也不亏】的动作**。其他五条路（搬、改、重构、换、留）**都需要先做评估、再做规划、最后执行**，而【关掉】不需要——**关掉之后，连评估都不用做了**。更实际的一点是：**关掉一个系统能让后面的总工作量直接变小**（Demo 里是少掉 15%）。**如果把它留到最后，那这段时间的维护费照付，盘点也照做，纯属重复劳动。** 所以正确顺序是：**能关的先关，再谈别的。** 2. 为什么说【Retain 是一个终态，不是过渡态】？ —— 因为**它针对的原因不会随时间消失**。延迟敏感、合规约束、刚升级过——**这三条要么是物理规律，要么是规则要求，要么是沉没成本**，都不是【等一等就好了】的问题。**把它当成过渡态，会让团队反复评估、反复延期，却永远推不出结论。** 反过来，**把它当终态并写一个复核日期**，就可以把它从【待办】里正式划掉——**这本身就是节省资源。** 这也是为什么它和 Retire 一样，考的是【敢不敢拍板】，而不是【技术行不行】。 3. 为什么【先搬容易的】这个看似稳妥的顺序，反而是错的？ —— 因为**它把一个多维度的决策压成了单维度**。搬的顺序至少要同时满足三个约束：**依赖（下游先于上游）、业务影响（关键系统挑窗口）、参考价值（第一批当模板）**。而【只看难易】只优化了其中一个，结果常常是：**边角料先搬完了，核心系统因为【太难】一直滞留**——而**核心系统恰恰是上云收益最大、也最需要被验证的那部分**。所以正确的做法是**先挑【有代表性但不致命】的几个当模板**，再用它们去啃难的，而不是**从头到尾挑最软的捏。**

☐ 下一节（7-3 与IT战略保持一致性：IT 策略）