弹性伸缩不是越多越好：用三条规则把云上闲置资源降下来

很多团队一谈弹性伸缩就想到“多备几台机器”，结果高峰过去了，机器还在空转，账单却没有跟着回落。弹性伸缩的本意不是囤资源，而是让供给跟着真实需求走。下面三条规则，能帮你在保证可用性的前提下，把闲置资源降下来。

第一条：用业务指标扩容，而不是只看 CPU

CPU 高不一定代表业务真的忙，可能是后台任务、日志压缩或者一次短暂抖动。更稳妥的做法，是把请求量、队列长度、平均响应时间作为主要触发指标，把 CPU 作为辅助参考。扩容前先问一句：用户请求真的变多了吗？如果答案是否定的，先定位异常，而不是直接加机器。

第二条：给扩容和缩容留出不同的节奏

扩容可以快一点，避免排队和超时；缩容一定要慢一点，并设置冷却时间。很多“反复伸缩”都来自阈值贴得太近：刚扩上去又立刻缩下来，实例反复启停，反而增加了不稳定和成本。建议用分级扩容、冷却窗口和最小实例数三者配合，让系统在波动中先稳住，再慢慢回收。

第三条：对已知高峰提前排班，对未知高峰留好上限

促销、发版、定时任务带来的高峰往往是可以预测的，用定时伸缩提前扩容，比事后追赶更便宜、更稳。未知流量则要靠上限和告警兜底：设定单次扩容上限、总实例上限和预算告警，一旦触顶就先通知负责人，而不是无限制扩下去。

每周复盘清单

本周最高水位是多少，闲置时段有多长，哪些实例可以降规格或改为按需加定时，哪些阈值误触发过。把这四项写进运维周报，弹性伸缩才真正从“自动加机器”变成“自动省成本”。