4. 预算管理与预测：把钱花在刀刃上
预算管理这事儿，说白了就是给云成本画个圈。圈画好了，团队就知道往哪使劲；圈画歪了，月底对账的时候准得头疼。我做了这么多年FinOps，见过太多团队预算拍脑袋定，结果要么花不完被砍额度，要么超支了才慌慌张张去补申请。
这一章，咱们就聊聊预算怎么定、怎么滚、怎么盯、怎么复盘。嗯，都是实战里踩过坑才总结出来的东西。
4.1 预算制定流程：别让预算变成数字游戏
预算不是财务部门关起门来算出来的。它得从业务需求出发，一层层往上叠。我个人习惯把预算制定分成四个阶段：
- 业务需求收集：各业务线报下个周期的资源预估，比如新增用户量、数据增量、计算任务规模。
- 技术方案评估：架构师根据需求选机型、定规格，估算出基础资源消耗。
- 成本模型映射：把技术方案里的资源量，按当前单价换算成金额。
- 审批与对齐：财务、业务、技术三方对齐，确认预算额度。
关键点：预算制定时，一定要预留 10%-15% 的弹性空间。为什么？因为业务增长从来不是线性的。我曾经遇到过一个项目，预算刚批完，第二天业务方就说数据量翻倍了……还好留了 buffer，不然整个季度都得拆东墙补西墙。
这里有个常见的误区：很多人喜欢用「去年同期的 1.2 倍」来定预算。你想想看，业务形态、资源单价、技术架构每年都在变，这种拍脑袋的方式迟早会出问题。
4.2 滚动预测方法：让预算活起来
静态预算最大的问题是什么？它是个死数字。月初定好了，月底一看，实际花销跟预算差了十万八千里。滚动预测就是为了解决这个问题的。
我推荐的做法是 12 个月滚动预测 + 季度调整。具体来说：
- 每个月更新一次未来 12 个月的预测数据
- 每个季度做一次预算基线的调整
- 每次预测都基于最新的实际消耗和业务变化
我的经验：滚动预测的精度取决于数据颗粒度。别只看总账，要按项目、按服务、按地域去拆。颗粒度越细，预测越准。我之前带团队做预测时，把粒度从「月」降到了「周」，预测偏差直接从 20% 降到了 5% 以内。
滚动预测的核心公式其实很简单：
预测值 = 实际消耗趋势 + 季节性因子 + 业务变更影响 + 价格变动影响嗯，公式看着简单，但每个因子怎么算，才是真功夫。比如季节性因子，你得看过去 12 个月的数据，找出规律。业务变更影响，得跟产品、运营团队对齐排期。
4.3 异常告警机制：别等账单出来才后悔
预算超支不可怕，可怕的是超了你不知道。我见过最夸张的情况：一个团队某天晚上跑了个全量数据回溯任务，花了 3 万美金，直到月底对账才发现。你说这钱还能追回来吗？
所以，异常告警机制必须做到 实时 + 分级。我一般这样设计：
| 告警级别 | 触发条件 | 响应方式 | 响应时间 |
|---|---|---|---|
| P0 紧急 | 单日消耗超过预算 200% | 电话 + 即时消息 + 自动限流 | 5 分钟内 |
| P1 严重 | 单日消耗超过预算 150% | 即时消息 + 邮件 | 30 分钟内 |
| P2 警告 | 单日消耗超过预算 120% | 邮件 + 日报 | 24 小时内 |
| P3 提示 | 单日消耗超过预算 105% | 日报中标注 | 下次日报 |
避坑指南：我曾经犯过一个错误——告警阈值设得太低。结果每天收到几百条告警，团队直接麻木了，看到告警也不处理。后来我把阈值调高，分级更细，告警量降了 80%，但真正的问题一个都没漏掉。
告警的触发逻辑，我建议用 滑动窗口 + 同比环比 的方式。比如：
if (当前小时消耗 > 过去7天同一小时平均消耗 * 1.5) {
触发 P2 告警
}
if (当前小时消耗 > 过去7天同一小时平均消耗 * 2.0) {
触发 P1 告警
}
if (当前小时消耗 > 预算日额度 * 2.0) {
触发 P0 告警
}这样既能捕捉突发增长，又能避免被周期性波动干扰。
4.4 预算与实际对比分析：复盘才是进步的关键
预算做完了，告警也设了，但如果不复盘，那前面的工作就白费了。预算与实际对比分析，我习惯按这个节奏来：
- 每日：看核心指标的偏差，比如总消耗、Top 5 服务消耗
- 每周：看项目级别的偏差，分析原因
- 每月：做完整的预算 vs 实际分析报告，输出改进项
对比分析时，我一般关注三个维度：
- 用量偏差：实际用了多少资源 vs 预算预估了多少
- 单价偏差：实际单价 vs 预算单价（比如预留实例折扣没拿到）
- 结构偏差：资源使用结构变了没（比如从按需转成了 Spot）
举个例子：上个月我们做对比分析时发现，某个项目的实际消耗比预算高了 30%。拆开一看，用量偏差只有 5%，但单价偏差高达 25%。原来是因为预算时假设了 70% 的预留实例覆盖率，但实际只做到了 40%。找到根因后，我们立刻调整了 RI 购买策略，下个月偏差就降到了 5% 以内。
下面这张图，是我常用的预算管理核心流程，你可以参考一下：
对比分析做完后，一定要输出 actionable 的改进项。比如：
- 「下个月需要增加 20% 的预留实例覆盖率」
- 「XX 项目的 Spot 实例使用率要从 30% 提升到 50%」
- 「XX 服务需要做资源规格降配」
这些改进项要落实到具体的负责人和截止时间，不然复盘就变成了走过场。
一个小技巧：我习惯在对比分析报告里加一个「偏差归因」的饼图。用量偏差、单价偏差、结构偏差各占多少，一眼就能看出来。这样开会的时候，大家不用看密密麻麻的数字，直接看图就知道问题出在哪。
好了，预算管理与预测这块，核心就是四个字：定、滚、警、对。定好基线，滚动更新，实时告警，定期复盘。把这四步走扎实了，云成本就不会失控。