3-12 云计算中需要长期支出的费用

📄 一句话概括

云的费用不只有"用了多少付多少"——订阅与承诺、数据出口、支持服务、删不掉的卷与快照、以及人，这五类都是长期项；一年 600 万云支出里，按行业平均有 27% 是浪费（162 万），优化到 12% 能省下 90 万；而真正最大的一块是人工成本——3.5 人变 1.2 人，一年省 69 万。

📝 本节和前面几节的关系

上一节（3-11）解决的是"同样用量怎么买更省"。这一节是它的反面：买法对了，钱还是可能漏——漏在那些不属于"用量"的地方。

教材把它放在这里，是因为 3-11 到 3-12 合起来才构成完整的成本观：一个讲"怎么降低单价"，一个讲"怎么控制总量"。而这一节还顺带回收了前面几节埋下的两条线——3-4 说的"账单归开发者"、3-7 说的"账单就是资产清单"，它们的意义都在这一节兑现。

一、云上不只有"用多少付多少"

长期支出项	说明
订阅与承诺费	承诺了就每月都要付，用不用都付
数据出口费	数据搬出去、跨区走，都要钱
支持服务费	要 SLA 承诺往往得买支持档，常按消费比例收
存储与快照沉淀	删了实例，卷和快照还在计费
人的成本	会用云的人、能省钱的治理岗

这五行有个共同点：它们都不是"业务用掉的"，而是"用云这件事本身的持有成本"。

订阅与承诺费：3-11 里那个"省 40% 的承诺"，另一面就是每月都要付，用不用都付。所以它是折扣还是负担，取决于你是否真的用满了。
数据出口费：这一项最容易被忽略，因为它不体现在"资源用量"里。数据在同一个区域内流动通常便宜甚至免费，但一旦跨区域、跨云、或者流向互联网，就开始计价。而很多架构在初期根本不考虑这件事，等到流量涨起来，账单上会冒出一行陌生的费用。
支持服务费：想要 SLA 承诺，往往要先买支持档——而支持档常按你总消费的一定比例收取。所以"拿到 SLA"这件事本身是有成本的，这一点在 2-11 讲 SLA 时也提到过。
存储与快照沉淀：这是"删了实例不等于删干净"的具体表现。实例终止后，挂在上面的卷、做过的快照都可能继续存在并计费。它们不会自己消失。
人的成本：单独说，见第三节。

二、一年 600 万，浪费了多少

行业调查给出的数字是：云支出平均有 27% 是浪费的（四年前是 32%，说明优化手段确实有效，但差距还很大）。同时，84% 的 IT 负责人把云成本管理列为首要挑战——排在安全之前，而只有 59% 的组织真正建立了对应的治理流程。

把这个比例套到"一年 600 万"上：

项目	金额	说明
一年云支出	600.0 万
按平均浪费率 27% 计	162.0 万	没人管的闲置与超配
优化到 12% 之后	72.0 万	省下 90.0 万

这 90 万是怎么来的？不是靠砍业务，而是靠四种动作：

清掉闲置：没挂载的卷、没用的弹性 IP、跑着但没人用的实例。这些是纯粹的漏，占的比例最大。
按实际用量调规格：按"猜的峰值"买机器，是最常见的浪费来源。正确做法是看一段时间内的真实 CPU、内存、IO，再往下调一到两档。
非生产环境按工时开关：开发、测试、预发这些环境，晚上和周末大多不需要开着。仅这一项就能砍掉它们大约三分之二的运行时间。
存储分层：把不常访问的数据挪到更便宜的存储层，长期保留的数据走归档。存储的费用是慢慢涨上去的，很少有人主动回头看。

注意顺序：这四种动作都属于"先清干净、再谈折扣"。先优化规格、再买承诺——因为给一个超配的实例买承诺，等于用折扣价长期锁定一个本不该存在的浪费。 这是这一节最实用的一条操作纪律。

三、人工成本才是最大的一块

人力投入	自建	云上
硬件与机房运维	2.0 人	0
系统与中间件	1.5 人	0.2 人
云资源与成本治理	0	1.0 人
合计	3.5 人	1.2 人
按 30 万/人/年折算	105.0 万/年	36.0 万/年

一年省下 69.0 万——这个数字比前面那 90 万浪费更容易被忽略，因为它不写在账单里。

这张表有三个地方要看清：

自建那 3.5 人里，有 2 人是"守机器"——机房、硬件、故障。这部分在云上变成 0，是云最实在的一笔节省。
云上多了 1.0 人是"管资源与成本"——这是一笔新增的人力，而且是必要的。前面那 27% 的浪费之所以存在，很大程度就是因为没人负责这件事。换句话说：这 1 个人不是成本，是那 90 万的来源。
"系统与中间件"从 1.5 人变成 0.2 人——这部分的变化说明云确实降低了日常维护的人力需求，但没有归零，因为仍要有人懂它。

把这张表和上一张放在一起看，就得到了本节完整的结论：

云省下的是"守硬件"和"守机器"的人；但要多花一个人去管钱——而这一个人管得好，能省下的远比他的工资多。

四、动手 Demo：浪费率与人力账

# 一年 600 万云支出，优化前后（单位：万元）
spend = 600.0
waste = spend * 0.27
after = spend * 0.12
print("一年云支出 %.1f 万" % spend)
print("按平均浪费率 27%% 计：%.1f 万" % waste)
print("优化到 12%% 之后：%.1f 万，省下 %.1f 万" % (after, waste - after))

实跑输出：

==================================================================================================
D12 云计算中需要长期支出的费用：账单里那些不会自己消失的行
==================================================================================================
  【一】云上并不只有【用多少付多少】

  长期支出项                说明
  ----------------------------------------------------------------------------------------
  订阅与承诺费              承诺了就每月都要付，用不用都付
  数据出口费                数据搬出去、跨区走，都要钱
  支持服务费                要 SLA 承诺往往得买支持档，常按消费比例收
  存储与快照沉淀            删了实例，卷和快照还在计费
  人的成本                  会用云的人、能省钱的治理岗

  【二】一年 600 万云支出，浪费了多少（2026 现状）

  项目                          金额            说明
  ----------------------------------------------------------------------------------
  一年云支出                    600.0 万
  按平均浪费率 27% 计           162.0 万        没人管的闲置与超配
  优化到 12% 之后               72.0 万         省下 90.0 万

     行业调查：84% 的 IT 负责人把云成本管理列为头号挑战（排在安全之前），
     但只有 59% 的组织真正建立了成本治理流程。

  【三】人工成本才是最大的一块

  人力投入                    自建            云上
  ----------------------------------------------------------------------
  硬件与机房运维              2.0 人          0
  系统与中间件                1.5 人          0.2 人
  云资源与成本治理            0               1.0 人
  ----------------------------------------------------------------------
  合计                        3.5 人          1.2 人
  按 30 万/人/年折算          105.0 万/年     36.0 万/年

  【四】一句话
     云省下的是【买硬件】和【守机器】的钱，
     但要多花一笔【盯着账单】的钱——这笔钱不花，前面省的会漏回去。

读这个输出：第二段那三个数字的关系很关键——27% 和 12% 都不是"必然"，它们是"有没有人管"的差别。中间那句调查说明的正是这件事：工具都有（各家的账单分析、资源推荐、预算告警都做得挺全），但多数的组织没有"谁负责按这些提示去动手"这个环节。

第三段则把这件事拉回到人身上：云上新增的那 1.0 个"管资源与成本"的人，就是 27% 变成 12% 的原因。 这里有一个非常实际的算法：这个岗位的年成本（假设 30 万）如果换来 90 万的节省，它的投入产出比是 1:3。 这也是为什么这项职能在 2026 年从"可选的优化"变成了"常设的角色"。

五、⚠️ 2026 现状

"管云成本"这件事在 2026 年已经成了一门专门的实践。它把财务、工程、运营三方拉到一起，按月度节奏看费用、找原因、定动作，行业里采用的机构比例已经接近六成。这说明它从"临时救火"变成了"固定流程"。
浪费的成分发生了变化。四年前的最大来源是"闲置的普通实例"，2026 年新增的最大一块变成了"闲置的 GPU 预留"——因为 AI 负载需要提前锁定算力资源，一旦项目延期或调整，那部分预留就成了最贵的一类闲置。结论：AI 负载需要单独一套成本管理方式，不能套用普通负载的做法。
"预防"比"清理"更重要了。业内的共识是：如果不在部署流程里加约束（比如打标签的强制要求、资源规格的准入限制），那清理就会变成"每半年重来一次"的循环——因为清理完之后，新的浪费会继续被创建出来。所以真正的解法是把成本判断嵌进日常的技术决策里，而不是定期做一次专项治理。
最能反映治理水平的其实是"单位成本"。业内推荐每月看三个指标：承诺覆盖率、承诺利用率、单位成本（比如每客户、每笔交易、每个功能的成本）。其中"单位成本在下降"才说明增长是有效的——而只盯总支出是不够的：总支出随业务增长而上升是正常的。

30 秒实验

打开你的云账单，只做一件事：找那几行你看着陌生、或者想不起来对应哪个业务的费用。

先按"从大到小"排一遍，看前五行是哪几类。
对每一行问一句：这个资源现在还在用吗？谁在用？

大概率你会找到至少一项"已经不用的东西还在付费"——可能是一个没删的快照、一块没挂载的卷、一个测试环境留下的实例。这就是 27% 里属于你的那一部分，而且它不需要任何工具就能找出来。

常见误区

错误：云是按量的，所以不会浪费。——纠正："按量"只保证你不为"没开的东西"付钱，它不保证你开的规格是对的。Demo 里那 27% 的浪费，绝大部分不是"没用的资源"，而是"用途对的资源买大了"——按猜的峰值买机器、存储不分层、非生产环境 24 小时开着。这些都是"按量付费"照样会付的钱。
错误：省钱就是换个更便宜的服务商或买更多折扣。——纠正：顺序错了。正确的顺序是先把规格调对、把闲置清掉，再去买承诺。因为给一个超配的实例买承诺，等于用折扣价锁定了这笔浪费——你不但没有省，反而把本该可以改的地方长期固定下来了。先治理、后折扣，这条顺序不能颠倒。
错误：新增一个"管成本"的岗位是增加开销。——纠正：它的投入产出比通常很高。Demo 里的算法是：一个人 30 万，换 90 万的节省，比例是 1:3。而且这还是保守估计——因为如果没有这个人，浪费会逐年累积（新增的资源会继续按老习惯配置）。所以它不是成本项，是一项收益明确的投入。
错误：单位成本不重要，看总支出就够了。——纠正：总支出上升是正常的——业务在增长，费用当然涨。真正要判断"增长是不是健康的"，看的是单位成本：每客户成本、每笔交易成本、每个功能的成本。如果单位成本在下降，说明规模效应在起作用；如果总支出涨、单位成本也涨，那说明效率在变差，钱花得没换来相应的业务量。

自测三问（点开对答案）

1. 为什么"先优化规格、再买承诺"这个顺序不能颠倒？ —— 因为**承诺是长期的**——一旦承诺，那个规格就被固定下来了。如果承诺之前的规格是超配的，那么**你用一个折后价长期买了一个本不该存在的容量**，等于把一笔可以消除的浪费锁定成了一笔三年的固定支出。**正确顺序是先看清楚真实用量、调到合适的规格、跑一段时间确认稳定，再对那个已经调好的基线做承诺。** 2. 云上新增的那 1.0 个"管资源与成本"的人，为什么不算成本增加？ —— 因为**他对应的是那 27% 到 12% 的差距**。Demo 里这段差距值 90 万，而一个人的年成本按 30 万算——**投入产出比约 1:3**。更关键的是，**这项职能的价值不需要新技术、不需要重构，它省下的每一分钱都是净利**。所以把它看成一个"职位"，不如看成一个"收益率较高的投入"。 3. 为什么说 2026 年的浪费来源和四年前不一样了？ —— 因为**负载的类型变了**。四年前最大的浪费是"普通实例买大了、闲置了"；**2026 年最大的新增来源是"为 AI 预留的 GPU 资源闲置"**——这类资源需要提前锁定（否则拿不到），**但项目一旦延期或调整方向，那部分预留就变成了最贵的一种闲置**。**所以成本优化的对象也要跟着变：普通负载看规格和开关，AI 负载看预留与实际使用的匹配度。**

☐ 下一节（3-13 最新技术的运用：Hadoop、机器学习）