4. 成本可视化与分摊

当 CUR 已经稳定落入 S3、Athena 能查询、成本标签也逐步补齐之后，FinOps 的下一道门槛不是“能不能看到账单”，而是“能不能让每个业务方看到属于自己的那一份，并且相信这个数字”。本章围绕这条主线展开：用 QuickSight 把成本数据变成可交互看板，用标签与账户结构把成本归到业务/团队/项目，用规则把共享成本拆开，最后通过 Showback（展示）与 Chargeback（回传/计费）形成闭环。

一、从 CUR 到 QuickSight：看板的数据链路

QuickSight 本身不生产成本数据，它只是消费层。典型链路是：CUR 2.0 以 Parquet 格式投递到 S3，Glue Crawler 或 Athena 分区投影建立 cost_and_usage_report 外部表，QuickSight 通过 Athena 数据源连接该表，再用 SPICE 抽取或直连方式构建数据集。这里有两个工程细节值得注意：一是 CUR 的 line_item_usage_start_date 是 UTC 时间，看板若按本地自然月展示，需要在数据集里做时区偏移，否则月初月末会出现“跨月漂移”；二是 line_item_unblended_cost、line_item_blended_cost、reservation_effective_cost、savings_plan_effective_cost 含义不同，看板必须明确口径，否则同一笔 RI 在不同视图里会得到不同金额。

一个可用的成本看板通常包含四层视图：总览层（月度总成本、环比、Top 服务）、组织层（按 OU/账户/业务线）、资源层（按标签、按资源 ID）、异常层（日环比突增、无标签资源占比）。QuickSight 的 calculated field 可以把这些口径固化下来，例如：

// 摊销后成本（含 RI/SP 分摊）
ifelse(
  isNotNull({reservation_effective_cost}) AND {reservation_effective_cost} > 0,
  {reservation_effective_cost},
  isNotNull({savings_plan_effective_cost}) AND {savings_plan_effective_cost} > 0,
  {savings_plan_effective_cost},
  {line_item_unblended_cost}
)

// 无标签成本占比
sumIf({amortized_cost}, isNull({resource_tags_user_cost_center}))
/ sum({amortized_cost})

看板的价值不在于“好看”，而在于让业务方能在 3 次点击内回答三个问题：我这个月花了多少、花在哪里、为什么比上月多。如果做不到，说明数据集粒度或筛选器设计有问题。

二、按业务/团队/项目分摊：标签是主键，账户是兜底

分摊的第一原则是“可归因”。AWS 上最可靠的分摊键是 resource_tags_user_* 系列标签，常见组合是 cost_center（成本中心）、business_unit（业务线）、project（项目）、owner（负责人）。但标签有两个现实问题：一是并非所有资源都支持标签（如部分数据传输费、Support 费、Marketplace 费）；二是标签可能缺失或写错。因此工程上通常采用“标签优先、账户兜底、规则补充”的三层映射：

• 标签优先：资源带 cost_center 标签时，直接归到对应成本中心。
• 账户兜底：无标签资源按 line_item_usage_account_id 映射到账户所属团队，映射表可维护在 DynamoDB 或 S3 的 CSV 中。
• 规则补充：对既无标签又无法按账户归属的条目（如全局 Support、部分税费），进入“共享成本池”，进入下一节的拆分流程。

为了让映射可审计，建议在 Athena 中建一张 account_owner_mapping 维表，与 CUR 做 JOIN，把 owner_team 落到每一行。这样 QuickSight 里只需按 owner_team 分组，就能得到团队级成本。示例映射表结构如下：

三、共享成本拆分：把“公共账单”变成“可解释份额”

共享成本是分摊中最容易引发争议的部分。典型共享项包括：Support 费用、CloudFront/NAT 数据传输、集中式日志与监控、安全扫描、CI/CD 构建集群、Kubernetes 控制面与共享节点池。拆分方法没有唯一正确答案，但必须满足三个条件：规则公开、数据可复算、结果可解释。常见拆分驱动因子有：

• 按直接成本比例：某团队直接成本占总直接成本的比例，乘以共享池总额。
• 按用量比例：如 NAT 按各 VPC 的流量 GB 数拆分，EKS 共享节点按各命名空间的 CPU/内存请求量拆分。
• 按人头或项目数：适用于 Support、安全工具等难以按用量度量的共享项。
• 固定比例：适用于长期稳定的共享服务，但需定期复核。

以 NAT Gateway 为例，假设某月 NAT 总费用为 1,200 美元，三个业务 VPC 的流量分别为 4TB、3TB、1TB，则按流量拆分后分别为 600、450、150 美元。这个计算过程应保留在 Athena 视图或 QuickSight 数据集中，而不是手工在 Excel 里完成，否则下个月无法复现。

四、Showback 与 Chargeback：从“看见”到“负责”

Showback 是“展示”：把分摊后的成本定期推送给业务/团队负责人，让他们看见自己的花费。Chargeback 是“回传/计费”：把成本真正计入业务方的预算或内部结算。两者不是非此即彼，而是成熟度递进关系。多数组织从 Showback 起步，等标签覆盖率、拆分规则、数据可信度都稳定后，再对部分可控成本实施 Chargeback。

一个可落地的 Showback 机制通常包含：每月固定日期（如次月第 3 个工作日）生成成本报告；报告包含总成本、环比、Top 5 服务、无标签占比、共享成本拆分明细；通过邮件、Slack 或内部成本平台推送；业务方可在 QuickSight 看板中下钻到资源级。Chargeback 则在此基础上增加预算对比、超支告警、内部结算单，甚至与财务系统对接。

五、让数字被信任：口径、审计与迭代

分摊体系能否长期运行，取决于业务方是否信任数字。为此需要做到三点：第一，所有计算字段和拆分规则在 QuickSight 数据集或 Athena 视图中可见、可复算，而不是藏在某个人的 Excel 里；第二，每月发布成本报告时附上“口径说明”，明确哪些成本按标签归集、哪些按账户兜底、哪些进入共享池、共享池按什么因子拆分；第三，建立反馈通道，业务方对某笔归属有异议时，能追溯到具体资源 ID 和标签值。

在实操中，可以用一张“分摊健康度”小表来跟踪体系质量，例如：标签覆盖率、无标签成本占比、共享成本占比、拆分规则变更次数、业务方异议数量。当标签覆盖率低于 85% 或共享成本占比超过 20% 时，说明分摊精度不足，应优先推动标签治理或重新审视共享池边界，而不是继续增加看板图表。

总结来说，本章的工程主线是：CUR 提供事实，Athena 提供可查询的明细，QuickSight 提供可交互的视图，标签与账户映射提供归因，共享成本拆分提供公平性，Showback/Chargeback 提供反馈闭环。五者缺一不可，而其中最容易被低估、也最值得投入的，是标签治理与拆分规则的文档化——它们决定了这套体系是“一次性报表”还是“可持续运行的成本治理基础设施”。