华为云弹性云服务器自动化运维实践：自定义镜像 + 弹性伸缩组 + 定时伸缩策略

这篇记录我搭建一套「测试环境按需伸缩」的完整过程。之前测试环境的 ECS 是常年开着的，白天用得多、晚上闲置，一个月电费和公网带宽费白白浪费了一截。想改成用弹性伸缩 AS 统一管理，但真正动手时踩了几个坑——镜像里的依赖没装全导致新实例起来就崩、伸缩组实例没绑 EIP 导致外网访问不通、定时策略的冷却时间设短了来回抖动。这里把完整的方案和排错过程都写下来。

一、先把目标拆清楚

我的诉求很具体：工作日 9:00 到 21:00 至少保持两台实例，其余时间缩容到零；遇到压测需要扩容时，手动加到五台，压测结束再缩回去。也就是说，我要的不是「弹性」这个概念，而是三个具体能力：批量创建同规格实例、按时段自动调整数量、以及在需要时临时手工介入。围绕这三点去配置，比照着文档从头到尾走一遍要清晰得多。

二、制作一个可复用的自定义镜像

这一步是整套方案的地基。直接用公共镜像建伸缩组也能跑，但每次新建实例都要走一遍初始化脚本，耗时且容易在初始化失败时留下半成品实例。所以我先手动装好一台 ECS，装上常用的监控 agent、日志采集 agent、以及我自己的业务依赖（Python 环境、字体、时区设置），然后在控制台「创建镜像」把它固化成私有镜像。

这里有个关键细节：创建镜像时一定要选「关机状态」或者在创建前把实例停机，否则快照出来的磁盘文件可能处于写入中的不一致状态。我第一次没关机就做镜像，结果扩容出来的实例上某个服务进程莫名其妙起不来，同样的包手动装却没问题——查下来就是那次快照里的文件没落盘。停机后重建镜像，问题再没出现过。另外私有镜像要和伸缩组在同一个可用区，跨可用区调度会直接报错，这一条官方文档里有，但我是在第一次扩容失败时才发现的。

三、配置弹性伸缩组和实例模板

伸缩组的配置核心是「实例模板」：启动配置、镜像、密钥对、安全组、子网、弹性公网 IP 都要在这里定死。我的做法是安全组只放行业务端口和管理端口的白名单，把所有出站流量放开（后续有收紧计划），EIP 直接绑在模板上而不是绑在组里的实例上，这样不管组内实例怎么换，公网入口地址始终不变。

实例规格这块我踩了个坑：一开始为了省成本，模板里把规格设成了 4 核 8G，但压测时发现扩容出来的实例在同一个伸缩组里表现差异很大。后来查到是伸缩组内部实例的实际规格会按配置类型浮动，配置为「固定」才能保证每台实例规格完全一致。所以我把模板改成固定规格，虽然单价高一点，但扩容出来的机器性能可预期，压测数据才有可比性。

四、用定时策略实现按时段伸缩

定时伸缩策略是按时间段配置期望实例数的，最少实例数设为零即可实现「夜间完全缩容到零」。我设置了三条策略：工作日 9:00 期望两台、21:00 期望零台、周末全天零台。策略之间有重叠时段时，平台按期望值较大的那条生效，这一点和我的直觉一致，不需要额外处理。

真正让人烦躁的是冷却时间。刚设置时我把冷却时间设成了 60 秒，结果某个健康检查短暂失败触发了缩容，紧接着又触发了扩容，来回抖了七八分钟，前端请求在这个过程中时好时坏。冷却时间调大到 300 秒之后抖动消失了，我的理解是：冷却期是给健康检查和业务自愈留的窗口，窗口太短，AS 会在「实例还没真正恢复」的时候又做一次决策。经验值是，健康检查周期 × 2 到 × 3 是个合理的起点，再根据实际的恢复时间调整。

五、健康检查和告警不能省

健康检查配错了，AS 会把已经正常的实例判成异常并替换掉，还不带任何通知，只能靠用户自己发现流量掉了。我的健康检查走的是 HTTP 探测业务健康接口，同时在伸缩组里挂了两个告警：一个是实例数量变化通知，一个是实例状态异常通知。告警接企业微信机器人之后扩容失败也能第一时间看到。这一步花的时间不多，但省下的是半夜排查的凌晨。

六、几个容易忽略的收尾

第一，伸缩组闲置时记得保留组本身但把期望实例数置零，不要把组删掉，否则下次还要重建模板。第二，业务侧的连接池要能承受实例数变化，尤其是扩出来的实例上服务注册到注册中心后，扩缩容的节奏要错开，否则瞬间上来二十台机器同时注册也会把注册中心打挂。第三，缩容前确保实例上没有任何未落盘的数据，我在业务里统一加了优雅退出的信号处理，收到缩容通知后先摘流量再退出，这样才不会出现正在处理的请求被硬生生掐断。

小结：这套方案跑了一个多月，测试环境的常驻成本降了大概六成，而白天高峰期的响应延迟基本没有变。回头看，弹性伸缩真正省下来的不只是机器钱，还有「扩容这件事不用人肉操作」带来的确定性。这一套配置我已经复制到两套预发环境上，唯一的区别是实例规格和定时策略的时间窗，模板本身完全复用。