深色模式
FinOps 入门
FinOps 不是"省钱"，而是让花出去的每一分钱都有明确产出。它是一套把财务、技术和业务放在一起协作的实践方法。
适用环境
- 团队使用公有云或自建 IDC，有明确的账单/资源清单
- 有基本的资源标签或归属关系
- 能拿到监控数据判断利用率
bash
# 先摸清家底：列出当前所有资源与规格
kubectl get nodes -o custom-columns='NAME:.metadata.name,CPU:.status.capacity.cpu,MEM:.status.capacity.memory'1
2
2
操作步骤
1. 理解 FinOps 的三个阶段
text
Inform（看得见）：知道钱花在哪、谁花的
Optimize（优化）：把浪费去掉、把规格调对
Operate（持续运营）：建立机制，让优化自动持续发生1
2
3
2
3
新手团队必须从 Inform 开始。没有账单可视化的优化，只能是"挑最贵的砍"，很容易砍出故障。
2. 记住六个原则
- 团队协作——成本不是财务一个部门的事
- 人人有责——谁创建资源谁对成本负责
- 由业务价值驱动——不看绝对花费，看单位业务成本
- 及时上报——账单要能天级看到，不是月底才知道
- 中心化团队推动——需要有专职或兼职的 FinOps 推动者
- 利用云的弹性——按需付费的能力要真正用起来
3. 明确三类角色
| 角色 | 谁来做 | 职责 |
|---|---|---|
| 业务/产品 | 业务负责人 | 定义单位成本目标、决定功能取舍 |
| 工程/运维 | SRE、开发 | 调规格、清理闲置、优化架构 |
| 财务/FinOps | 财务或专职 | 分摊、预算、报表、推动流程 |
技术团队最常犯的错是"我自己闷头优化"，没有业务目标就没有优化终点。
4. 定义单位成本指标（最重要的一步）
text
传统指标：本月云账单 100 万（无法判断好坏）
单位成本：每笔订单 0.2 元、每 GB 日志 3 元、每 1000 次请求 0.05 元1
2
2
bash
# 用两个时间序列算出单位成本趋势
# 单位成本 = 成本 / 业务量
echo "scale=4; 1000000 / 5000000" | bc # 每笔订单 0.2 元1
2
3
2
3
目标是让单位成本随业务量增长而下降（规模效应）。这才是"健康的成本曲线"。
5. 从零开始的四周计划
text
第 1 周：打开账单，按服务/账号/区域看 top 10 花费
第 2 周：建立标签规范，开始给资源打标
第 3 周：找出闲置资源（关机实例、空盘、未使用的 IP）
第 4 周：建立月度成本审视会，定下预算与告警1
2
3
4
2
3
4
6. 建立第一个成本台账
bash
mkdir -p finops/{bills,tags,reports}
cat > finops/README.md <<'EOF'
# 成本台账
- bills/ ：月度账单导出
- tags/ ：标签规范与执行情况
- reports/ ：月度成本报告
EOF1
2
3
4
5
6
7
2
3
4
5
6
7
text
月度台账最小字段：
月份 | 总花费 | Top5 服务花费 | 单位成本 | 闲置金额 | 优化节省 | 负责人1
2
2
验证
入门阶段是否合格，看四件事能否立刻回答：
bash
# 1) 上个月总共花了多少？按服务拆开是多少？
# 2) 每个服务归谁？
# 3) 单位业务成本是升是降？
# 4) 有多少资源是明确闲置的？1
2
3
4
2
3
4
四个问题都能答出来，就具备进入 Optimize 阶段的条件。
常见坑
一上来就砍资源
没有账单可视化和归属关系时砍资源，砍掉的多半是别人的核心依赖。先 Inform 再 Optimize。
把"花费最低"当目标
一味压低花费会让冗余被砍光，最终以故障的形式还回来。正确目标是单位成本下降，而不是总额下降。
只有财务看账单
工程师看不到成本，就永远不知道自己的一个配置决定值多少钱。必须把成本数据推到研发日常可见的地方（看板/周报）。
只做一次性优化
清理一次闲置省了几万，三个月后又涨回去。没有持续机制（标签、预算、月度审视）的优化不可持续。