目标
伸缩策略在两个方向上失败：太慢（用户感受到爬坡）或太急（副本振荡、账单翻倍）。从真实流量形态出发调参、用延迟类触发器、诚实地配置冷却与不对称的缩容窗口，才能落在两者之间——扩容快、缩容慢，用少量闲置容量换稳定。
步骤要点
- 分析真实流量形态：考察爬坡速率、每日峰值、尖峰事件及其周期性，策略要匹配形态而不是抽象概念。
- 选对信号：负载与资源脱钩时优先延迟或队列深度做扩容触发，均匀计算型才用 CPU。
- 对着振荡调阈值与冷却：扩容灵敏度追上实测爬坡，冷却期防止与稳定器打架，缩容保守避免平台期翻拍。
- 圈定边界：min 为夜间底线与故障余量，max 作为成本熔断并接评审告警，步长在尖峰下有实际意义。
- 用回放峰值验证：在预发重放最近最狠的峰值，确认爬坡全程延迟守住 SLO 且过冲有界。
排错提示
CPU 只有 40% 用户却在排队，是 IO 型负载用错了信号，换成延迟或队列深度触发；副本数一天到晚上下翻拍是对称策略的必然产物，缩容窗口至少是扩容的五倍；max 被打到没触发任何告警说明上限只是摆设，触顶必须带评审与容量复盘。
适用边界
伸缩响应受资源供给速度限制，云商配额与镜像拉取时间是不可压缩的下界；回放验证依赖历史峰值代表性，超出历史的全新尖峰形态需保守加余量。
代码示例
traffic shape (observed):
weekday ramp: 09:00 4x in 90 min (linear)
spike events: +300% in 4 min (marketing)
overnight floor: 11% of peak
before (CPU 70% target, no cooldown):
ramp: replicas chase, p99 2.1s for 12 min (SLO 500ms)
plateau: 8 -> 14 -> 8 -> 14 oscillation all day
after (tuned):
signal: p99 latency 300ms target + queue depth 20
scale-out: +50% steps, stabilization 60s
scale-in: 5 min window, 20% down steps
bounds: min 3 (failover floor), max 24 (cost breaker)
peak replay: p99 max 460ms, overshoot 2 replicas, no flap