2. OCI 成本结构解析

在 OCI 上做 FinOps，第一步不是“省钱”，而是把账单拆开看：每一块钱究竟由哪个服务、哪个维度、哪个用量单位产生。OCI 的计费模型整体上遵循“按量计费 + 计量维度 + 定价模型”三层结构。理解这三层，才能把成本从“一个总数”还原成“可归因、可预测、可优化”的明细。

一、计费的三层结构：维度、单位、定价

OCI 每个服务的成本都可以用同一个公式表达：成本 = 用量 × 单价。难点在于“用量”如何计量。计量维度（Metering Dimension）决定了用量按什么单位统计，常见的有：小时（OCPU·小时、GB·小时）、容量（GB·月）、次数（请求数、API 调用）、流量（GB 出站）、吞吐（IOPS、MB/s）。定价模型（Pricing Model）则决定单价如何随承诺、用量、区域变化，OCI 主要有三种：

• 按需（On-Demand）：无承诺，按秒/小时计费，单价最高，适合波动或短期负载。
• 节省计划（Savings Plan / 承诺用量）：承诺 1 年或 3 年的每小时消费额，换取折扣，适合稳定基线负载。
• 自带许可（BYOL）：数据库、中间件等自带许可证，降低软件授权部分的单价。

成本驱动因素（Cost Driver）就是让“用量”上升或下降的业务与技术变量。例如计算服务的驱动因素是 OCPU 数量、运行时长、实例形态；存储的驱动因素是容量、性能层级、请求次数；网络的驱动因素是出站流量、跨区流量、NAT 网关处理量；数据库的驱动因素是 OCPU、存储、备份、许可类型。FinOps 的核心工作，就是识别每个服务的驱动因素，并判断哪些可以优化。

二、计算服务：OCPU·小时与实例形态

OCI 计算（Compute）按 OCPU·小时 计费，1 OCPU 在 x86 上约等于 2 vCPU。计费粒度精确到秒，但按小时单价折算。成本驱动因素包括：实例形态（Standard、Dense I/O、GPU、ARM Ampere A1）、OCPU 数、内存（部分形态内存单独计费）、运行时长、是否使用 Burstable 实例。

以示例参数说明：一台 VM.Standard.E4.Flex，2 OCPU、16 GB 内存，按需单价假设为 0.025 USD/OCPU·小时，则每小时成本 = 2 × 0.025 = 0.05 USD，每月（730 小时）约 36.5 USD。若改为 1 年节省计划，假设折扣 30%，则月成本降至约 25.6 USD。这里的关键判断是：该实例是否 7×24 稳定运行？若是，承诺折扣划算；若每天只跑 8 小时，按需反而更省。

ARM Ampere A1 的单价通常低于 x86，且提供一定免费额度，适合可迁移的容器化负载。GPU 实例（如 A100、H100）单价高，驱动因素从“时长”转为“GPU 卡数 × 时长”，需要按训练任务排队和抢占策略优化。

三、存储服务：容量、性能与请求次数

OCI 块存储（Block Volume）按 GB·月 计费，同时性能层级（Balanced、Higher Performance、Ultra High Performance）影响单价。成本驱动因素：卷容量、性能层级、备份容量、克隆数量。对象存储（Object Storage）按 GB·月 + 请求数 + 出站流量 计费，分为 Standard、Infrequent Access、Archive 三档，访问越冷单价越低，但取回有额外费用。

文件存储（File Storage）按 GB·月计费，驱动因素是文件系统容量和吞吐层级。一个常见误区是只关注容量，忽略请求次数：小文件高频读写的对象存储场景，请求费用可能超过容量费用。因此存储优化要同时看容量、性能层级和访问模式。

四、网络服务：出站流量是主要成本项

OCI 网络计费的核心是出站流量（Egress）。入站流量通常免费，同一可用域内网流量免费，跨可用域、跨区域、到互联网的出站流量按 GB 计费。NAT 网关、负载均衡器、VPN、FastConnect 也有各自的计费维度：NAT 网关按处理流量计费，负载均衡按带宽和实例数计费，FastConnect 按端口带宽和出站流量计费。

成本驱动因素包括：出站数据量、跨区复制流量、NAT 网关处理量、负载均衡带宽规格。优化方向是尽量让流量留在同一可用域、使用私有端点（Private Endpoint）替代公网、压缩和缓存减少出站量。

五、数据库服务：OCPU、存储、备份与许可

OCI 数据库服务（Autonomous Database、Base Database、MySQL HeatWave）计费维度更复杂。Autonomous Database 按 OCPU·小时 + 存储 GB·月 计费，分 Serverless 和 Dedicated 两种部署；Base Database 按 OCPU·小时 + 存储 + 备份计费；MySQL HeatWave 按 OCPU·小时 + 存储 + HeatWave 节点计费。许可类型（License Included 或 BYOL）直接影响单价，BYOL 通常可降低 30%～50% 的软件成本。

数据库的成本驱动因素：OCPU 数、存储容量、备份保留策略、自动扩缩容设置、许可类型、是否启用 Data Guard。自动扩缩容若未设置上限，可能在负载高峰时推高 OCPU 用量，因此必须设置合理的最大 OCPU 阈值。

六、核心服务计费维度对照

七、从账单到归因：一个可执行的拆解方法

拿到 OCI 月度账单后，建议按以下顺序拆解：第一步，按服务分类汇总，找出金额最高的前三个服务；第二步，对每个服务查看计量维度明细，区分“容量型”和“用量型”成本；第三步，把用量映射到具体资源（通过标签、区间、成本中心）；第四步，识别驱动因素中可控的部分，形成优化候选清单。

例如，账单显示计算占比 45%、数据库 30%、网络 15%、存储 10%。进一步查看计算明细，发现 60% 的 OCPU·小时来自 7×24 运行的 Web 层实例，且未使用节省计划；数据库的自动扩缩容最大 OCPU 设置为 8，但实际峰值只到 4。这两个发现分别对应“承诺折扣”和“扩缩容上限”两个优化动作，预计可降低 15%～25% 的月度成本。

掌握计费维度、定价模型和成本驱动因素，是后续容量规划、预算预测和优化执行的基础。只有把每个服务的“用量从哪来、单价怎么变、驱动因素能否控制”这三件事说清楚，FinOps 才不是一句口号，而是一套可落地的成本治理方法。