4.2 成本-收益分析
一句话
成本-收益分析的价值不在 “算出一个精确数字”，而在把假设摊在桌面上，让争议在决策之前暴露；算错的账都源于漏项，不源于除法。
成本是全口径：TCO 的六层
| 层 | 包含什么 | 常见占比 | 最容易漏的部分 |
|---|---|---|---|
| 资源 | 计算、存储、带宽、CDN、数据库 | 30–50% | 峰值冗余、跨可用区/跨区流量费 |
| 软件 | 许可、订阅、商业支持、镜像仓库 | 10–25% | 按量计费的隐性项（API 调用、日志量） |
| 人力·建设 | 研发人日、架构改造、迁移 | — | 迁移往往占总投入的 30–50% |
| 人力·运维 | on-call、升级、容量规划、救火 | 1 人 ≈ 40–60 万/年（全成本） | 这是最大且最常被漏的一项 |
| 合规 | 等保测评、渗透测试、审计、认证 | 等保三级 3–10 万/次，每年一次 | 复测、整改、驻场 |
| 退出 | 数据导出、重写、双跑过渡期 | 建设成本的 20–50% | 几乎从不计入 |
🔑 **一个自建系统真实的三年度成本，约等于云账单 × 3。**差的那些是人和退出成本——所以 “自建比买便宜” 这个结论，八成是账没算全。
把总量成本变成可比的 “单位成本”
| 口径 | 公式 | 用在哪 |
|---|---|---|
| 元/千次请求 | 月成本 ÷ (月请求量/1000) | 网关、无状态服务 |
| 元/订单 | 月成本 ÷ 月订单数 | 交易链路 |
| 元/TB/月 | 月成本 ÷ 存储量 | 日志、影像、数据湖 |
| 元/活跃用户/月 | 月成本 ÷ MAU | To C 产品 |
算一遍 (两套方案的真实贵贱)：
| 方案 | 月成本 | 月请求量 | 单位成本 |
|---|---|---|---|
| A | 1.0 万元 | 2 亿 | 0.05 元/千次 |
| B | 0.8 万元 | 1 亿 | 0.08 元/千次 |
B 的账单便宜 20%，单位成本却贵 60%——规模没到，便宜的方案其实更贵。
四种算法，各回答一个问题
| 方法 | 回答的问题 | 公式 | 优点 | 缺陷 |
|---|---|---|---|---|
| 回收期 | 多久回本 | 一次性投入 ÷ 年净收益 | 直观、抗不确定性 | 忽略回本之后的收益 |
| ROI | 收益率多少 | (总收益 − 总成本) ÷ 总成本 | 便于横向比较 | 对时间不敏感，长短期混算 |
| NPV | 值不值 | Σ 现金流 ÷ (1+r)^n | 考虑时间价值 | 折现率可以被人为调 |
| 单位经济 | 单笔赚不赚 | 单笔收入 − 单笔变动成本 | 可随规模外推 | 依赖稳定的成本结构 |
决策规则 (三条同时满足才推)：
- NPV > 0；
- 回收期 ≤ 18 个月 (超过就要问：这 18 个月里业务假设还成立吗)；
- 结论不依赖某一个乐观假设 (见下面的敏感性表)。
三年现金流：一张表说完全部
场景：一次性投入 40 万，年运行成本 30 万，年收益 60 万。
| 项 | Y0 | Y1 | Y2 | Y3 |
|---|---|---|---|---|
| 一次性投入 | −40 | 0 | 0 | 0 |
| 年运行成本 | 0 | −30 | −30 | −30 |
| 年收益 | 0 | +60 | +60 | +60 |
| 净现金流 | −40 | +30 | +30 | +30 |
| 累计 | −40 | −10 | +20 | +50 |
- 回收期 = 40 ÷ 30 ≈ 16 个月 (落在 Y1 内)；
- 三年累计 +50 万，折现后 (系数和 2.486) ≈ +34.6 万。
⚠️ 注意最后一行：**不看折现时 “+50 万”，折现后只剩 “+34.6 万”。**汇报时用哪个数，取决于你想让谁看见什么——但这两种数都要在文档里出现。
敏感性分析：让结论自己说话
对 “使用率、单价、人力成本” 三个假设各动 ±30%，看结论会不会翻。
| 项 | 悲观（−30%） | 中性 | 乐观（+30%） |
|---|---|---|---|
| 年收益（使用率 × 单价） | 42 万 | 60 万 | 78 万 |
| 年运行成本（人力为主） | 39 万 | 30 万 | 21 万 |
| 年净现金流 | 3 万 | 30 万 | 57 万 |
| 3 年 NPV（10%） | −32.5 万 | +34.6 万 | +102 万 |
🔑 **悲观情形下 NPV < 0 的项目，不是 “稳健的投资”，是 “押注”。**它仍然可以做，但决策记录里必须写明：“押的是使用率不低于 70%”。
自建 vs 买：交叉点在哪个数据量
场景：日志平台，日写入 500 GB。
| 方案 | 一次性 | 年成本 | 构成 |
|---|---|---|---|
| 自建 | 6 万（30 人日） | 28 万 | 资源 6 万 + 0.5 人力 20 万 + 监控接入 2 万 |
| 托管 | 0 | 0.5 元/GB/月 × 数据量 | 按量计费，含运维 |
交叉点 = 28 万 ÷ 12 ÷ 0.5 元/GB ≈ 46,700 GB/月 ≈ 45 TB/月
| 你的情况 | 选 |
|---|---|
| 日志量 < 45 TB/月 | 托管（自建省不下钱，还要养人） |
| 日志量 > 45 TB/月，且已有平台团队 | 自建（规模摊薄了人力） |
| 日志量 > 45 TB/月，但没有平台团队 | 先托管，等有了人再自建——否则省钱的是预算，赔进去的是 on-call |
💡 交叉点算法本身就是最好的说服工具：它把 “自建还是买” 从立场之争，变成 “我们的量在交叉点哪一侧” 的事实问题。
沉没成本：只算边际
已投入 200 万做到一半，继续还要 150 万；换方案要 120 万且效果相同。
| 错误算法 | 正确算法 |
|---|---|
| 已投 200 万 + 继续 150 万 = 350 万，换方案要"重新花 120 万"，所以继续 | 前方：继续 +150 万 vs 换方案 +120 万 → 换；那 200 万在两种情况下都收不回来 |
判断口诀：把已经花掉的钱从表里删掉，只看 “从现在起，每条路还要花多少、还能拿到多少”。删掉之后结论变了，说明原来的决策是被沉没成本绑架的。
代码：把“回本周期”算出来
# 净现值与回收期（简化模型，rate 为年折现率）
def npv(cashflows, rate=0.1):
return sum(cf / (1 + rate) ** t for t, cf in enumerate(cashflows))
def payback(cashflows):
cum = 0
for t, cf in enumerate(cashflows):
cum += cf
if cum >= 0: return t # 第几年回本
return None
# 例：投入 300（第 0 年），之后每年净收益 120
flows = [-300, 120, 130, 140, 150]
print("NPV:", round(npv(flows), 1), "回收期:", payback(flows), "年")
判据：NPV > 0 且回收期 < 可接受年限才值得投；只算 “总收益” 不算折现，会高估长期项目。
反模式
| 反模式 | 后果 |
|---|---|
| 只算云账单，不算人力 | 自建方案永远显得便宜，第二年运维把人耗光 |
| 用平均负载算容量成本 | 峰值按平均的 3 倍准备，预算必然超支或必然不够 |
| 收益按乐观、成本按悲观 | 结论预设立场，评审变成表演 |
| 忽略退出成本 | 换供应商时才发现迁移要 6 个月，锁定成立 |
| 把沉没成本当继续的理由 | 越投越深，直到无法止损 |
| 用 ROI 高低排序所有项目 | 避险类项目 ROI 天生难看，永远排最后，直到出事 |
| 折现率随手填 10% | 折现率 5% 与 15% 能让同一个项目一个通过一个否决 |
三条铁律
🔑 **成本算全口径，收益算下限。**成本漏一项，结论就偏一次；收益取上限，风险就多一层。
🔑 **任何超过 18 个月回本的技术投入，都要单独回答 “这期间业务假设变了怎么办”。**技术项目的失败，多数不是做不出来，是做出来时需求没了。
🔑 **算不清的时候，把不确定性写进决策记录，而不是把数字编圆。**一份写着 “使用率低于 60% 则本项目不成立” 的决策记录，比一个精确到小数点的 ROI 有用得多。
自检
Q1 团队报 “自建比买便宜 40%，三年省 200 万”。你最该追问哪三件事？
▸ 答案：① 人力算进去了吗 (1 个运维 40–60 万/年，三年就是 120–180 万，常常正好抵掉 “省下的 200 万”)；② 迁移与退出成本算了吗 (建设成本的 20–50%，且换回来还要再花一次)；③ 省下的钱会真的从预算里消失吗 (如果资源是包年已付、人力是现有编制，账面上的 “省” 不产生现金流)。
Q2 两个方案：A 月账单 1 万、月请求 2 亿；B 月账单 8000、月请求 1 亿。哪个便宜？
▸ 答案：A 的单位成本更低 (0.05 元/千次 vs 0.08 元/千次)。总账单便宜不等于便宜——比价必须换算到同一单位 (元/千次请求、元/订单)。只有当你的量确实只有 1 亿且短期不会涨，B 的总支出才更少。
Q3 项目已投入 200 万，继续要 150 万，换方案要 120 万。有人说 “都投 200 万了，不能半途而废”。怎么回？
▸ 答案：把 200 万从表里删掉再比——继续 +150 万 vs 换方案 +120 万，换方案省 30 万且效果相同，所以换。沉没成本的正确用法是 “复盘时解释当初为什么这么决策”，不是 “决策时给继续加权重”。
Q4 同一个项目，用 NPV 算是正的，用回收期算是 26 个月。推不推？
▸ 答案：关键不在数字，在那个 26 个月。超过 18 个月回本意味着你要在两年多里持续为一个尚未验证的假设付费。要么把范围缩到 “18 个月内能回本的那部分” 先做，要么在决策记录里写明 “押的是两年内业务量增长 3 倍”，并设置阶段校验点 (如 6 个月时复核使用率)。
Q5 避险类项目 (比如多活改造) 用 ROI 排序永远垫底，怎么办？
▸ 答案：换指标，不要换算法。避险类用 “年期望损失 EL = P × L” 排序，和增收/降本类分开排队；两类各有一份预算池。把避险塞进 ROI 排序，等价于系统性地推迟所有 “不出事就看不见价值” 的投入，直到出一次大事。
Q6 为什么 “折现” 这件事在技术决策里经常被跳过，却必须做？
▸ 答案：因为技术收益大多后置 (先投入 6 个月，收益从第 7 个月开始)，而成本前置。不折现就等于假设 “三年后的一块钱等于今天的一块钱”。折现率 10% 时三年系数和是 2.486 而不是 3——直接差 17%，足以让一个边缘项目的结论翻转。