一、钱花在哪：浪费有三种形态
1、闲置型
规格买得比实际需要高，CPU 常年跑在个位数百分比。这种浪费最普遍，也最容易被 “怕不够用” 的心理合理化。
2、时间型
白天峰值、夜里低谷，或者只在促销期间冲高。按峰值规格常年付费，剩下的时间都在为空转买单。
3、结构型
没做缓存导致回源量大、同一份数据存了三份、快照和镜像越堆越多、闲置磁盘和未绑定的弹性 IP 一直挂着。这类问题不显眼，账单上却是实打实的。
4、隐性成本
告警太吵导致没人看、故障定位靠人肉、变更没有记录。这些不直接进账单，但在人力上持续消耗。
二、云服务器监控先抓这几个指标
1、CPU
看百分位而不是平均值。P95 能反映真实的高负载时段，平均值会把尖峰抹平，让你误以为很闲。
2、内存
注意区分 “用了” 和 “缓存占用”。Linux 的可用内存和 free 字段含义不同，看错了容易误判。
3、磁盘
IOPS、吞吐、队列长度一起看。队列长度上去了，说明磁盘已经在排队，光看使用率不够。
4、网络
带宽峰值、连接数、重传率。带宽打满会连带影响响应时间，但账单上只体现流量。
5、成本
按项目、环境、业务线打标签，让每一笔支出能找到归属。没有标签体系，成本治理就无从谈起。
三、弹性伸缩怎么配才不出事
1、应用得先无状态
会话存在本地、文件写在本地盘的服务，扩出来也没用。会话外置、对象存储、配置中心，是伸缩的前置条件。
2、指标别只盯 CPU
CPU 常常不是瓶颈。队列长度、待处理请求数、平均响应时间，这些更能反映真实压力。基于 CPU 扩容，容易在 IO 瓶颈时白扩一堆机器。
3、冷启动要有预案
镜像预热、依赖包预装、健康检查宽限期。否则扩容出来的实例还没准备好，流量已经打过去了。
4、缩容要保守
缩得太快会出现抖动：刚缩完流量又上来，反复扩缩既费钱也不稳定。设冷却时间，缩容阈值比扩容阈值更宽松。
5、有状态服务谨慎处理
数据库、缓存集群这类不适合简单套用自动伸缩。它们更适合垂直扩容加读写分离，或者按业务分片。
6、设上下限
最少保留几台、最多不超过几台。上限是成本护栏，下限是可用性护栏。
四、几个立刻见效的动作
1、降一档再压测
先把规格降一档，做一轮压测验证。空跑着的高配机器，多数都能降下来。
2、区分基线负载和峰值负载
基线部分用包年包月，峰值部分用按量计费。比全部按量便宜，比全部包年灵活。
3、开发测试环境定时开关
非工作时段自动关机，这一项在很多团队能省下可观的一笔。
4、清理沉淀物
快照、自定义镜像、未挂载的磁盘、闲置的弹性 IP、过期的备份。这类资源不会自己消失，得定期扫。
5、存储分层
热数据放高性能存储，冷数据转低频或归档。日志和备份是最典型的适用对象。
6、前置缓存
CDN、页面缓存、接口缓存，减少回源和数据库压力。很多扩容需求，本质上是缓存没做好。
7、合并碎片
一堆小规格实例的管理成本高于少数几个大规格。整合能同时省下钱和运维精力。
五、成本治理是机制，不是一次性动作
1、标签体系
谁申请的、给谁用的、属于哪个环境。标签不统一，账单就没法分摊。
2、预算与告警
按项目设月度预算，超过阈值提前告警，而不是月底看账单才发现。
3、月度复盘
固定一个时间点，看趋势、看异常、看新增。频率不用高，但要固定。
4、变更评审
规格调整、架构改动之前过一遍成本影响。很多浪费是在 “临时先这样” 的决定里长出来的。
