ECS 升配后别只看控制台：重启、规格与业务验证清单

一、背景与问题

业务量上来之后，最常见的扩容动作就是给弹性云服务器 ECS 升配：CPU 从 2 核升到 4 核，内存从 4 GiB 升到 8 GiB，或者同时把带宽和系统盘规格一起调整。控制台上点几下就能提交变更，很多人就以为事情做完了。实际上，控制台显示的新规格只是云平台侧的配置已经生效，操作系统里、业务进程里、监控里是不是真的用上了新规格，还需要一步步核对。

最容易踩的坑有三类：第一，实例没有按要求重启，操作系统仍然跑在旧的资源视图里；第二，应用本身有限制，比如 JVM 堆内存、数据库连接池、Nginx worker 进程数还是按旧规格写的，升配没有转化为吞吐；第三，变更窗口没有留验证时间，业务看起来正常，但高峰一来才发现某个依赖没有跟上。

本文给出一份可直接照做的清单：变更前先留基线，变更中按重启规则操作，变更后从规格、系统、进程、业务四个层面验证，最后列出常见坑和回退思路。文中命令以 Linux 常见的发行版为例，适用于大多数云服务器镜像。

二、前提与准备

在动手之前，先确认四件事。第一，确认当前实例的计费方式与变更规则。按量付费实例与包年包月实例的变更入口和生效方式可能不同，变更前先在控制台核对目标规格、价格变化和生效提示，不要只看规格名称。第二，确认业务是否允许重启。升配通常需要关机或重启才能生效，如果业务不能停，先安排变更窗口，或者先做主备切换。第三，确认数据已经有可用的备份或快照。升配本身不改动数据盘内容，但任何涉及关机和重启的操作，都值得先确认最近一次备份是可用的。第四，留一份基线。把变更前的 CPU 核数、内存、负载、关键进程状态和业务响应时间记下来，否则变更后无法判断是变好了还是变差了。

基线命令可以先跑一遍并保存输出：

nproc
free -h
uptime
lsblk
df -h
ss -tlnp | head -20

nproc 看 CPU 核数，free -h 看内存总量，uptime 看负载和运行时间，lsblk 和 df -h 看磁盘挂载情况，ss -tlnp 看关键端口是不是在监听。把这些输出贴到变更记录里，后面验证时逐项对照。

三、分步操作

第 1 步：在控制台提交升配

进入弹性云服务器控制台，找到目标实例，确认实例名称、区域和当前规格没有选错。选择变更规格，挑到目标规格后，认真核对 CPU、内存、带宽和磁盘信息。提交前再看一次价格提示和生效说明，确认是否需要关机或重启。如果提示需要关机，不要在业务高峰直接点提交，先按窗口计划走。

第 2 步：按规则重启实例

如果变更要求重启，先在实例内做一次优雅关机准备：通知业务方，停止对外写入的关键任务，确认没有正在跑的长事务。可以在实例内先执行一次同步写入，再从控制台重启：

sync

重启后不要马上判断结果，等实例状态回到运行中，再登录检查。有些实例重启后需要一点时间完成云平台侧的初始化，急着登录可能会看到旧的监控数据。

第 3 步：核对操作系统看到的规格

登录实例后，先跑基线命令的对应项，逐项比对：

nproc
free -h
cat /proc/cpuinfo | grep -m 1 "model name"
uptime

nproc 的结果应当等于新规格的核数，free -h 的 total 应当接近新规格的内存。注意内存总量会因为系统保留和单位换算略小于标称值，这是正常的，关键是数量级要对得上，不能还停留在旧规格。uptime 的运行时间应当是重启后的新时间，如果运行时间还是几天前，说明这次重启没有真正生效，要先排查重启流程。

第 4 步：核对业务进程与配置上限

规格变了，应用配置不一定跟着变。逐项检查：第一，Java 应用看启动参数里的堆内存上限，比如 -Xmx 是不是还按旧内存写死的；第二，数据库看连接池和缓存配置，是不是还按旧内存预留的；第三，Web 服务看 worker 进程数和连接数上限，是不是还按旧核数配置的；第四，定时任务和队列消费者的并发数，是不是还停留在旧值。

检查进程与监听端口的常用命令：

ps aux --sort=-%mem | head -20
ss -tlnp
systemctl status nginx
systemctl status mysql

上面最后两条按实际服务名替换。如果服务没有用 systemd 管理，就用对应的进程管理命令。重点是确认关键服务在重启后已经正常拉起，而不是只看实例状态是运行中。

第 5 步：做一轮业务验证

先做健康检查：打开业务首页或健康检查接口，确认能正常返回；再登录后台或跑一条只读查询，确认数据库连接正常；最后挑一个核心写流程，在测试账号或灰度流量下走一遍，确认写路径没有因为重启丢配置。验证时顺手看一眼日志的最新时间戳，确认日志在重启后还在正常滚动，而不是停在重启前。

curl -I https://example.com/health
journalctl -u nginx --since "30 minutes ago" | tail -50

把上面地址换成自己的健康检查地址。journalctl 的服务名同样按实际替换。如果业务没有健康检查接口，至少要人工打开一次核心页面，不能只看进程在就下结论。

四、验证清单

变更完成后，按这张表逐项打勾，全部通过再算完成：

• 控制台规格：实例详情里的 CPU、内存与目标规格一致。
• 操作系统规格：nproc 与 free -h 与目标规格数量级一致。
• 重启状态：uptime 显示为重启后的运行时间，系统日志有重启后的新记录。
• 关键服务：业务进程、数据库、缓存、消息队列都已拉起，监听端口正常。
• 应用上限：JVM 堆、连接池、worker 数等关键参数已经按新规格复核，不再是旧值。
• 业务验证：首页、登录、核心读流程和核心写流程都通过。
• 监控验证：CPU、内存、磁盘、网络监控曲线在重启后恢复正常，没有持续告警。
• 费用验证：控制台账单或价格提示与预期一致，没有多出意料之外的规格。

建议把这份清单和基线输出一起保存到变更记录里。下次再升配或降配时，直接拿这份记录对照，能省下大量排查时间。

五、常见坑

第一个坑是只看控制台不看系统。控制台显示新规格，不代表操作系统已经生效，凡是需要重启的变更，都要以 nproc 和 free -h 的结果为准。第二个坑是重启了实例但服务没拉起。有些服务没有设置开机自启，重启后进程不在，业务端口也不监听，实例状态却是运行中，很容易误判。第三个坑是应用上限没改。升配后 CPU 和内存上去了，但 JVM 堆还是旧值，连接池还是旧值，瓶颈只是从系统层转移到了应用层，压测时还是会先满。第四个坑是监控窗口太短。刚重启时负载低、曲线好看，高峰还没来就宣布成功，等高峰一到才发现某个依赖没跟上。第五个坑是没有回退计划。升配前没有记下旧规格和旧配置，万一新规格有兼容问题，想降回去还要重新翻记录。

还有一个容易被忽略的点：升配不等于扩容磁盘。如果业务瓶颈在磁盘空间或磁盘吞吐，单纯升 CPU 和内存解决不了问题，要先用 df -h 和磁盘监控确认瓶颈到底在哪一层，再决定是升规格、扩磁盘还是优化应用。

六、小结清单

升配的正确顺序是：留基线、确认窗口和备份、控制台提交、按规则重启、核对系统规格、复核应用上限、走业务验证、保存变更记录。控制台只是第一步，系统命令、进程状态和业务验证才是真正完成的标准。下次升配时，直接按本文第四节的八项清单逐项打勾，全部通过再关闭变更单，这样既不容易漏项，出问题时也有据可查。