攻击流量涌入时，CPU升高不一定代表真实用户变多。若伸缩规则只看CPU，云端应用遭攻击时自动伸缩策略误触发，可能不断增加实例，却没有解决请求来源异常的问题。治理重点不是一律关闭扩容，而是判断指标是否代表有效负载，再决定扩容、限速还是暂缓动作。
先区分业务增长与异常负载
同一组实例可能因攻击请求、正常流量高峰或下游故障而变忙，单看CPU、内存很难区分。建议并排观察每秒请求数、有效请求比例、响应延迟、队列长度，以及应用错误率。指标需结合业务含义：例如请求速率突然上升但成功请求没有同步增加，扩容未必能改善用户体验。
可将请求分为经过认证的业务操作、匿名访问和明显无效请求，检查它们各自的变化趋势。若队列长度持续增长、延迟变差，且有效请求也增加，扩容较有依据；若无效请求占比升高而有效业务平稳，应优先处理入口流量、应用限速或资源隔离。这里的关键是避免把每一次负载升高都当成扩容信号。
按风险设置阈值告警
阈值不是通用常数，应从应用平稳运行时的基线和容量测试结果出发。对常见在线服务，可以先把CPU持续高于约70%至80%作为观察信号，而不是单次触发扩容的唯一条件；具体范围取决于实例规格、并发模型和延迟目标。内存则应关注持续占用及是否接近容器限制，避免短暂缓存增长造成误判。
告警规则应加入持续时间和组合条件。例如，CPU连续数分钟偏高，同时队列增长或延迟越过业务目标，再通知值班人员；若只有CPU短时抖动，则先记录并观察。阈值告警用于发现异常，自动伸缩规则负责改变容量，两者可以采用不同门槛，避免警报一响就立刻大幅扩容。
用冷却时间和容量边界稳住伸缩
冷却时间适合抑制反复动作
冷却时间是一次扩缩容后，暂缓再次采取相同方向动作的时间。时间过短，指标还没反映新实例的效果就再次扩容，容易频繁波动；时间过长，则可能延误真实流量高峰。可先根据启动时间和监控采样周期，尝试数分钟级的观察窗口，再通过演练和历史曲线调整。对不同动作设置不同等待规则，通常比简单地把所有伸缩都锁住更稳妥。
扩容上限适合限制损失
设置最低与最高实例数，并限制单次扩容幅度，能够在规则异常时圈定影响范围。上限应按正常高峰承载能力、下游数据库或第三方服务的容量来确定；只看计算实例本身，可能把压力转移到连接池或存储。最低实例数则要满足基础可用性，不能因担心误触发而降到无法承载正常请求的水平。
可执行的治理步骤
整理近一段时间的正常负载曲线，标出业务高峰、延迟目标和实例启动时间，确认哪些监控指标能代表有效请求。
为CPU、请求速率、队列长度和错误率分别配置告警，并设置持续时间；先验证告警是否能区分短时抖动与持续异常。
检查伸缩策略的最小值、最大值、单次变化幅度和冷却时间。若使用 Kubernetes Horizontal Pod Autoscaler，核对其目标指标、指标来源及扩缩容行为设置；它可依据资源指标或已配置的自定义指标工作，但不能自动判断流量是否恶意。
在测试环境或低风险时段模拟负载变化，观察实例增加后有效请求、延迟和队列是否改善。若实例数上升而业务指标没有好转，暂停继续扩容并检查入口请求与下游瓶颈。
保留人工暂停或回滚流程，并记录每次伸缩的触发指标、时间和结果。确认误触发原因后再改规则，不要在事件处理中同时修改多项参数。
按症状选方案
当业务请求确实增长、队列和延迟一起恶化时，可保留自动扩容，但配合合理冷却时间和扩容上限。当指标短暂尖峰、实例启动较慢时，优先调整持续时间与冷却策略。若请求速率剧增而有效业务没有同步增长，则应先限制异常请求或保护应用入口，扩容只作为容量保护手段，不是攻击治理的替代品。
因此，云端应用遭攻击时自动伸缩策略误触发，适合用“指标组合判断、阈值告警、冷却时间、容量边界”逐层治理，而不是仅调高一个CPU阈值。每次变更后复核告警和伸缩记录，才能让策略既不过度扩容，也不压制真实业务增长。
常见问题
攻击期间要不要关闭自动伸缩？
不必一概关闭。若自动扩容仍能保护正常请求，可保留并缩小单次扩容幅度、设置上限；如果指标明显被异常流量主导且扩容无效，可按预案暂停相关规则，同时安排人工容量监控。
冷却时间设得越长越好吗？
不是。冷却时间要覆盖实例启动和指标稳定所需的时间；过长可能错过真实高峰。先依据启动耗时和监控采样间隔设定，再通过演练观察调整。
只用CPU阈值可以吗？
不建议。CPU可能同时受正常计算、无效请求或应用故障影响。至少结合请求速率、队列长度、延迟或错误率中的适用指标，并验证扩容后业务是否改善。
如何确认误触发已经治理？
观察后续异常期间是否仍出现无效扩容、实例是否触及上限，以及扩容后延迟和有效请求是否改善。若云端应用遭攻击时自动伸缩策略误触发仍反复发生，应回看触发指标与请求类型，再调整条件，而不是只延长冷却时间。