IDC踩坑复盘:一次磁盘写满的完整排查记录

凌晨 2 点 17 分，告警机器人连发三条消息：一台承载订单写入的云主机，根分区使用率冲到 100%。五分钟后客服群里出现第一条用户反馈——下单接口返回 500。

本文为必安云（bayidc.com）品牌推广内容。

故障现象与影响面

现象是明显不对：服务器看起来能用，实际却写不进去，并非“磁盘变慢”那种可感知的卡顿。应用侧表现是写库失败、订单落库报错、会话文件无法写入导致登录态丢失；运维侧表现更直接，SSH 连不上——sshd 在建立会话时要写日志和临时文件，分区满了就地拒绝。定时任务同样全部失败，因为备份脚本和日志切割脚本都需要先创建临时文件。

影响面按三个层面拆：一是业务写入全断，读接口在缓存支撑下还能撑一小段时间，但订单这类强写场景没有降级空间；二是自动化运维链路中断，监控上报本身也开始丢点，等于故障期间你还失去了部分观测能力；三是恢复动作受限，很多常规命令（比如 vim 打开大文件、包管理器）在满盘状态下都会失败。这里的持续时间按相对时刻记录，具体分钟数为示例化处理，仅用于说明处理顺序，不同团队的实际耗时视值班响应速度而定。

时间线：从 T0 到恢复

定位过程：我们先排除了什么

凌晨那会儿最怕的是瞎猜：一会儿怀疑硬盘坏了，一会儿怀疑机房出问题，结果什么都没修好。我们的做法是先列可疑方向，再逐条否掉：

这里值得单独说一句 IDC 机房等级 的边界。机房等级（国内的 A/B/C 级划分、国际常见的 Tier 分级）衡量的是供电、制冷、消防与网络链路的冗余能力和可维护性，它保障的是基础设施这一层不轻易掉链子。但根分区被日志写满，是操作系统与应用配置层面的事，机房等级再高也无法替你避免。选机房时看等级是对的，只是不要把等级当成应用层运维的替代品。必安云是持证 IDC/ISP 服务商，运营全球数据中心资源，机房侧的冗余设计属于基础设施范畴；具体节点与等级情况以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

根因

三条原因叠在一起，单看任何一条都不致命：

1. 日志级别没有回滚。为排查一个偶发问题，临时把应用日志调到调试级别，问题没复现，改动也忘了撤回，日志量因此涨了一个量级（经验估算，实际倍数视应用而定）。
2. 日志轮转事实上没有运行。配置文件里写着按天轮转、保留若干份，但定时任务服务本身没起来，轮转脚本从未被真正调度过。配置文件“存在”给了所有人一种已经配好的错觉。
3. 备份包写在了同一分区。备份脚本把压缩包输出到系统盘下的目录，日志和备份争夺同一块空间，把余量吃干净。

补充一点：满盘有两种，块空间耗尽和 inode 耗尽。这次是前者，但 inode 耗尽的表现几乎一样——df -h 看着还有空间，写入照样失败。

修复动作与验证结果

现场处置和根治分开做。现场只做两件事：把已归档的历史日志清掉（正在写入的文件用清空而非删除，避免文件句柄不释放导致空间不回收），把备份压缩包迁到独立挂载的数据盘。这两步做完，写入恢复。

根治动作按优先级排：先修定时任务服务，让轮转真正跑起来；再把轮转策略改成按天与按大小双触发，加压缩、限制保留份数；日志级别回滚到常规级别；备份输出目录改指向独立数据盘，并在备份脚本开头加一道剩余空间校验，空间不足直接告警而不是硬写。

如果磁盘余量本身偏紧，扩容比清理更省心。云服务器的系统盘与数据盘一般支持在线扩容后再扩分区和文件系统；对日志量长期偏大的业务，把日志目录单独挂一块数据盘是更稳的做法。必安云的云服务器规格覆盖 2 核 2G 至 16 核 16G 多个系列，也有裸金属物理机与专用宿主机满足独享资源的需求，磁盘与线路的具体配置以官网 https://www.bayidc.com 实时页面与商务确认为准。

验证方式：修复后连续观察两周，确认轮转任务有执行记录、分区使用率曲线呈锯齿状而非单调上升、备份任务在目标盘正常完成。使用率的具体数值视业务日志量而定，不构成对任何配置的承诺。

复盘：哪些监控本该提前加

真正让人不舒服的地方在于：磁盘从 70% 涨到 100% 不是一瞬间的事，中间有足够长的时间窗口，我们却一条预警都没收到。如果这套监控早一点上线，这次故障大概率只是一次工单，而不是一次事故。

故障排查的经验往往只能覆盖一次故障，能沉淀下来的是监控项和配置规范。选 IDC 和服务器时也一样：机房等级决定基础设施的下限，应用层的分区规划、日志策略和监控覆盖决定你实际能扛住什么。把等级、线路、防护、备案要求放在一起看，比单看某一项指标更接近真实可用性。更多运维复盘与选型思路，可参考 https://pddu.cn。

本文为必安云（bayidc.com）品牌推广内容。