前言 我有一个文件夹，叫 scripts/。

里面是我三年运维攒下来的自动化脚本：自动清理日志、自动重启服务、自动封IP、自动续证书。

上个月，我把它们全删了。

不是它们不能用，是它们太危险了。

先说一个真实的事故 去年夏天，我写了一个自动清理日志的脚本。

逻辑很简单：每天凌晨3点，扫描 /var/log/ 目录，删除7天前的 .log 文件。

跑了三个月，没出过问题。

直到有一天，Nginx的access.log被我的脚本删了。但Nginx进程还持有这个文件的句柄，继续往里写。

磁盘没释放。 df显示磁盘使用率还是95%。我的脚本删了个寂寞。

更糟的是，logrotate第二天来轮转日志，发现access.log不见了，直接报错。Nginx因为无法写入日志文件，开始拒绝请求。

网站挂了两个小时。

我的脚本错在哪 复盘之后，我发现了三个问题：

问题一：没检查文件是否被进程持有。

Linux的文件删除机制：rm只是删了目录项。如果进程还持有句柄，文件数据不会被释放。我的脚本不知道这件事。

问题二：没排除活跃日志。

Nginx的access.log是活跃文件，正在被写入。我的脚本只看“修改时间超过7天”，没看“是否正在被写入”。

问题三：没和logrotate协调。

logrotate有自己的轮转逻辑。我的脚本和它各干各的，互相打架。

这三个问题，一个脚本根本处理不了。

我写了多少脚本 我数了一下，三年下来写了23个运维脚本：

磁盘清理：5个（不同目录不同策略）

服务重启：4个（Nginx/MySQL/Redis/PHP）

SSH封禁：3个（不同阈值不同封禁时长）

证书续期：2个（Let's Encrypt/certbot）

日志轮转：3个（Nginx/Apache/自定义）

进程监控：4个（内存/CPU/僵尸/端口）

其他：2个

23个脚本，23个潜在的事故点。

每一个脚本都只解决一个问题，但每一个脚本都可能引入新问题。

后来我换了一个思路 与其维护23个脚本，不如用一个统一的工具。

这个工具要能做到：

删日志前检查文件是否被持有

重启服务前检查配置是否正确

封IP前检查是否是自己人

所有操作有安全约束，不会越修越坏

这就是ServerGuard的设计出发点。

它是怎么处理日志清理的 不是简单看“修改时间”，是6层检查：

第一层：是否在保护目录（数据库/配置/源码/会话文件）→ 是则跳过 第二层：是否是压缩或轮转文件（.gz/.1/.old）→ 否则跳过 第三层：是否被进程持有句柄 → 是则跳过 第四层：是否是活跃日志文件（最近1小时内有写入）→ 是则跳过 第五层：是否超过30天 → 否则跳过 第六层：清理后磁盘是否真的释放了 → 否则告警 6层全过才执行。 我的脚本只过了第二层和第五层。

23个脚本 vs 1个工具 我的脚本 ServerGuard 安全检查层数 0-2层 11项检查链 白名单保护 没有 45+进程 熔断机制 没有 连续失败3次暂停 Kill预算 没有 15次/小时 配置预检 没有 nginx -t等 可解释性 自己写的自己懂 代码开源可查 我并不是说脚本没用 脚本适合处理确定性的、一次性的、低风险的任务。比如：

备份数据库

同步文件到远程

生成日报

但脚本不适合处理“有风险、有边界条件、有副作用”的任务。 比如自动清理日志、自动重启服务、自动封禁IP。

因为这类任务需要判断力。而判断力，需要安全约束来兜底。

总结 如果你还在维护一堆运维脚本，问自己一个问题：

这些脚本在异常情况下会做什么？

如果答案不确定，那它们迟早会出事。

GitHub搜 ServerGuard，代码开源，Apache 2.0协议。看看它是怎么用11项检查链兜底的。

项目地址：

GitHub：suoten/ServerGuard

Gitee：suoten/ServerGuard

你写过多少个运维脚本？出过事吗？评论区聊聊。