📚 课程目录第3章成本指标设计

3、成本指标设计：核心指标定义与分摊模型

成本指标设计，说白了就是给每一分钱找到主人。我见过太多团队，资源用了不少，月底一算账，谁也说不出钱花在哪。嗯，这节课我们就来解决这个问题。

先聊最基础的。每个资源维度，我都习惯定义三个层级的指标：总量、使用量、浪费量。为什么是三个？因为只看使用率会骗人。

核心原则：所有指标必须可量化、可追溯、可归因。不能量化的指标，等于没定义。

CPU 是成本大头，也是最容易产生浪费的地方。我个人习惯这样定义：

避坑指南：我曾经遇到一个项目，CPU 平均使用率只有 30%，但峰值经常冲到 90%。如果只看平均值，你会觉得资源很充裕；但实际调度时，高峰期大量任务在排队。所以峰值/均值比这个指标，一定要加上。

内存比 CPU 更棘手。CPU 用不完可以等，内存用完了直接 OOM。我建议这样定义：

你想想看，很多开发为了省事，内存申请直接翻倍填。结果就是集群看起来满了，实际利用率不到一半。这个「申请溢出率」就是专门抓这种行为的。

存储成本是慢刀子割肉。我见过最夸张的一个案例，某团队 HDFS 上存了 3 年的临时数据，占了 40TB，从来没人清理。存储指标要这样设计：

注意：存储的副本数很容易被忽略。你以为用了 10TB，实际占用了 30TB（3副本）。成本计算时一定要把副本系数算进去，否则预算会严重偏差。

网络成本在云环境中尤其突出。跨 AZ、跨 Region 的数据传输，单价高得吓人。我习惯这样定义：

指标定义好了，接下来就是分账。成本分摊模型，说白了就是解决「这笔钱该谁出」的问题。我见过三种主流模型，各有适用场景。

最公平的方式。谁用了多少资源，就付多少钱。适合资源隔离做得好的场景。

# 分摊公式示例
租户A费用 = 租户A实际CPU核时 × CPU单价 
           + 租户A实际内存GB时 × 内存单价
           + 租户A实际存储GB月 × 存储单价

我的经验：这种模型看起来公平，但有个坑——公共资源没人买单。比如 HDFS NameNode、YARN ResourceManager 这些组件，是所有租户共享的。我建议单独拎出来，按比例分摊到各租户头上。

简单粗暴。适合业务相对稳定、资源使用波动不大的团队。

这种模型的好处是简单，坏处是容易养懒汉。业务线A明明可以优化资源，但因为固定比例，优化了也省不了钱，动力不足。

我个人最推荐的方式。把成本拆成三部分：

核心思路：基础成本保底，使用成本公平，惩罚成本倒逼优化。三管齐下，才能让每个团队都有动力去省钱。

指标和模型都定了，怎么把成本准确打到每个团队头上？靠标签。标签体系是成本可视化的地基，地基不稳，上面全是歪楼。

我总结了三要三不要：

这是我目前在用的标签体系，你可以直接参考：

曾经踩过的坑：我们一开始把标签设计成三层嵌套结构，比如「电商-搜索-算法」。结果查询成本时，SQL 写得巨复杂，而且一旦中间层改名，所有历史数据全对不上。后来改成扁平标签，用组合查询代替层级，清爽多了。

光有设计不行，得能落地。我建议按这个步骤来：

下面这张图，把本章的核心逻辑串起来了。从指标定义到分摊模型，再到标签体系，环环相扣。

嗯，到这里，成本指标设计的核心内容就讲完了。指标定义让你知道「看什么」，分摊模型让你知道「怎么分」，标签体系让你知道「分给谁」。三者配合，才能把成本账算清楚。