成本模型设计：资源定价模型、标签体系与分摊策略
成本模型是整个归因体系的基石。说白了，你得先知道「一个 CPU 核跑一小时到底值多少钱」，才能谈得上把账算清楚。我见过不少团队，一上来就搞分摊逻辑，结果底层定价拍脑袋，最后出来的数据连自己都不信。
这一章，我们就把地基打牢。从资源定价、标签设计，到分摊策略，一步步拆开揉碎了讲。
资源定价模型：给每份资源贴上价签
资源定价不是简单的「采购价除以总量」。你想想看，集群里有新机器、有老机器，有包年包月的预留实例，也有按量付费的竞价实例。如果统一定价，成本归因就失去了意义。
我个人习惯把资源定价分为三个层级：
- 采购成本价：实际账单金额，包含折扣、预留实例摊销。
- 内部结算价：在采购价基础上，加上运维、网络、管理 overhead。
- 市场参考价：对标公有云按量付费，用于评估「自建 vs 上云」的性价比。
下面这张图，是我常用的定价模型结构：
具体到每种资源，定价方式不太一样：
| 资源类型 | 定价单位 | 核心考量因素 | 我踩过的坑 |
|---|---|---|---|
| CPU | 核·小时 | CPU 型号差异、超分比、预留 vs 按量 | 不同代 CPU 混部时，按统一价算，高负载任务总抱怨不公平 |
| 内存 | GB·小时 | 内存类型（DDR4 vs DDR5）、预留量 vs 实际使用量 | 内存定价忽略 NUMA 架构，导致大数据任务性能归因偏差 |
| 存储 | GB·月 / IOPS·月 | 存储介质（HDD/SSD/NVMe）、副本数、访问频率 | 冷数据按热数据定价，业务方投诉存储成本虚高 |
| 网络 | GB 出流量 | 内网 vs 外网、跨 AZ 流量、CDN 回源 | 内网流量免费惯了，结果跨机房流量占了总成本的 30% |
标签体系设计：给成本打上可追溯的烙印
定价模型解决了「值多少钱」的问题。但钱花在谁身上了？这就需要标签体系来回答。
标签设计有个核心原则：谁受益，谁承担。我见过最糟糕的做法，是把所有成本打上一个「公共」标签，最后财务一看，公共成本占了 60%，等于没归因。
我习惯把标签分为三类：
- 资源标签：描述资源本身的属性，比如集群、机型、可用区。
- 业务标签：描述资源被谁使用，比如部门、项目、应用、环境（生产/测试）。
- 管理标签：描述资源的生命周期状态，比如创建人、创建时间、是否被标记为僵尸资源。
下面是一个实际的标签设计示例：
# 资源标签示例
cluster=production-hadoop
instance_type=ecs.g7.4xlarge
zone=cn-beijing-a
# 业务标签示例
department=data-platform
project=real-time-compute
application=flink-job-001
environment=production
# 管理标签示例
owner=zhangsan
created_at=2024-06-01
lifecycle=active
cost_center=COST-001标签的落地，通常有两种方式：
- 自动继承：资源创建时，从上层应用或集群自动继承标签。比如 Flink 作业提交时，自动打上 project=实时计算、owner=提交人。
- 手动补全：对于历史资源或无法自动打标的资源，通过定期扫描 + 人工确认的方式补全。
我个人更推荐自动继承。手动补全太容易遗漏了，而且一旦人员变动，标签就成了无主之地。
分摊策略制定：把总账拆成明细账
资源定价和标签都准备好了，最后一步是分摊。分摊解决的是「共享资源怎么分」的问题。
举个例子：一台物理机跑了 10 个容器，物理机本身有 CPU、内存、磁盘、网卡。如果按容器实际使用量分摊，那空闲时段怎么算？如果按容器申请量分摊，那超卖部分又怎么处理？
我常用的分摊策略有三种：
| 分摊策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 按实际用量分摊 | 在线业务、实时计算 | 公平，谁用得多谁付得多 | 需要高精度监控，空闲时段成本波动大 |
| 按申请量分摊 | 离线任务、批处理 | 成本稳定，便于预算 | 申请量不等于使用量，可能造成浪费 |
| 混合分摊 | 共享集群、混部场景 | 兼顾公平与稳定 | 规则复杂，需要反复调参 |
具体到每种共享资源，分摊逻辑也不太一样：
- 物理机/宿主机：按容器实际使用的 CPU 和内存比例分摊。注意要排除宿主机自身的开销（如操作系统、监控 agent）。
- 共享存储：按各业务的实际存储量和 IOPS 加权分摊。冷数据可以打折。
- 网络带宽：按出流量分摊。内网流量建议免费，跨机房流量按实际发生额分摊。
- 公共组件：如 DNS、NTP、监控系统，按各业务的资源规模比例分摊。
一个真实案例：我之前负责的一个数据平台，HDFS 存储成本一直居高不下。按实际用量分摊后，发现某个业务线存储了 80% 的冷数据，但只承担了 30% 的成本。后来我们引入了「冷热数据分层定价」，冷数据存储单价打 3 折，但读取时按实际 IO 收费。结果那个业务线主动清理了 60% 的冷数据，总存储成本下降了 40%。
分摊策略不是一成不变的。我建议每季度复盘一次，看看分摊规则是否还合理。尤其是业务线调整、集群扩容、新资源类型引入时，一定要重新审视分摊逻辑。
好了，成本模型的核心三件套——定价、标签、分摊——就讲到这里。这三样东西搭好了，后面的成本归因才有据可依。下一层，我们会聊聊数据采集和链路追踪，把成本数据真正「跑起来」。