弹性伸缩误配置是导致服务中断的高频原因之一。你可能遇到过这样的场景：某个促销活动开始后，流量短时翻倍，但应用却突然返回 503，或者部分请求超时。此时检查 Auto Scaling 组，发现实例数不升反降，甚至最小实例数被设成了 0。这类问题往往不是容量不足，而是策略配置本身埋下了隐患。本文从实际排查角度，带你逐步定位并修复因弹性伸缩策略误配置造成的服务中断。
先确认故障现象：是容量不足还是策略行为异常
服务中断时，不要急着调大实例数。先回答三个问题：
- 监控指标（如 CPU、请求数）是否已触发扩容告警？
- Auto Scaling 活动历史中是否有实例被终止或启动的记录？
- 当前实例数是否低于期望值？
如果实例数低于期望值，很可能是缩容策略误判。例如，某次代码发布后，CPU 使用率骤降（因为请求被阻塞），触发缩容，导致实例数减少，进而放大故障。此时应暂时禁用缩容策略，恢复实例数，再分析根因。
检查最小实例数和最大实例数设置
最小实例数是最关键的防线。很多团队为了节省成本，将最小实例数设为 1 甚至 0，这在生产环境是危险的。AWS 官方文档指出，EC2 提供按需、可扩展的计算容量，你可以根据需要启动任意数量的虚拟服务器，并随时调整。但最小实例数设得过低，当流量波动时，扩容需要时间，而缩容可能瞬间发生，导致容量缺口。建议生产环境最小实例数至少为 2（多可用区部署），并设置合理的最大实例数以控制成本。
检查扩展策略的阈值和冷却时间
常见的误配置包括：
- 扩容阈值过高，例如 CPU 超过 90% 才扩容，但此时已经过载，扩容来不及。
- 缩容阈值过低，例如 CPU 低于 10% 就缩容，但流量毛刺会导致频繁伸缩。
- 冷却时间（Cooldown）设置不当，扩容后立即进入冷却，导致后续扩容被阻止。
AWS 官方建议在部署前进行负载测试，验证策略行为。你可以使用 AWS 的“实例刷新”或手动调整实例数以模拟负载，观察策略是否按预期触发。
确认健康检查配置
如果实例被标记不健康，Auto Scaling 会替换它们。但健康检查的配置可能过于敏感：例如，ELB 健康检查间隔过短，或检查路径返回 5xx，导致实例被频繁替换。此时服务中断可能不是策略问题，而是健康检查误判。检查健康检查的阈值和响应超时，确保其反映真实可用性。
使用 AWS Well-Architected 框架审查配置
AWS Well-Architected 框架提供了成本优化和安全性等支柱的最佳实践。在成本优化支柱中，强调“完全利用所有资源”，但过度追求利用率会导致弹性不足。在安全性支柱中，强调“最小权限”原则，但有时权限配置错误也会导致 Auto Scaling 无法启动实例（例如角色缺少权限）。建议定期使用 Well-Architected 工具审查架构，识别风险。
常见误区与失败条件
- 误区一：认为扩容是瞬时的。实际上，启动实例需要时间（分钟级），因此必须预留缓冲。
- 误区二：只依赖单一指标。例如仅依赖 CPU，而忽略内存或队列深度。
- 失败条件：如果最小实例数设为 0，且所有实例因故障被终止，Auto Scaling 可能无法自动恢复，因为策略可能被禁用或权限不足。
实操步骤：快速恢复服务
- 暂停缩容策略：在 Auto Scaling 组中，将缩容策略的“禁用”开关打开，或手动将期望实例数调高。
- 手动扩容：将期望实例数设置为当前需要的容量，例如 5。
- 检查健康检查配置：确认 ELB 健康检查路径和阈值，避免误杀。
- 调整最小实例数：至少设为 2，并确保多可用区。
- 调整扩展策略：降低扩容阈值（如 CPU 60%），提高缩容阈值（如 CPU 30%），并设置较短的冷却时间（如 300 秒）。
- 逐步恢复策略：先将缩容策略暂停，待稳定后重新启用，并观察活动历史。
参考资料
本文参考了以下 AWS 官方文档：
延伸阅读