FinOps：云资源与IT成本治理实战

FinOps 不是简单地要求各团队“少花钱”，而是让工程、财务、采购、产品和管理者使用一致的数据，在速度、可靠性、性能和成本之间做出透明决策。现代 FinOps 的对象已经不只包括公有云，也可以覆盖 SaaS、私有云、数据中心、软件许可和 AI 资源。

本文给出从账单可见、成本分配、异常管理到单位经济性的落地路线。示例不绑定云厂商，具体计费项目以当前合同和官方账单为准。

一、为什么传统成本管理不够

传统数据中心通常通过年度采购和固定资产折旧管理成本。云资源可以在几分钟内创建、扩容和删除，费用由实例规格、运行时间、流量、请求、存储层级和折扣共同决定。常见问题包括：

• 账单很大，但无法回答由哪个系统、团队或客户产生；
• 标签缺失或不一致，大量费用进入“共享/未知”；
• 测试资源长期运行，快照和公网地址无人回收；
• 只关注价格折扣，没有先优化实际使用量；
• 为节省成本降低冗余，反而增加事故风险；
• 财务看到的是月度金额，工程团队需要小时级资源数据；
• 采购了预留折扣，但工作负载变化导致承诺无法使用。

FinOps强调共同责任：工程团队理解使用量，财务和采购理解计费与合同，管理者基于业务价值设定优先级。

二、建立成本数据底座

1. 收集完整数据

至少汇总：

• 云厂商明细账单和使用量；
• 合同价、折扣、信用额度、税费和支持费用；
• 账号、订阅、项目和资源层级；
• 标签、资源名称、区域和规格；
• CMDB或服务目录中的业务、团队和负责人；
• Kubernetes命名空间、工作负载和资源请求；
• SaaS席位、许可证和活跃用户；
• 私有云、机房设备、功耗、维保和折旧数据。

账单数据应保留原始版本，转换过程可追溯。币种、税费、退款和摊销口径必须统一，否则不同报表会得出不同结论。

2. 设计成本归属模型

推荐至少包含：

不是所有资源都能打标签。共享网络、安全、日志、监控和平台费用需要单独的分摊规则。

三、标签治理

标签治理分为四步：定义、实施、检测和纠正。

1. 建立字段字典，限定大小写、可选值和负责人；
2. 通过 IaC 模块、策略和项目模板自动加入标签；
3. 创建资源时阻止缺少关键标签，或给临时资源设置短期例外；
4. 持续生成缺失、无效和无人负责的资源清单；
5. 把标签完整率纳入平台和团队指标。

仅靠邮件提醒通常不会成功。应尽量在创建入口自动填充，并允许负责人在服务目录中维护一次、同步到多个系统。

四、共享成本如何分摊

常见方法：

• 平均分摊：简单，但无法反映真实使用；
• 按直接成本比例：适合支持费用、共享折扣；
• 按使用量：如日志量、流量、CPU小时、席位；
• 按业务驱动量：订单数、活跃用户、存储容量；
• 中央承担：明确决定由平台预算承担，不强行分摊。

分摊规则应该稳定、可解释，并保留规则版本。不要为了追求100%精确而制造难以维护的模型。无法合理分摊时，可以透明地标记为中央共享费用。

五、预算、预测和异常管理

预算

预算是决策边界，不只是超支后发邮件。应按业务、团队和环境设定，并明确超出不同阈值时的动作：提醒、解释、审批或暂停非关键扩容。

预测

预测要考虑：

• 历史趋势和季节性；
• 新项目、迁移和大促；
• 合同与价格变化；
• 数据增长和保留周期；
• 已批准的扩容和下线计划；
• 汇率、税率和一次性费用。

记录预测偏差及原因比追求一个看似精确的数字更重要。

异常费用

异常检测应结合绝对金额、变化比例和持续时间。小团队突然增长200%可能金额很小，大业务增长10%可能已经非常昂贵。告警必须包含资源、变化来源、负责人和建议动作。

六、成本优化的正确顺序

1. 先消除浪费

• 无人负责或已过期资源；
• 空闲计算实例；
• 未挂载磁盘和旧快照；
• 长期不用的公网IP、负载均衡和测试集群；
• 无查询价值的高成本日志；
• 离职人员或不活跃的SaaS席位。

删除前应确认依赖、备份和回退，不能只凭CPU低就判断资源无用。

2. 再优化规格和架构

• 根据长期分位数调整规格；
• 对周期性环境设置启停计划；
• 为可中断任务使用更合适的计费类型；
• 调整对象存储层级和生命周期；
• 优化跨区域、跨可用区和公网流量；
• 通过缓存、批处理和数据压缩减少请求和流量；
• 调整数据库索引、实例类型和副本策略。

任何降配都要设定性能和可靠性保护指标。

3. 最后购买价格承诺

预留实例、节省计划和承诺折扣适合稳定基线负载。购买前应评估覆盖率、利用率、期限、可转移性和业务变化。折扣不是优化低效资源的理由。

七、Kubernetes成本治理

Kubernetes中节点费用需要分配到集群、命名空间和工作负载。重点关注：

• requests 与真实使用量的差异；
• 长期 Pending 或反复重启的工作负载；
• 空闲节点和碎片化资源；
• 系统组件、平台组件和业务组件的共享成本；
• GPU等稀缺资源的分时与队列；
• 网络、日志、镜像和持久卷费用；
• HPA/VPA与节点自动扩缩容的协同。

不能简单用 limit 当作实际成本。节点已经购买时，短期内降低 request 不一定减少账单，只有释放的容量能合并并缩减节点时才产生真实节省。

八、建立单位经济性

总成本下降不一定代表效率提升。可以计算：

• 每万次API请求成本；
• 每个活跃用户成本；
• 每笔订单或每次构建成本；
• 每TB有效数据成本；
• 每个租户的基础设施成本；
• AI场景中每千Token、每次推理或每个任务成本。

单位成本需要同时定义分子和分母的口径，并结合质量指标。例如成本下降但错误率上升，不是有效优化。

九、组织与流程

FinOps团队不应成为费用警察。推荐职责：

• 中央团队维护数据、规则、工具、合同和培训；
• 工程团队负责资源使用和优化实施；
• 财务负责预算、会计口径和预测协同；
• 采购负责价格、合同和供应商管理；
• 产品与业务负责人决定性能、可靠性和成本的权衡；
• 管理层处理跨团队共享成本和重大承诺。

建立每月成本评审，关注异常、预测偏差、优化进度和业务价值，不要只展示总账单排名。

十、FinOps指标

“节省金额”必须说明基线和计算方式，区分实际账单减少、成本避免和理论建议值。

十一、90天落地路线

第1～30天：看得见

• 汇总主要账单和合同；
• 建立账号、业务和负责人映射；
• 定义最小标签规范；
• 找出前20项费用和未知费用；
• 建立月度成本报告。

第31～60天：能负责

• 为未知和共享费用建立处理规则；
• 设置预算和异常告警；
• 清理无主、过期和明显闲置资源；
• 为团队提供自助查询；
• 建立优化工单和验收证据。

第61～90天：可优化

• 开始规格与存储优化；
• 评估稳定基线和折扣承诺；
• 建立一个核心产品的单位成本；
• 把成本校验加入资源申请和架构评审；
• 对效果、风险和预测偏差复盘。

十二、常见误区

• 只让财务负责云成本；
• 用强制关机替代业务沟通；
• 为追求低利用率而牺牲故障余量；
• 先购买长期折扣，再治理使用量；
• 把所有共享成本随意平均分摊；
• 只看月度账单，不分析单位成本；
• 把理论建议金额当成真实节省；
• 忽略日志、流量、SaaS和许可费用；
• 给每个团队排名，却不给可执行数据和工具。

十三、检查清单

• [ ] 能把主要费用映射到业务、团队和负责人；
• [ ] 标签规范可以自动实施和检测；
• [ ] 共享成本有透明、版本化的分摊规则；
• [ ] 预算和异常告警关联明确动作；
• [ ] 删除资源前完成依赖、备份和回退确认；
• [ ] 规格优化同时受SLO和性能指标保护；
• [ ] 价格承诺建立在稳定基线之上；
• [ ] 至少一个核心业务建立单位成本；
• [ ] 节省结果区分实际节省、避免成本和建议值。

十四、示例：治理一笔无法归属的云费用

某团队发现对象存储和公网流量连续两个月增长，但账单只有账号名称，没有业务标签。FinOps人员没有直接要求停用，而是把存储桶访问日志、资源创建记录、域名和服务目录进行关联，确认费用来自一个已停止推广但仍保留下载入口的旧产品。

团队先补负责人、业务和到期日，再分析对象访问频率和来源地区。结果显示大部分历史文件几乎不访问，但少量客户仍在使用。处理方案不是立即删除，而是把冷数据迁移到更合适的存储层级、缩短非必要日志保留、为热点内容配置缓存，并保留客户仍需访问的数据。修改前记录成本和性能基线，修改后连续观察下载成功率、延迟、回源量和账单。

报告把结果分为三类：已反映到账单的实际节省、如果继续增长将产生的成本避免、尚未实施的理论建议。通过这一过程，组织还发现资源创建入口没有强制负责人和生命周期字段，于是把治理措施前移到平台模板，避免以后重复产生未知费用。

十五、参考资料

• FinOps Framework
• FinOps Framework 2025
• FinOps：Adopting FinOps
• FinOps Foundation：State of FinOps

FinOps的最终目标不是让账单最低，而是让每一笔技术投入都有清晰归属、可解释价值和持续优化机制。