月底账单出来，财务问“这个月为什么涨了 18%”，没人认领，最后按人头平摊：人多的团队骂不公平，人少的团队照旧浪费。这不是财务问题，是成本在系统里没有负责人。
分摊要解决的真问题只有一个：让人看见自己多开一台机器的边际成本，在决策发生那一刻把浪费掐掉。它不追求把账算到分——归因到 5% 精度足以改变行为，精确到 0.5% 却没人看，等于白做。
1. 目标从"算准"改成"改行为"
| 目标 | 做法 | 结果 |
|---|---|---|
| 算准账 | 100% 归因、逐笔对账 | 成本高、周期长、行为不变 |
| 改行为 | 80% 归因 + 高频可见 + 绑决策点 | 闲置与过量当月被削掉 |
| 只做展示 | 群里发一张饼图 | 第一周有人看，第三周没人看 |
判据：落地三个月后，如果没有任何团队因为看到账单改过配置，方案就是失败的。
2. 三种口径与各自的激励扭曲
| 口径 | 计算方式 | 优点 | 扭曲 |
|---|---|---|---|
| 按用量 | 标签聚合实际消耗 | 边际成本可见 | 只能估算，估算被当精确值 |
| 按预留 | 按配额或预留份额切 | 稳定可预算 | 申请即占坑，空转不痛 |
| 按人头 | 总账 ÷ 人数 | 零维护 | 多用不用，账单一样 |
三种可并存，但必须指定一个决策口径：主机与存储按用量，预留折扣按份额返还，监控与 CI 按人头。
allocation:
- resource: compute.instance
basis: usage # 运行小时 × 单价
decision: true
- resource: storage.object
basis: usage
decision: true
- resource: platform.shared # 监控、日志、CI、镜像仓库
basis: headcount
decision: false
decision: false 的项不要放团队首页第一屏，否则注意力会从"我能改的"漂到"我改不了的"。
3. 共享资源：三种解法与代价
共享资源是唯一真正难的部分，特征是没有天然的消费者标识。
| 资源 | 为什么难 | 常见错法 |
|---|---|---|
| 网络出口/跨区流量 | 网关汇聚，源端可能是共享代理 | 按 VPC 平摊 |
| 日志与指标平台 | 写入方多、单条极便宜但总量巨大 | 按服务数均摊 |
| 共享数据库主库 | 一个实例跑几十库，CPU/IO 无法切 | 按库数量均摊 |
A 按调用分摊：网关或代理层记 (consumer, bytes|queries)，按计量切。
代价：链路上加计量点；采样率必须声明，别让估算冒充精确。
B 按容量分摊：只对可持久化度量（GB·月、索引条数、留存天数）收费。
代价：抓不住“查询把 CPU 打满”这类动态成本。
C 内部价 + 配额：给单价与配额，超额要申请，配额即预算。
代价：价目表要人维护；价格失真会扭曲技术选型。
判据是消耗是否由消费者单方面决定：能单方面决定的（日志量、查询量、缓存大小）用 A 或 C，不能的（共享主库容量由 DBA 定）用 B，余量进不可归因。内部价的坑是价格锚定：单价一公布，团队就拿它做选型，而真实成本含人力与冗余。
4. 标签：谁打、打不准、漏了怎么办
标签是分摊的地基，腐化有三种。谁打：建资源时忘打、或从模板复制别人的标签——创建入口必填加模板继承。打不准：一个资源挂两个团队、改名后没跟着改——值来自受控清单，不接受自由文本。漏了：无标签资源进不了任何团队——单列“未归属”按月公示，不平摊兜底。
{ "tag_policy": {
"required": ["cost_center", "service", "env", "owner"],
"cost_center": { "source": "controlled_list", "change_via": "pr" },
"unlabeled_policy": "show_in_unattributed_pool",
"enforcement": "warn_then_block_create" } }
enforcement 先 warn 两周补存量再切 block，否则会挡住紧急扩容。
5. 不可归因占比是最诚实的指标
分摊总会剩下一部分钱说不清是谁的：共享控制面、跨团队实验、历史遗留、最低消费。这个比例比归因精度更有信息量。
| 占比 | 含义 | 动作 |
|---|---|---|
| <5% | 标签与计量已成熟 | 盯趋势不上升 |
| 5%–15% | 正常区间，共享占比合理 | 确认大头来源 |
| 15%–30% | 存在黑洞 | 找 top3 处置 |
| >30% | 体系尚未成立 | 先做标签清单 |
追求“零不可归因”是常见的错误目标：它逼团队硬套标签，产生假归因，账单反而不可信。宁可留 10% 明码标价的公共开销，也不要 100% 里混 30% 的猜测。
6. 预留与弹性的账怎么落到人头上
预留实例与承诺用量带来折扣，也带来归属难题：折扣按承诺买，用量却是波动的。
按用量返还：用多少返多少，未用掉进公共池 → 波动大、团队多
按份额返还：谁申请预留谁拿折扣 → 申请制、可预测
不返还 ：平台持预留，按折后单价计费 → 平台化高、团队不管采购
第三种最省事，代价是团队看不见预留浪费；折中是把预留覆盖率与利用率作平台 KPI 公示。责任要落在能改变它的人身上。
弹性用量的坑在计量窗口：按秒计费、按小时聚合、按天出账，同一团队在三个报表里得到三个数字——对外只发布一个粒度。
7. 可见性的频率决定行为是否改变
| 频率 | 粒度 | 效果 |
|---|---|---|
| 月 | 团队总额 | 只能事后解释 |
| 周 | 服务 × 资源类型 | 能发现多开的机器 |
| 日 | 服务 × 类型 × 环境 | 能关联到发布与扩容 |
| 实时 | 单资源 | 噪声大，只适合排障 |
判据：可见周期要短于“犯错到后悔”的周期。误开 20 台机器若一个月后才上账单，错误已成既成事实；日粒度并与发布、扩缩容对齐最划算。
配套是变更标注——把发布、扩容、批量任务画在成本曲线上，否则只能看出“涨了”，看不出“为什么涨”。
8. 三类成本告警与误报
alerts:
- name: budget_burn
expr: month_to_date_cost > budget * 0.8
for: 1d # 流程提醒，需指名到人
- name: spike
expr: daily_cost > avg_over_time(daily_cost[14d]) * 1.8
for: 2h # 附 top5 资源变化
- name: slope
expr: deriv(daily_cost[7d]) > 0
and predict_linear(daily_cost[14d], 30d) > budget
for: 6h # 动作窗口最长
斜率告警价值最高（窗口最长）；突增最易误报（批处理、月末结算、备份），须排除已知周期任务；预算告警不落到人就只是群消息。
误报来自周期任务、数据迁移、促销、预留到期；治理不是调阈值，而是把这些模式写进运营日历。
9. 单位成本：唯一能跨时间比较的指标
单位成本才能回答“效率有没有变好”，但它比总额更容易被误读：失真条件要写在指标旁边。
| 指标 | 定义 | 失真条件 |
|---|---|---|
| 每千请求成本 | 总成本 ÷ 请求千数 | 大小请求混算 |
| 每 GB 存储成本 | 存储成本 ÷ 有效数据量 | 副本进分母则虚低 |
| 每活跃用户成本 | 总成本 ÷ 活跃用户 | 活跃定义变更 |
| 每单位业务量成本 | 总成本 ÷ 业务口径单位 | 口径本身变化 |
10. 省钱的顺序：闲置 → 规格 → 架构
1 闲置回收（当天，零风险）：未挂载磁盘、无流量 LB、N 天无读对象、停止未释放实例、孤儿快照。
2 规格调整（周级）：CPU/内存长期低于阈值则降配；存储降档；非生产按时段关机。
3 架构变更（月级、有风险）：加缓存、批量化、冷热分层、换引擎、改调用链。
顺序错：先做架构改造（三个月，收益 15%），闲置资源却占 20%。判据是先做一周内能完成、且不碰任何 SLA 的那一档。
11. 成本与可靠性的冲突怎么裁
| 场景 | 省钱做法 | 代价 | 裁决依据 |
|---|---|---|---|
| 多可用区 | 退单可用区 | 故障域扩大 | RTO/RPO 承诺 |
| 备份保留 | 90 天缩到 7 天 | 长尾不可恢复 | 合规与恢复点 |
| 日志留存 | 30 天缩到 3 天 | 取证能力下降 | 排障回溯窗口 |
| 竞价实例 | 跑在线服务 | 容量抖动 | 只允许无状态负载 |
| 监控采样 | 降到 1% | 长尾看不见 | P99 诊断需求 |
只有一条原则：优化对象是没有人为它负责的冗余，不是写在承诺里的冗余；没人说得清为什么要的冗余才是优化对象。
12. 度量体系本身
可归因比例 = 已归属成本 / 总成本 （> 85%，趋势平稳）
单位成本趋势 = 每千请求成本的 30 天斜率 （不随业务同步上升）
闲置率 = 闲置资源成本 / 总资源成本 （< 5%）
决策响应时长 = 账单可见 → 配置变更的中位间隔 （< 7 天）
只能保一个时，保决策响应时长——它直接测量账单有没有改变行为。
13. 排错：分摊体系失效的六种样子
| 现象 | 根因 | 处理 |
|---|---|---|
| 账单没人认领 | 按创建者归属 | 改按用量，共享单列 |
| 团队质疑数字 | 估算值未标注 | 标注数据来源 |
| 标签覆盖率上不去 | 入口无校验 | warn→block |
| 分摊后成本没降 | 只展示不绑预算 | 绑配额 |
| 共享资源引发争吵 | 平摊且不公示 | 公开公式 |
| 优化动作导致故障 | 承诺内冗余当冗余 | 先确认 SLO |
14. 边界：什么时候不该做分摊
| 场景 | 判断 | 替代做法 |
|---|---|---|
| 单团队、单项目 | 收益接近零 | 总额趋势+闲置清单 |
| 成本占营收 <1% | 投产比不足 | 只做突增告警 |
| 完全托管、粒度不可细分 | 无法归因 | 粗分+单位成本 |
| 团队 <15 人 | 沟通成本更低 | 季度复盘 |
| 快速试错期 | 优化抑制探索 | 总额+爆炸半径 |
产品形态还没找到就做精细分摊，会把“多试一次”变成“多花一笔钱要解释”，直接压制探索；此时正确的治理是一个总额加一个爆炸半径。
15. 自测
- 分摊方案上线三个月，怎么判断它有没有起作用？
- 按人头平摊会诱导出哪一种具体行为？举一个你系统里的例子。
- 日志平台该按调用分摊还是按存储分摊，判据是什么？
- 为什么"把无标签资源平摊给所有团队"是错的？
- 三类成本告警里哪一类动作窗口最长，为什么？
- 竞价实例能不能跑在线服务，裁决依据是哪一条？