1. Oracle Cloud FinOps 导论

在云上做成本管理，最容易踩的坑不是“不会省钱”，而是把成本当成财务部门月末才关心的事。FinOps 的核心主张恰恰相反：成本是工程决策的一等公民，它必须和性能、可用性、交付速度一起被设计、被度量、被持续优化。Oracle Cloud Infrastructure（OCI）的计费与容量模型有其鲜明特点——按秒计费、按需弹性、预留容量与节省计划并存、跨可用域与跨区域的资源拓扑直接影响账单结构。理解这些特点，才能把“省钱”从口号变成可执行的工程动作。

FinOps 的三条原则与 OCI 的对应关系

FinOps 基金会把实践归纳为三条原则，它们不是口号，而是可以直接映射到 OCI 具体机制的操作准则。

• 协作（Collaboration）：财务、工程、采购、业务必须共享同一套成本语言。在 OCI 中，这意味着用标签（Tag）和成本跟踪标签把资源归属到团队、项目、环境，让账单能按业务维度拆分，而不是只按 compartment 罗列。
• 责任归属（Ownership）：每个资源都要有明确的责任人。OCI 的 Compartment 天然是权限与成本的边界，配合预算（Budget）和告警（Alert），可以把“谁花的钱”落到具体团队。
• 价值驱动（Value）：不是花得越少越好，而是单位业务价值的花费最优。OCI 的弹性伸缩、预留容量、节省计划提供了不同成本/灵活性权衡，选择取决于业务对稳定性和响应速度的要求。

这三条原则落到 OCI 上，就形成了一条从“资源创建”到“账单归因”再到“优化决策”的闭环。下图展示了 OCI 成本模型与容量治理之间的核心关联：资源形态决定计费方式，计费方式决定成本可见性，成本可见性反过来驱动容量与架构的调整。

OCI 成本模型的三个关键特征

与许多云厂商不同，OCI 的成本模型有几个直接影响 FinOps 实践的特征，值得在课程一开始就建立清晰认知。

第一，按秒计费与最小计费单位。OCI 计算实例按秒计费，但存在最小计费时长（例如按需实例通常有 1 分钟的最小计费窗口）。这意味着频繁启停短生命周期实例并不一定省钱，反而可能因为最小计费单位而放大成本。FinOps 实践中，判断“是否值得自动关机”必须把最小计费窗口和实际业务空闲时长一起算。

第二，预留容量与节省计划的区别。预留容量（Reserved Capacity）是提前承诺一定量的计算容量，换取显著折扣，适合长期稳定负载；节省计划（Savings Plan）则是承诺每小时消费金额，抵扣范围更灵活，适合负载形态会变化但总体支出可预测的场景。两者不是互斥，而是可以组合覆盖不同比例的基线负载与弹性负载。

第三，出站流量与跨域拓扑的成本影响。OCI 区域内跨可用域流量通常免费或低价，但跨区域、出公网流量会计费。这意味着高可用架构的可用域选择、数据复制策略、CDN 回源路径都会直接反映在账单上。容量治理不能只看计算和存储，网络拓扑同样是成本变量。

容量治理与成本治理为什么必须一起做

很多团队把成本治理理解为“月底看账单、找异常、砍资源”，这是被动且滞后的。容量治理关注的是“资源供给与业务需求是否匹配”，它天然是成本治理的前置动作。两者结合，才能形成可预测的闭环。

举一个教学示例（以下参数为合理假设，用于说明计算逻辑，非实测数据）：某业务在 OCI 上运行 10 台 4 OCPU 的按需计算实例，单台按需价格假设为 0.10 元/OCPU·小时，则每月（按 730 小时）按需成本约为 10 × 4 × 0.10 × 730 = 2920 元。若其中 6 台为稳定基线负载，改用预留容量假设折扣 40%，则这 6 台月成本约为 6 × 4 × 0.10 × 730 × 0.6 = 1051 元；剩余 4 台保持按需以应对波动，成本约 1168 元；合计约 2219 元，相比全按需节省约 24%。这个示例说明：容量治理的核心不是“全部预留”或“全部按需”，而是识别基线负载与弹性负载的比例，再匹配对应的计费方式。

本课程的学习路径

本课程围绕“原则—模型—度量—优化—治理”的主线展开，共 30 章。前几章建立 FinOps 原则与 OCI 成本模型的认知基础；中间部分深入标签体系、预算告警、成本分析、预留容量与节省计划的实操；后续章节覆盖容量规划、自动伸缩、存储分层、网络成本优化、异常检测与治理机制。每一章都会尽量给出可执行的判断依据、示例参数和操作路径，而不是停留在概念层面。

学习本节后，你应该能够回答三个问题：FinOps 的三条原则分别对应 OCI 的哪些机制？OCI 成本模型的按秒计费、预留容量、出站流量三个特征如何影响优化决策？容量治理与成本治理为什么必须形成闭环？带着这三个问题进入后续章节，会更容易把零散的工具和指标串成一套可落地的治理体系。