2. Azure成本数据体系

在Azure FinOps实践中，几乎所有成本治理动作都建立在同一套底层数据之上：账户层级决定“钱记在谁头上”，使用量文件决定“消耗了什么”，价目表决定“单价怎么算”，账单周期与数据延迟决定“什么时候能看到、能信多少”。如果这四件事没有对齐，后续的预算、分摊、优化和承诺折扣管理都会出现口径漂移。本节把这条数据链拆开讲清楚，并给出可落地的核对方法。

一、三种账户结构：EA、MCA、CSP的层级差异

Azure的计费账户结构决定了成本数据的归属路径。最常见的三类是企业协议（EA）、Microsoft客户协议（MCA）和云解决方案提供商（CSP）。

EA（Enterprise Agreement）采用“注册（Enrollment）→ 部门（Department）→ 账户（Account）→ 订阅（Subscription）”四层结构。注册是计费根节点，部门用于组织隔离，账户是订阅的容器，订阅才是资源实际运行的位置。EA的成本数据天然带有Department和Account维度，适合按组织架构做分摊。EA的价目表以“价目表（Price Sheet）”形式按注册和计费周期提供，货币化价格通常已包含企业折扣层级。

MCA（Microsoft Customer Agreement）采用“计费账户（Billing Account）→ 计费配置文件（Billing Profile）→ 发票科目（Invoice Section）→ 订阅”结构。MCA没有EA的Department概念，取而代之的是Invoice Section，它更贴近“内部结算单元”。MCA的价目表通过“价目表API”按计费账户和计费周期获取，价格字段包含零售价、协议价和有效价，需要区分使用。

CSP（Cloud Solution Provider）是间接模式：最终客户不直接与微软结算，而是通过CSP合作伙伴。客户侧看到的是合作伙伴的加价后价格，使用量数据通过合作伙伴的API或Partner Center获取。CSP的成本数据延迟通常比EA/MCA更大，且价目表由合作伙伴定义，不能直接套用微软零售价。

二、使用量文件：成本数据的原始事实

使用量文件（Usage Details）是成本治理的“原始凭证”。每条记录通常包含：MeterId、MeterName、Quantity、UnitPrice、CostInBillingCurrency、ResourceId、SubscriptionId、Date、MeterCategory、MeterSubCategory、Tags等字段。其中Quantity是计量单位下的用量，UnitPrice是单价，CostInBillingCurrency是最终金额。

需要特别注意的是：使用量文件中的UnitPrice并不总是等于价目表中的零售价。对于EA，它可能是协商后的有效价；对于MCA，它可能是协议价；对于CSP，它可能是合作伙伴加价后的价格。因此，做成本分析时不能只用Quantity × 零售价来估算，必须以使用量文件中的CostInBillingCurrency为准。

使用量文件按计费周期生成，通常以每日或每月粒度提供。EA通过EA API或成本管理导出获取，MCA通过Cost Management Export或Usage Details API获取，CSP通过Partner Center或合作伙伴提供的接口获取。导出格式可以是CSV或Parquet，Parquet更适合大规模数据。

三、价目表：单价的来源与版本

价目表（Price Sheet）定义了每个计量器的单价。它有两个关键属性：版本和适用范围。版本指价目表按计费周期发布，同一计量器在不同周期可能有不同价格；适用范围指价格是零售价、协议价还是有效价。

在EA中，价目表通过PriceSheet API获取，返回MeterId、UnitPrice、CurrencyCode、EffectiveDate等字段。在MCA中，价目表通过Pricesheet API获取，返回RetailPrice、UnitPrice、CurrencyCode、EffectiveStartDate等字段。CSP的价目表由合作伙伴提供，通常包含合作伙伴的加价规则。

价目表与使用量文件的关联点是MeterId。做成本核对时，可以用MeterId把使用量记录和价目表记录连接起来，验证UnitPrice是否一致。如果发现不一致，通常是因为使用了不同版本的价目表，或者使用了零售价而非有效价。

四、账单周期与数据延迟：什么时候能看到、能信多少

账单周期（Billing Period）是成本数据的“时间窗口”。EA的账单周期通常是月度，MCA的账单周期也是月度，但发票可能按计费配置文件分别出具。CSP的账单周期由合作伙伴定义，可能是月度或自定义周期。

数据延迟（Data Latency）是成本数据从产生到可查询的时间差。Azure使用量数据通常有24～48小时的延迟，部分服务（如Azure Marketplace、预留实例）可能延迟更长。这意味着：今天产生的资源消耗，可能要到明天或后天才能在成本管理里看到。做实时成本监控时，必须把延迟考虑进去，否则会误判“没有消耗”或“消耗异常”。

延迟的另一个影响是数据回填。Azure会定期回填历史数据，修正之前的延迟或错误。因此，同一时间段的成本数据在不同时间查询可能不同。做月度结算时，应等待数据稳定后再取数，通常建议在账单周期结束后3～5天再导出最终数据。

五、把四件事串起来：一次成本核对的完整过程

假设某企业使用MCA，需要核对2025年3月某订阅的成本。操作路径如下：

1. 从Cost Management Export导出2025年3月的Usage Details，格式选Parquet，字段包含MeterId、Quantity、UnitPrice、CostInBillingCurrency、SubscriptionId。
2. 从Pricesheet API获取同一计费账户、同一计费周期的价目表，字段包含MeterId、UnitPrice、RetailPrice、EffectiveStartDate。
3. 用MeterId做左连接，比较使用量文件中的UnitPrice与价目表中的UnitPrice。如果一致，说明价格口径正确；如果不一致，检查是否使用了不同版本的价目表。
4. 汇总CostInBillingCurrency，得到该订阅在3月的总成本。与发票金额对比，差异应小于1%。
5. 如果差异较大，检查是否有数据回填未完成，或是否有CSP加价未计入。

这个过程中，最容易出错的是价目表版本和数据延迟。价目表版本不对，会导致单价错误；数据延迟未考虑，会导致取数不完整。建议在每月固定日期（如次月5日）执行核对，并保留每次核对的价目表版本和导出时间，便于追溯。

六、常见口径陷阱与规避方法

陷阱一：用零售价估算EA/MCA成本。EA和MCA的实际单价是协商价，通常低于零售价。用零售价估算会高估成本。规避方法：始终以使用量文件中的CostInBillingCurrency为准。

陷阱二：忽略CSP加价。CSP客户看到的使用量文件可能已经包含合作伙伴加价，也可能不包含。规避方法：与合作伙伴确认价目表口径，必要时要求提供加价规则。

陷阱三：在数据回填前取数。回填会修正历史数据，提前取数会导致金额偏差。规避方法：在账单周期结束后3～5天再取最终数据，并记录取数时间。

陷阱四：混淆计费周期与日历月。部分CSP的计费周期不是自然月，可能是每月15日到次月14日。规避方法：以账单周期为准，不要默认自然月。