业务量涨起来以后，服务器变慢是很多站长都会遇到的事。高峰期页面转圈，数据库查询迟迟不返回。这时升级配置通常是最快的办法，但实际操作细节不少，选错规格、没算清停机时间、磁盘扩了却没分区，都会让问题换个样子再出现。下面按判断时机、升级方式、操作前准备、操作步骤和升级后检查的顺序讲一遍，中间穿插一个实际案例。
先看监控，别凭感觉加配置
加配置之前，先去阿里云云监控里看一段时间的数据。CPU、内存、磁盘IO、网络带宽都有曲线。别只看当前值，要看峰值和均值各是多少，高点持续了多久。如果只是偶尔冲高一次，问题可能不在规格上。
下面几种情况，可以考虑升级：
- CPU长期高于70%，且高峰时段持续超过30分钟，说明计算能力基本用满了；
- 内存使用率持续超过85%，同时Swap频繁换入换出，系统会明显变慢；
- 磁盘使用率超过80%，或者IOPS长期打满，数据库写入就会排队；
- 带宽峰值反复顶到上限，页面加载变慢，用户开始反馈。
单看一个指标偏高，不一定是规格不够。CPU高也可能是某个进程死循环，内存高可能是缓存参数设得太大。先查清原因，再决定升配还是改代码，通常更省事。
升配还是换型
ECS实例升级一般分两种。一种是在原规格族里加CPU核数或内存，叫升配。另一种是换到另一个实例族，比如从通用型换成计算型或内存型，叫换型。
两者的差别主要在操作难度和停机时间。同一规格族内调整，一般要先停止实例，停机时间相对短。跨规格族迁移可能要处理镜像，或者新建实例再切换，需要提前规划。是否需要停机，以控制台的提示为准。
如果业务是Web应用加MySQL，两台机器的侧重点通常不同。应用服务器多数情况下先看CPU核数，数据库服务器更依赖内存和磁盘性能。盲目买高配划不来，要把资源加在真正的瓶颈上。
操作前要准备的事
升级操作本身不难，出问题多半出在准备阶段。开始前做好以下几件事：
- 给系统盘和数据盘做快照。升级后如果异常，可以直接回滚到快照。
- 选访问量最低的时段，比如凌晨。提前在站点上发维护公告，告诉用户可能短暂不可用。
- 确认IP和绑定关系。应用是否写死了内网IP，公网IP是否需要保留，弹性公网IP或负载均衡的绑定会不会受影响，都要先查。
- 单独备份数据库。快照能恢复整盘，但数据库做一次逻辑备份，恢复时更灵活，也更方便核对数据。
- 记下当前配置。包括实例规格、磁盘分区、服务启动参数。升级后拿来对照，能快速看出哪一项变了。
同规格族内升配的操作步骤
以同规格族内升级CPU和内存为例，步骤大致如下：
- 登录阿里云ECS控制台，进入目标实例详情页。
- 确认实例状态是“运行中”，点击“更多”，在“实例设置”里找到“升级实例规格”或“配置变更”入口。
- 选定目标配置。提交前看一下价格变化和库存提示。如果目标规格库存紧张，订单可能失败，需要换一个规格。
- 提交订单后，按页面提示停止实例，等待变更完成。
- 实例重启后，通过SSH登录，检查CPU核数和内存是否已经生效。
如果还要扩容磁盘，系统内部还得处理分区和文件系统。先执行lsblk或df -h，确认新容量已被系统识别。然后用growpart扩展分区，再根据文件系统类型执行resize2fs（ext4）或xfs_growfs（xfs）。磁盘操作一旦出错，修复起来麻烦，建议先在测试环境走一遍。
案例：一个电商小站的升级过程
某垂直领域电商站点，日均访问量两万左右，最初用一台4核8G的ECS同时跑Web应用和MySQL。促销期间，平均响应时间从200毫秒涨到3秒以上。监控显示内存长期超过90%，Swap使用频繁，磁盘IO等待也偏高。
运维团队没有直接翻倍配置，而是先做了三件事。第一，查看慢查询日志，找出几条没有建索引的商品筛选语句，补上索引。第二，把MySQL的innodb_buffer_pool_size调整到和内存规模相匹配。第三，把Web应用的会话存储迁到Redis。做完这些，内存占用回落到65%左右。
之后团队才把实例升到8核16G，同时把系统盘从40G扩到100G。升级安排在凌晨两点，动手前建了快照，停机约12分钟。升级后，高峰期平均响应时间稳定在400毫秒以内，促销期间没有再出现明显卡顿。
这个案例里，升配是最后一步。先把慢查询和内存配置理顺，再升级，通常比一开始就堆资源更省钱，后续也更稳。
升级后的检查
升级完成后别急着下结论，至少观察24小时。重点看这几项：
- CPU、内存、磁盘和带宽曲线是否回到合理范围；
- 应用和数据库是否正常启动，日志里有没有新增报错；
- 定时任务和系统参数（比如ulimit、内核参数）是否需要跟着配置调整；
- 账单和预期是否一致。按量付费和包年包月混在一起时，最容易多扣费。
还有一点要提前确认。部分配置变更后，实例的公网IP可能会变。如果域名解析或第三方白名单依赖固定IP，最好在变更前确认好，不要等业务报错才发现。
阿里云服务器升级配置本身不复杂，但要以准确的监控数据为依据，做好完整备份，并按步骤操作。把升级当成一次正式变更来做：先排查，再优化，最后扩容，每一步都留好回退的余地。
