磁盘快满的时候，删日志、清缓存通常是第一反应。这些操作能撑一阵子，但日志还会增长，缓存还会再生，过不了几周告警又会回来。真正能解决问题的，是对云盘做扩容，或者把数据迁到性能更合适的新盘上。下面结合一个实际场景，讲清楚操作思路和容易踩的坑。
先想清楚要哪种升级
ECS 的云盘升级大致分两类。一类是容量扩容，盘的类型不变，只把容量调大，多数情况下可以在线完成，业务基本不用停。另一类是性能升级，比如从高效云盘换成 ESSD 云盘。两种云盘类型之间没法直接转换，通常要靠快照或新建磁盘再迁移数据，成本和风险都比扩容高。所以动手前先确认自己要的是哪一种。
如果只是空间不够，扩容基本就能解决。如果是磁盘读写慢、IOPS 跟不上，才需要考虑换盘类型。这时候先看监控里的读写延迟和吞吐，确认瓶颈真的在磁盘上，而不是在数据库查询或应用本身。很多“磁盘慢”的问题，换盘之后并没有明显改善，原因就在这里。
动手前建议先确认下面几件事：
- 磁盘类型和当前容量，在 ECS 控制台的云盘详情页就能看到。
- 文件系统类型，在实例里执行 df -T 或 lsblk -f 即可查到。ext4 和 xfs 的扩展命令不同，别凭印象操作。
- 磁盘上跑的是什么服务。数据库和正在写入数据的任务，最好单独安排操作时间。
- 业务能接受多长的停顿。哪怕只是几分钟，也要提前告诉相关同事，免得他们在导出或上传时突然报错。
扩容本身对业务影响不大，真正容易出事的是实例内的分区和文件系统调整。这一步如果顺序错了，或者命令用错了，可能造成分区异常，恢复起来比扩容本身麻烦得多。
案例：一台电商后台服务器的扩容经过
某小型电商团队的后台服务器挂载了一块 100GB 的数据盘，运行一年后使用率达到 86%，订单导出任务经常因为空间不足而失败。团队最初打算直接新购一台更大的实例，把服务整体迁过去。评估之后发现，问题只出在数据盘容量上，扩容就能解决，迁移整个实例反而费时费力，还要重新调整配置和访问地址。
他们最终按下面的顺序处理：
- 在 ECS 控制台为该数据盘创建快照。快照是回滚的保障，要在扩容前完成，而且要确认快照状态为可用，再进行下一步。
- 在云盘管理页面选择扩容，把容量从 100GB 调整到 300GB。控制台显示扩容完成后，再进入实例操作，不要急着在页面还没刷新时就动手。
- 登录实例，用 lsblk 确认系统已经识别到新容量。如果分区表还是旧的，就需要用 growpart 扩展分区。部分发行版需要先安装 cloud-utils-growpart 这类工具包。
- 根据文件系统类型执行对应命令。ext4 用 resize2fs，xfs 用 xfs_growfs。两者的操作对象也不同，xfs 需要指向挂载点，写错了会白白浪费时间。
- 用 df -h 确认挂载点的可用空间已经变化，再回归测试导出功能，确认业务链路正常。
整个过程大约 20 分钟，业务没有中断。团队事后的经验有两点。第一，快照一定要在扩容前做，哪怕操作看起来很简单。第二，文件系统类型必须提前确认，否则很容易把命令用错。
常见风险与注意事项
第一，云盘扩容只能增大，不能缩小。如果未来想把盘变小，只能新建一块小盘，再把数据迁移过去。这一点在采购之初就要考虑清楚，尤其是按量计费的场景，盘越大，费用越高，而且没法直接退回去。
第二，系统盘扩容要留意镜像和操作系统的兼容性。部分旧镜像在扩容后需要重启，系统才能识别新容量。这类操作建议先在测试实例上走一遍，确认没有问题再对生产环境动手。重启本身也是一次业务中断，需要单独评估。
第三，如果磁盘挂载了数据库或正在写入的服务，最好选择业务低峰期操作，并在扩容前做一次数据备份。快照能回滚磁盘状态，但对正在写入的数据库来说，最好还是先做逻辑备份，多一层保险。
第四，性能升级会涉及云盘类型变更，费用和性能指标都会有变化。建议先在控制台的价格计算器里核对费用，再结合实际的 IOPS 和吞吐需求决定是否升级。配置不是越高越好，选到刚好够用的那一档，通常更划算，也更容易在后续复盘时说清楚。
阿里云升级硬盘的核心流程并不复杂：先判断需求，做好快照，再在实例内完成文件系统调整。遇到限制条件或版本差异时，以阿里云官方文档和控制台提示为准，不同地域和镜像的细节可能会有出入。每次操作后把步骤和结果记下来，下一次遇到磁盘告警，就能照着处理，不必从头摸索。
