服务器磁盘满那天，我经历了一次完整的线上事故

目录

一、事故背景（很普通，但很危险）

二、事故发生：第一个异常信号

三、告警来了，但已经有点晚了

四、真正的致命一击：磁盘写满了

五、为什么磁盘满会直接“拖死”服务？

1.日志写不进去了

2.PostgreSQL 开始拒绝写入

3.服务开始“自我保护”

六、真正的根因：不是“突然满”，而是“早就满了”

七、我们是怎么止血的？

1.紧急清理日志

2.重启数据库和服务

3.临时关闭非必要服务

八、事后复盘：这次事故暴露了什么问题？

❌ 以为“磁盘够用”

❌ 以为“小业务不会出事”

❌ 没有磁盘监控

❌ 没有日志轮转策略

九、如果让我重来一次，我一定会做这几件事

十、为什么我要把这次事故写出来？

十一、这篇文章你应该带走的只有一句话

一个低级问题，如何一步步把服务拖垮

我一直以为，“磁盘满”这种问题，不可能出现在我负责的服务器上。

直到有一天凌晨，我被一连串告警吵醒。

这篇文章不是教程，也不是炫技，而是一次非常真实、非常典型的线上事故复盘。 如果你以后要碰服务器、数据库、后端服务，这种事故你一定会遇到。

一、事故背景（很普通，但很危险）

• 一台 Linux 服务器

• 上面跑着：

  • PostgreSQL 数据库

  • Java 后端服务

• 业务规模不大

• 服务器配置也不算低

所有条件看起来都“很安全”。

二、事故发生：第一个异常信号

最早的异常，不是服务挂掉，而是：

• 业务接口开始 偶发超时

• 日志里开始出现零星错误

• 但服务并没有完全不可用

这是一个非常典型的“前兆阶段”。

现在回头看，这是系统在“拼命挣扎”。

三、告警来了，但已经有点晚了

很快，监控开始报警：

• 数据库连接异常

• 接口错误率上升

• 服务重启次数增加

但当时我们第一反应是：

“是不是代码问题？” “是不是数据库连接池没配好？”

这是一个非常人性的误判。

四、真正的致命一击：磁盘写满了

当我真正登录服务器，第一条命令是：

df -h

结果非常刺眼：

/dev/sda1 100% /

根分区满了。

而且不是刚满，是已经满了一段时间。

五、为什么磁盘满会直接“拖死”服务？

很多新手会觉得疑惑：

磁盘满了，为什么服务会直接出问题？

真实原因是：

1.日志写不进去了

• Java 服务还在跑

• 但日志无法写入

• 部分框架直接抛异常

2.PostgreSQL 开始拒绝写入

数据库需要持续写：

• 数据文件

• WAL 日志

• 临时文件

当磁盘满时：

• PostgreSQL 会直接进入异常状态

• 新连接开始失败

3.服务开始“自我保护”

• 连接失败

• 异常堆积

• 应用线程被拖死

• 最终被系统或监控重启

整个系统开始连锁反应。

六、真正的根因：不是“突然满”，而是“早就满了”

事后复盘发现：

• 日志长期没有轮转

• 数据库日志 + 应用日志一起堆

• 磁盘使用率早就超过 80%

• 但没有任何磁盘告警

换句话说： 这是一个“早就该被发现”的问题。

七、我们是怎么止血的？

事故当下，所有“高级优化”都没意义，只能做三件事：

1.紧急清理日志

du -sh /var/log/*

删掉无用历史日志，立刻释放空间。

2.重启数据库和服务

在磁盘有空间后，服务才能真正恢复。

3.临时关闭非必要服务

减少磁盘和 IO 压力，防止二次事故。

八、事后复盘：这次事故暴露了什么问题？

❌ 以为“磁盘够用”

❌ 以为“小业务不会出事”

❌ 没有磁盘监控

❌ 没有日志轮转策略

而这些问题，和代码水平几乎没关系。

九、如果让我重来一次，我一定会做这几件事

十、为什么我要把这次事故写出来？

因为我见过太多新人：

• 学会了 Docker

• 学会了数据库

• 学会了写服务

却栽在最基础的问题上。

服务器事故，往往不是技术难度高，而是忽略了基础。

十一、这篇文章你应该带走的只有一句话

磁盘满，不是“如果会出事”，而是“什么时候出事”。