多云 FinOps 实践：从成本可视到成本优化机制

大多数企业的云成本问题是这样的：账单每月都在涨，但没人能说清涨在哪里；财务拿着总额来问，技术团队只能给出“业务量涨了”这种无法验证的回答。FinOps 要解决的不是“把成本降下来”这一个动作，而是建立一套持续可问、可算、可追溯的成本管理机制。

一、第一步：把账单分成可追责的单元

只要成本归属不到团队和应用，后续所有优化都会停在“建议”层面。分工路径通常是：

• 打标签：为资源强制要求业务域、环境、负责人三类标签。关键在于强制——靠自觉打标签的覆盖率通常不到一半。
• 设默认值：新资源创建时自动注入默认标签，避免出现大量未分类资源。
• 建立分摊规则：共享资源（网络出口、日志平台、K8s 集群控制面）按明确规则分摊，而不是“谁大谁担”。
• 发布到团队：每月向各团队同步其成本明细与趋势，而不是只在内部通报总额。

二、需要盯的三类成本指标

单位成本是最容易被忽略但最有价值的一类。总支出上漲可能是业务健康增长的结果，只有当单位成本上升时，才说明效率在下降。这个区分能力决定了成本治理会不会误伤业务。

三、优化手段按性价比排序

1. 先清理完全闲置的资源

未挂载的块存储、无人访问的负载均衡、长期停止但保留的实例与快照、过期的镜像与备份。这类项基本不涉及改造风险，收益直接。

2. 处理非生产环境的长期开支

开发、测试、演示环境往往 7×24 运行但只在工作时间被使用。夜间自动停机、按需拉起，通常能省下一大块，代价是团队需要接受“早上第一条请求稍慢”。

3. 用承诺折扣覆盖稳定负载

预留实例与节省计划能拿到可观折扣，前提是能分辨哪些是稳定基线。做法是先看未来一段时间的用量下界，只对基线部分下承诺，波峰部分仍走按量。过度承诺会把节省变成浪费。

4. 调整存储与传输分层

冷数据及时下调存储等级，跨可用区与跨地域流量尽可能收敛到同区。这部分往往金额不算最大，但持续流失且容易忽略，尤其是网络出口费用。

四、机制比一次优化更重要

一次性治理能降 20%–30%，但半年后往往反弹。可持续的做法是把三件事变成例行流程：

• 预算与告警联动：接近预算阈值时自动通知成本责任人，而不是月末才发现超支。
• 上线前做成本评估：架构评审时估算稳态成本，即避免“先上线再说”的习惯。
• 季度成本回顾：固定节奏重新审视预留覆盖率、闲置资源清单与大额异常项。

五、多云环境下的额外难点

多云的 FinOps 复杂度主要来自三处：一是计价模型差异大，同样算力在不同云上的计价方式与折扣机制完全不同；二是账单粒度不一致，部分云按小时、部分按秒，也有的按项目聚合；三是标签能力不对等，需要做一层统一化映射。

务实的做法是先做归一化再谈优化：建立统一的服务清单与成本标签字典，把各家账单映射到同一维度上，再做跨云比较。否则会出现“A 云便宜所以搬过去”这种基于不完整数据的决策。

FinOps 最终交付的不是一张降本报告，而是让团队能回答三个问题的能力：这个月钱花在哪里、每单位业务的成本是多少、下个月预计花多少。能把这三件事稳定说清楚的组织，成本就不会失控。