云成本优化最有效的顺序是：先让成本可见，再清闲置，接着做规格右调，最后才是计费方式组合。跳过前两步直接买预留实例，往往是把浪费固化成了长期合约。多数企业的第一轮治理能压掉 25%–40%，其中超过一半来自"没人用的资源"。
第一步：让成本可见
看不到就管不了。账单往往按产品维度汇总，而决策是按业务线、项目、环境做的，两者对不上，任何优化都会变成"大家一起省一点"的空话。落地动作是强制标签策略：
- 必填标签：业务线/项目、环境（prod/staging/dev）、负责人、成本中心。缺标签的资源在账单里归入"未分摊"，并按周发给对应负责人。
- 分账报表：每月按标签聚合出"每业务线成本 / 每万元营收成本"两个指标，比绝对金额更能驱动行为。
- 单位成本视角：把成本除以业务量（订单数、活跃用户），避免业务增长的成本被误判为浪费。
FinOps 的核心不是省钱，而是让每一次花销都能对应到一个明确的业务归属和技术决策。没有归属，优化只能靠运动式突击，三个月后反弹。
第二步：清理闲置资源
这一项收益最快、阻力最小，通常一两周就能完成。按下面清单逐项过一遍：
| 资源类型 | 常见浪费形态 | 处理动作 | 风险提示 |
|---|---|---|---|
| 云服务器 | CPU 平均利用率长期低于 5%，或已无人认领 | 停机 → 观察一周 → 释放 | 先确认是否承载定时任务或灾备角色 |
| 云盘/块存储 | 已删除实例遗留的独立云盘 | 打快照后释放 | 确认无挂载与手工挂载脚本 |
| 快照 | 无保留策略，三年累积数千份 | 设保留策略（如日备 7 天、周备 4 周、月备 12 月） | 合规要求的备份不能删 |
| 弹性公网 IP | 已解绑但仍占用，按未绑定状态计费 | 释放未绑定 EIP | 确认无 DNS 记录指向 |
| 负载均衡 | 后端无健康实例的空闲实例 | 合并或释放 | 核对域名解析与灰度流量 |
| 对象存储 | 临时文件、日志长期不清理 | 配置生命周期规则转低频/归档或过期删除 | 避免误删审计与备份数据 |
| 数据库 | 只读从库长期空跑、测试库常开 | 按需启停或降配 | 确认无报表与备份任务依赖 |
| NAT 网关/带宽 | 小流量却开了超大规格 | 降规格或改按流量计费 | 峰值带宽需留余量 |
清理时务必保留可回滚路径：先停机不释放，观察一周无告警再释放；删除前打一份快照并记录在案。这类"先停后删"的纪律能避免 90% 的误删事故。
第三步：规格右调（Rightsizing）
右调的依据是实际用量曲线，不是感觉。看两个指标就够：CPU 与内存的 P95 使用率，以及是否发生过 OOM 或 CPU 被打满。常见结论是"规格买大了一到两档"——大量实例长期运行在 10% 以下的 CPU 水位。
调整策略要分负载类型：
- 无状态服务：优先降单机规格、增副本数。同样的总算力，多台小规格比少台大规格更抗故障，也更容易弹性伸缩。
- 有状态服务：数据库不要激进降配，先看连接数、慢查询与 IOPS 瓶颈；内存型数据库（Redis）留足余量，避免淘汰率上升导致命中率崩塌。
- 峰值型业务：不要为了一年几次的峰值常备容量，用弹性伸缩加队列削峰，峰值时临时扩容。
右调一定要有验收标准：降配后观察一周的错误率、P95 延迟与 OOM 次数，任一指标恶化就回滚。批量降配而不做灰度，是成本优化里最容易引发线上事故的操作。
第四步：计费方式组合
同规格的云服务器，包年包月、预留/节省计划与按量付费之间的单价差异通常可达数倍（具体折扣以各厂商官网为准）。但折扣的前提是"你确实会用满"。因此按负载的稳定性分层：
| 负载特征 | 占总量比例参考 | 推荐计费方式 |
|---|---|---|
| 7×24 稳定运行的核心服务 | 50%–70% | 包年包月或预留实例/节省计划，锁定 1 年期 |
| 有明显昼夜波动、可预测 | 15%–30% | 基线部分用预留，波峰部分用按量 + 弹性伸缩 |
| 临时任务、压测、CI 构建机 | < 15% | 按量付费或抢占式实例，跑完即释放 |
| 开发测试环境 | < 10% | 按量 + 定时启停（夜间与周末关机） |
两个纪律：预留承诺的覆盖率从 60%–70% 起步，先观察三个月实际用量再提高；不要把弹性部分也买成包年，否则扩缩容失去意义。
第五步：存储分层与自动伸缩
存储成本的特点是"只涨不跌"，需要靠规则来压。对象存储按访问频次分层：热数据标准存储、30 天未访问转低频、90 天转归档/冷归档，并给临时目录设过期删除规则。块存储则要区分性能型与容量型，日志盘、备份盘用容量型即可，不必全上高性能 SSD。
自动伸缩是双向的：既能扩容也能缩容，但缩容往往被忽略。检查 HPA/伸缩组的缩容阈值与冷却时间，避免只扩不缩；节点池要开启集群自动缩容（cluster autoscaler），否则 Pod 缩了节点还在付费。Kubernetes 场景下的资源请求设置不当会直接推高成本，可参考 Kubernetes 核心概念 中关于 requests/limits 的说明。
第六步：把治理变成制度
一次性优化会在三个月内反弹，制度才能锁定收益。可落地的四件事：
- 预算与告警：给每个业务线设月度预算，达到 80% 预警、100% 通知负责人，避免月底才发现超支。
- 上线前成本评审：新服务上线时说明预估规格与成本，架构选型阶段就避免"先买大的再说"。
- 月度成本复盘会：只看三个数字——总成本、单位成本、未分摊比例，各自指派动作与负责人。
- 优化看板：把闲置资源数、预留覆盖率、平均 CPU 水位做成周更指标，让浪费始终可见。
组织上建议设一名 FinOps 牵头人（通常是平台或 SRE 岗），但成本责任必须落回业务团队——平台侧只提供工具、报表与规则，不做"帮你省钱"的保姆。带宽与流量的计费方式也常是隐形大头，选型细节见 云服务器带宽与流量计费避坑。
常见问题
云账单降 30% 现实吗，一般从哪里来？
对没有系统治理过的账号，30% 是保守目标。经验上约一半来自闲置与冗余资源清理（未挂载云盘、旧快照、空负载均衡、僵尸实例），约三成来自规格右调，其余来自计费方式组合与存储分层。已经做过一轮治理的账号，第二轮通常只能再压 10%–15%。
包年包月和按量付费到底怎么组合最省钱？
先把负载按稳定性分三层：稳定基线买包年或预留，波峰用按量配合弹性伸缩，临时任务用按量或抢占式。预留覆盖率建议从 60%–70% 起步，跑满三个月再调高，避免承诺过量造成新的浪费。具体折扣比例各厂商差异较大，以官网当期价格为准。
降配之后性能会不会不够用？
关键看依据。如果降配基于近 30 天的 P95 CPU 与内存水位、且留有一档余量，风险很低；如果凭感觉或只看平均值，就容易踩坑。做法是分批灰度降配，观察一周的错误率、P95 延迟和 OOM 次数，指标恶化立即回滚。
开发测试环境也要做成本治理吗？
要，而且往往性价比最高。非生产环境通常占总成本的两三成，但使用率极低。最简单的动作是定时启停——夜间与周末自动关机，可省下约六成机时费用；其次是按需创建、用完销毁，避免"临时环境"变成永久资产。
延伸阅读
- 云服务器带宽与流量计费避坑
- 云服务器选购指南：配置、带宽与计费方式怎么选
- 对象存储怎么选：OSS、S3 与自建 MinIO 对比
- 日志体系怎么建：从 rsyslog 到 ELK 与 Loki 的选型：日志存储是账单里最容易失控的一项，这篇讲了分层保留策略。
- DNS 与 CDN 加速：把首字节时间压下来的正确顺序：提高缓存命中率是降本动作里性价比最高的一项。
- Nginx 性能调优清单：worker、连接数与缓存怎么设：压测出真实容量，才不会为冗余配置长期付费。
