做样子的成本管理很好认：人人能看却没人行动的仪表盘，每季度一次的清理冲刺，再加上一个按从来不会支付的目录价算出来的节省数字。账单降一阵又慢慢涨回去，因为支出决策的方式什么也没变。
FinOps要解决的正是这个问题，它让工程、财务和业务围绕云支出的价值协作。去掉术语，我们认为核心只有一条：做支出决策的人要看得到决策的成本，并为此负责。下面的做法都由此而来。
打标签是为了分摊，不是为了齐全
标签策略失败，通常是因为要求太多。先从真正会用的几个开始，比如：
owner：对资源负责的团队。service：资源所属的产品或应用。environment：生产、预发布或开发。
在资源创建时就强制执行，靠基础设施即代码检查或云服务商的策略。事后补标签吃力不讨好，而且永远补不完。有些成本打不了标签，比如部分数据传输费和共享平台，商定一条简单的分摊规则就好，不要演变成持续数月的建模工作。
然后盯住一个数字：无法归属到负责人的支出占比。这个比例降下来之前，其他成本讨论都没有基础。
度量单位经济
只看总支出，判断不了情况好坏。账单涨20%而客户翻倍是好消息，用量萎缩时账单持平则不是。
选一个与业务赚钱方式相符的单位：每个客户、每笔订单、每千次API调用或每个活跃租户的成本。把账单数据和现有的用量指标结合起来，每月画一张图。开始时粗略的数字就够了，要看的是趋势。
这也会改变与工程团队的对话。“少花点钱”只会引来争论，而“上次发布后每笔订单的成本涨了，能看看吗？”是工程师可以解决的问题。它也有助于定价决策，你能看出哪些客户或功能服务成本高。
先调规格，再做承诺
先做便宜又安全的工作：
- 删除闲置资源。 找找未挂载的磁盘、旧快照、没人用的负载均衡器和被遗忘的测试环境。
- 给非生产环境排班。 开发环境只在工作日每天运行10小时，一周168小时只用50小时，比全天运行少用约70%的计算时长。
- 凭证据调整规格。 查看几周内（含高峰期）的CPU和内存，看百分位数而不是平均值。内存指标通常要装代理才能上报。
- 检查存储层级。 确认取回费用和最短保留期后，用生命周期规则把没人读的数据转到便宜层级。
- 审视架构选择。 频繁的跨可用区流量和冗长的日志可能比计算资源还贵，调整实例规格解决不了。
谨慎做承诺
预留实例和节省计划以承诺期限换取可观折扣。折扣是真的，但你承诺什么就锁定什么，所以要先调规格。
只承诺稳定的基线，也就是你确信会持续的用量。分小批逐步覆盖，不要一次大额购买。除非对工作负载非常有把握，否则先选一年期。折扣差距不大时，优先选更灵活的承诺类型。还要有人跟踪使用率和到期日，用不上的承诺就是白花钱。
账单归谁
财务可以报告云支出，但改不了实例类型。中央平台团队可以提建议，却很少知道哪些工作负载能放心动。所以责任应该落在构建和运行各服务的团队身上，财务负责整体预测，一个小型中央职能负责承诺、工具和报告。
- 每个服务都有明确的成本负责人。
- 各团队至少每月看到自己的成本、趋势和单位成本。
- 预算和异常告警发给能采取行动的团队，不发到公共邮箱。
- 架构评审时把成本作为设计考量。
本周可以做的事
- 按服务排序上月账单，看看多大比例没有明确负责人。
- 为前五大开支项指定负责人。
- 找一个闲置资源删掉，再打开异常告警，多数云服务商都提供。
- 选一个单位指标，手工算出过去三个月的数字。
这些都不需要新工具。如果确实有用，而且规模够大，再考虑工具也不迟。