3. 成本分摊快照概述
成本分摊快照（Cost Allocation Snapshot）是云成本管理体系中用于“冻结”某一时刻资源归属与分摊规则的数据副本。它并非实时流式数据，而是一个时间点上的确定性记录，确保在后续的容量回退、成本追溯或对账审计中，所有参与方看到的是同一份“历史事实”。
3.1 什么是成本分摊快照
成本分摊快照本质上是将某一时刻的以下三类信息打包为一个不可变的数据集：
- 资源清单快照：当前所有云资源实例的元数据（ID、规格、标签、所属项目）。
- 分摊规则快照：生效中的成本分摊策略（按比例、按用量、按固定值、层级分摊等）。
- 计量数据快照：截至该时刻的累计用量与原始成本数据。
关键区别： 实时分摊引擎处理的是“当前”数据，而快照处理的是“历史某一刻”的数据。快照一旦生成，其内容不允许被后续变更所覆盖，这是成本审计的基石。
3.2 快照在成本管理中的作用
在成本分摊与容量回退演练中，快照承担着四个核心职能，如下表所示：
| 作用维度 | 具体说明 | 演练场景示例 |
|---|---|---|
| 审计锚点 | 提供不可篡改的历史分摊结果，满足合规与内部审计要求。 | 季度成本复盘时，直接引用快照数据，避免因规则变更导致数据漂移。 |
| 回退基准 | 作为容量回退操作的“原点”，回退后需与快照中的资源归属进行比对。 | 回退演练前生成快照，回退完成后校验资源标签与分摊比例是否一致。 |
| 对账凭证 | 跨部门、跨财务周期的成本分摊争议，以快照为唯一裁决依据。 | 业务A与业务B对共享数据库成本分摊比例有异议，调取快照中的规则版本。 |
| 趋势基线 | 通过连续快照的对比，分析成本结构变化与分摊偏差趋势。 | 每月1日生成快照，观察某项目成本占比的月度变化曲线。 |
3.3 快照的生命周期
一个完整的成本分摊快照从创建到归档，通常经历以下五个阶段。下图展示了快照生命周期的核心流转路径：
各阶段的详细操作与注意事项如下：
- ① 创建：支持手动触发（演练前）与自动定时触发（每日/每周）。创建时需确保所有数据源（CMDB、账单系统、标签引擎）处于一致状态。
- ② 冻结：将动态数据转为静态数据集。此阶段会锁定分摊规则版本，防止后续规则变更污染历史数据。
- ③ 存储：快照通常以 JSON 或 Parquet 格式存入对象存储（如 S3、OSS）或时序数据库。建议保留至少 90 天，满足审计窗口。
- ④ 使用：在容量回退演练中，快照被加载到比对引擎，用于校验回退后的资源归属与分摊比例是否与快照一致。
- ⑤ 归档：超过保留周期的快照自动转入冷存储或按策略删除。归档前需确认无未完成的审计或争议。
常见陷阱： 快照创建与回退操作之间如果间隔时间过长（超过 24 小时），云资源可能发生自动伸缩或标签变更，导致快照基准失效。建议在回退演练前 30 分钟内生成快照。
3.4 快照与实时分摊的对比
为了更清晰地理解快照的定位，下表对比了成本分摊快照与实时分摊引擎的核心差异：
| 对比维度 | 成本分摊快照 | 实时分摊引擎 |
|---|---|---|
| 数据时效 | 历史某一时刻的静态数据 | 当前最新数据，持续更新 |
| 可变性 | 不可变，生成后禁止修改 | 可变，规则变更后重新计算 |
| 主要用途 | 审计、回退基准、对账 | 日常成本监控、实时告警 |
| 存储成本 | 较高（需保留多个历史版本） | 较低（仅保留当前状态） |
| 回退演练适用性 | 强（提供确定性基准） | 弱（数据持续变化，无法作为基准） |
在后续的容量回退演练章节中，我们将基于本章的快照概念，详细演示如何利用快照进行回退前后的成本差异分析。