上周跟一个做SaaS的技术负责人吃夜宵。
他刚被CFO约谈。
翻出手机里的云账单给我看，密密麻麻的资源条目，有近四成的费用，是三个月前上线测试功能时开的实例，后来功能砍了，实例忘删。
他挠头说，当时忙着赶新版本，谁有空回头清这些。
账单上的糊涂账从来不是一个人的锅
很多团队刚上云的时候，根本没想着要做云成本优化。毕竟刚从物理机迁过来，之前买服务器要走三个月采购流程，现在控制台点三下，十分钟就能跑起一套环境，谁会算这点钱？
就像你租房刚搬进去，肯定不会先想着把哪个灯换成节能的，先住舒服了再说。等住了半年，物业把账单甩你脸上，才发现一半的电，是那个从来没打开过的储物间的空调耗的。
这事太常见了。
从团队负责人到一线开发，大家的注意力全在功能迭代、用户体验上，没人会把”省云钱”当成优先级高的事。毕竟业务跑不起来，省再多钱也没用。但反过来，没人拦着你在跑业务的同时，把那些平白无故流走的钱接回来。
省下来的钱从来不是靠关实例
很多人对云成本优化的第一反应，就是找没人用的实例删掉，关闲置的磁盘。说白了这是最浅的一层，能挤出来的水最多占总账单的10%。
真正麻烦的是那些正在跑的业务，你删了就要出故障。比如很多团队的生产实例，一上来就按最高配置开，生怕高峰期扛不住。实际跑起来，CPU平均使用率连15%都不到，内存更是剩了大半。
之前接触过一个做电商的团队，大促前给所有核心服务升了4倍配置，大促结束后忘了降回来，整整多花了八个月的冤枉钱。
很多人怕降配置出问题，干脆就一直用着高配。其实现在云厂商的弹性伸缩功能，早就把这事做的很成熟了。你只要设好阈值，流量低的时候自动缩容，流量高的时候自动扩容，根本不用人天天盯着控制台点。
别把弹性伸缩当成给大促准备的专属工具。日常的所有业务，只要流量有波动，都能套进去。之前有个团队把所有内部系统都接了弹性伸缩，光是这块就把整体资源成本砍了三分之一，业务体验一点没降。
别把成本优化变成业务的绊脚石
很多团队一提到降成本，就开始给各个部门下指标，要求每个月必须砍15%的云预算。最后技术团队被逼的没办法，只能把生产环境的日志存储时间从30天改成7天，把监控告警的阈值调的松松垮垮，真出问题的时候，查都查不出来。
这就走偏了。
云成本优化的本质，是把花在没用地方的钱，挪去能产生价值的地方。不是让你为了省钱把业务做崩。
比如你花大价钱开的全球加速节点，要是只有不到5%的海外用户访问，那完全可以把边缘节点缩到两个核心区域，把省下来的钱投去做新功能的研发，这才是划算的买卖。
说实话，我见过太多团队，把成本优化的压力全压在运维身上，开发写完代码扔上去就不管了，最后运维翻遍了控制台，也挤不出多少水分。毕竟开发写的代码如果有冗余，一次请求多打三个接口，多存两份临时文件，日积月累的资源消耗，比你删十个闲置实例都多。
现在云厂商都有自带的成本分析工具，能把每一笔钱花在哪个项目、哪个服务上拆的明明白白。很多人从来没点开看过。
就像你每个月工资到账，从来不对账单，等年底要买房的时候，才发现自己根本存不下钱。
昨天那个跟我吃夜宵的技术负责人，回去花了一晚上清完了闲置资源，又给所有生产实例设了自动缩容的规则。他说之前总觉得云成本优化是要抠到每一分钱，现在才发现，只要把那些漏出去的窟窿堵上，省下来的钱够给团队发两次季度奖金。