云服务器磁盘写满引发服务雪崩？一次从告警到根因的完整排障实录

凌晨两点，手机连续弹出云监控告警：弹性云服务器 ECS 的系统盘使用率突破 90%，紧接着业务侧开始出现 502 与数据库写入失败。登录控制台查看监控曲线，磁盘使用率在 40 分钟内从 68% 直线拉升到 100%，应用日志随即开始刷出 No space left on device。这是一次典型的磁盘写满故障：表面上看是磁盘满了，实质是某个环节失控后持续写入的结果。处理这类故障的关键顺序是先恢复写入能力止血，再定位根因，最后做长效预防。如果顺序颠倒，很容易误删关键数据，或者刚清完空间又被迅速写满。

一、故障现象与初步判断

磁盘写满的表象往往不止一种：应用写入失败、数据库拒绝写入、无法登录、定时任务报错，甚至 SSH 登录后连命令补全都卡顿。先通过云监控确认磁盘使用率曲线与故障起始时间，再登录服务器验证。需要区分三种情况：磁盘空间真的满了、inode 耗尽导致无法新建文件、以及挂载点异常导致写入失败。三种情况的表象相似，但处理方法完全不同，误判会浪费大量时间。

二、定位磁盘：df 与 du 的组合拳

登录服务器后，第一步不是急着删除文件，而是先看清全局。df -h 查看各挂载点使用率，确认是哪块盘满了；df -i 查看 inode 使用率，排除 inode 耗尽导致的“明明有空间却写不进”的情况。随后用 du -sh /* 逐层下钻定位占用最大的目录，再用 du -sh /var/log/* | sort -rh | head -n 20 列出最大的日志文件。这一组命令通常能在两分钟内把“元凶”锁定到目录级。需要注意，du 看到的是文件实际占用，而 df 看到的是已分配空间，两者不一致时往往意味着有文件被删除但仍被进程占用。

三、四大“隐形杀手”

第一是被删除却未释放的文件。Linux 下文件被 rm 删除后，只要仍有进程持有句柄，磁盘空间就不会释放。用 lsof | grep deleted 可以找到这类文件，处理方法是重启持有进程或通过截断句柄对应的文件描述符来释放空间，而不是反复删除。第二是失控的日志。应用在 DEBUG 级别下持续输出，或某个循环报错每秒写几百行日志，一夜就能写满几十 GB。第三是容器层。Docker 的 overlay2 目录、悬空镜像与未清理的容器日志常常在不知不觉中吃掉上百 GB，docker system df 与 docker system prune 是常规清理手段。第四是 inode 耗尽。小文件数量过多会先耗尽 inode，此时 df -h 显示仍有剩余空间，但任何写入都会失败，容易误判为权限问题。

四、应急止血：安全清理的正确顺序

止血要遵循“先截断、后归档、再删除”的顺序。对正在写入的大日志优先用截断方式清零，而不是 rm，截断能立即释放空间且不影响进程句柄。确认不再需要的旧日志、临时文件与安装包缓存可以删除，但删除前务必确认目录归属，避免误删数据库数据文件与备份。数据库的 binlog、慢查询日志要按保留策略清理，不能直接清空正在使用的文件。清理完成后用 df -h 与业务健康检查确认服务恢复，再逐步放开限流。整个过程建议保留操作记录，便于事后复盘。

五、根因修复：让问题不再复发

应急处理完只是治标，根因修复要解决“为什么会被写满”。日志方面，给应用与系统日志配置 logrotate，按大小或时间轮转并设置保留份数与压缩；容器日志配置 max-size 与 max-file，限制单个容器日志上限。监控方面，在云监控服务中把磁盘使用率告警阈值设在 80% 与 90% 两档，并配置磁盘剩余空间绝对值告警，避免“百分比正常但绝对空间不足”的盲区。容量方面，对增长快的业务盘定期评估扩容，核心业务建议把日志盘、数据盘与系统盘分离部署。最后把磁盘使用率纳入日常巡检清单，每周看一次趋势曲线，增长异常时提前介入。

六、排障方法论：分层定位，先止血后根因

这次故障复盘下来，最值得沉淀的不是某一条命令，而是一套分层定位的思路：先看监控曲线确认故障范围与起始时间，再分层排查系统层、中间件层、应用层，每一层用最小代价的只读命令验证假设，确认后再动手处理。排查时坚持“先止血、后根因、再预防”，避免在故障进行中做高风险操作；操作前先确认备份与回滚路径，关键删除类操作先列清单再执行。云上排障还有一个优势：控制台、云监控与日志服务提供了开箱即用的观测手段，善用这些工具往往比登录服务器逐条翻日志更快。把这套方法沉淀为团队的排障手册，下一次告警响起时，就能按图索骥而不是凭感觉救火。

磁盘写满看似是运维小事，实则是对监控、日志管理与容量规划的综合考验。希望这次实录能帮你在遇到类似问题时少走弯路，也欢迎在评论区分享你遇到过的奇葩磁盘故障。