实战复盘：我是如何帮一家 SaaS 公司把阿里云账单从 100 万砍到 70 万的？
前言： 在降本增效成为主旋律的今天，对于 CTO 和运维负责人来说，云账单往往是那个“即使不想看也不得不看”的痛点。
上个月，我协助一家 B 轮融资的 SaaS 公司进行了深度的云资源审计与优化。历时两周，要在不影响任何业务稳定性的前提下，将其阿里云月度账单从 100 万（年化 1200 万）成功压降至 70 万左右，综合降本幅度达到 30%。
这一省，就是一年 360 万的纯利润。
很多人问我：是不是砍了业务？或者降低了配置？ 我的回答是：不是降级，是“除湿”。 云资源里的“水分”，远比你想象的要大。
以下是我的实战复盘。
第一步：拒绝盲人摸象，用脚本做“全身CT”
很多公司的运维在查账单时，习惯去阿里云控制台的“费用中心”看大盘。但那是财务看的，不是运维看的。财务数据无法告诉你**“钱是不是花得冤枉”**。
我入场的第一件事，不是去关机器，而是跑脚本。
我使用 Python (Aliyun SDK) 编写了一套自动化巡检脚本，对该公司的所有 Region 进行了全量扫描。与其靠人工排查，代码永远是最诚实的。
我的脚本主要抓取了以下维度的“异常数据”：
- ECS 僵尸检测： 找出连续 30 天 CPU 利用率低于 2% 的实例。
- EBS 孤儿检测： 状态为
In_use但实际读写 IO 为 0，或者状态为Available未挂载的云盘。 - 快照审计： 超过 90 天且未关联任何自定义镜像的快照。
- 流量异常： 内网互通却走了公网 EIP/NAT 网关的流量路径。
诊断报告输出： 脚本跑完，生成了一份《云成本透视分析报告》。结果令人咋舌：闲置资源占比 12%，配置溢出占比 15%，架构性浪费占比 8%。 这 35% 就是我们要挤出来的水分。
第二步：ECS 资源利用率大手术 —— “瘦身”
这是大头。在这家公司的账单里，ECS 计算资源占据了 60%。
1. 拒绝“安全感配置”
很多开发为了“求稳”，申请机器时习惯性“顶格申领”。业务只要 2核4G，非要申请 8核16G，美其名曰“预留冗余”。 通过 CloudMonitor（云监控）的历史数据，我发现有 20 多台跑定时任务的机器，CPU 峰值从未超过 10%。 对策： 在非核心链路，直接进行 InstanceType 降配。将 8vCPU 降级为 2vCPU 或 4vCPU。仅此一项，月节省 5 万元。
2. 实例代际升级
他们还在大量使用 g5、c5 系列的老旧实例。 对策： 阿里云的定价策略往往是“新一代性价比更高”。我将部分实例迁移到了 g7 或 g8 系列（甚至部分非核心业务采用了 AMD 实例）。在算力提升 20% 的同时，价格反而便宜了 15%。
3. 引入弹性伸缩 (Auto Scaling)
他们的业务有明显的波峰波谷（早9晚6）。但之前是按“晚高峰”的量全天候开着机器。 对策： 结合 SLB 和 ESS（弹性伸缩服务），将固定实例减少至 30%，其余 70% 的算力全部改为按需自动扩缩容。 结果： 每天夜间 0:00 到次日 8:00，计算成本直接归零（除了少量保底机器）。
第三步：清理“隐形杀手” —— 快照与存储
存储费用往往是“温水煮青蛙”，单价不高，但日积月累非常恐怖。
1. 无效快照大扫除
脚本扫描发现，该公司保留了 3 年前的开发环境系统盘快照。这些快照对于现在的业务没有任何回滚价值。 对策： 设定策略，批量删除了所有“创建时间 > 180天”且“未打保留标签”的快照。清理释放了 50TB 的快照空间。
2. OSS 生命周期管理 (Lifecycle)
他们的日志归档和用户上传的图片，全部放在标准存储（Standard）里，哪怕是 2 年前的数据。 对策： 配置 OSS 生命周期规则。
30天后转入低频访问存储 (IA)。180天后转入归档存储 (Archive)。 结果： 存储单价瞬间下降了 60% 以上。
第四步：堵住“流量黑洞” —— 内网也是钱
这是最容易被忽视的“冤枉钱”。
我分析账单时发现，NAT 网关的流量费高得离谱。排查后发现，应用服务 A 调用业务 B，明明都在同一个 VPC 内，却因为配置失误，走了公网域名。 这意味着：流量先出公网，绕一圈，再回来。 每一 GB 数据都在被双向收费。
对策：
- 修正 DNS 解析，强制走 VPC 内网 IP。
- 对于跨 VPC 的调用，建立云企业网 (CEN) 或 VPC Peering，严禁走公网 NAT。
这一改动，不仅省了流量费，连 API 调用的延迟都降低了 20ms，一举两得。
总结：降本是运维的核心竞争力
经过这套组合拳：
- 资源瘦身： 关停降配。
- 架构优化： 弹性伸缩 + 内网流量修正。
- 垃圾清理： 存储与快照治理。
最终，下个月的预测账单定格在了 70 万左右。对于公司，这是实打实的利润；对于运维，这是无可辩驳的绩效。
写在最后： 云资源优化（FinOps）不是一次性的工作，而是一种持续的运营能力。
如果你也怀疑公司的阿里云/AWS 账单里有“水分”，或者看着每月的费用心惊肉跳，欢迎私信或者在评论区留言。
我把自己写的这套《云资源自动巡检脚本 (Python版)》整理好了，可以免费发给有需要的朋友，帮你给公司的云资源做个免费体检。
本文作者：[木头]，一名专注降本增效的资深运维工程师。
