# 40G云盘快满了，敢让Skill自动删除吗？

> 告警是容量信号，不是删除许可。

```text
[读者] 把运维动作交给 Skill 的一线工程师
[痛点] 告警一来，第一反应就是先删日志
[现在读] 误删只差一个通配符，回滚无门
[读完] 能画出只读→预演→授权清理的安全边际
```

```text
[旧方案] 告警触发脚本直接清日志
    |
    v
[新需求] 把清理交给 Skill 自动决策
    |
    v
[冲突] 告警只说容量紧张，不说哪些文件可删
    |
    v
[后果] 删掉被进程持有的文件，删掉未知业务目录
```

我是老李。值班时最怕的不是告警，而是告警之后那句“先清一下日志再说”。清得快，问题可能暂时消失；清得错，问题会变得更难解释。

一台 40G 系统盘的云服务器磁盘占用告警之后，有人给它写了个 Skill。公开概述里讲的不是“自动清空”，而是从 83% 这个数字一路走到具体文件的可验证决策。这个方向值得学，但它也正好踩在运维最容易翻车的地方。

容量告警本身只说明一件事：盘上块不够用了。它不说明是哪一类文件不够用，不说明这些文件还能不能删，更不说明删除会不会伤到正在写的进程。

那么，告警响了，就能等于可以删吗？

再想一层，让 Skill 直接 rm，和让它先出示证据再删，差别到底在哪？

如果这一步判错，代价是什么——是空间腾出来了，还是排障线索一起被腾掉了？

# 01、故事

场景很普通：一台 40G 系统盘的小机器，监控把磁盘使用率推到 83%，再涨就可能影响写入。任务是把这个“快满了”变成“知道该动谁、不该动谁”。

最省事的旧做法是 cron 加一条 find，把 /var/log 下超过七天的 *.log 删掉。这条命令几乎每个运维都写过，它也几乎每次都能让数字降下来。

变化来自自动化。既然 Skill 已经能读监控、能执行命令，为什么不干脆让它看到告警就动手？因为一旦“看到告警”被当成“获得许可”，Skill 就从助手变成了不可审计的执行者。

四十个 G 的空间，和一份说不清原因的删除记录，哪个更贵，其实取决于下一次故障时你还剩多少线索。

> 告警一声响
> 手先别发痒
> 先看谁在占
> 再谈删不删

# 02、问题

旧方案失效的地方，不在“能不能删”，而在“说不清为什么删”。

业务影响有两层：删掉正在被进程持有的日志，进程可能继续往已删除的 inode 写，空间不释放；删掉不属于日志的目录，服务直接掉。技术表现则更直接——清理完 df 仍然高，或者 du 和 df 长期对不上。

可验证的完成标准可以写成四条：第一，能给出候选对象的路径、大小、修改时间、归属进程；第二，能给出回滚方案或明确的“不可回滚”结论；第三，删除前必须有人工批准；第四，删除后必须复测容量并留下审计记录。

这四条不涉及任何智能，只涉及纪律。而纪律正是自动清理最缺的东西。

> 脚本能删净
> 证据留不下
> 代价不在删
> 在于说不清

# 03、原理

先把芒格的两个模型摆清楚。安全边际：在触碰关键数据前，保留恢复空间与确认机会。检查清单：把高风险步骤转成逐项可核验的规则。前者决定“留多少余地”，后者决定“每一步怎么验”。

落到磁盘上，第一条反直觉判断是：df 高不等于文件多。df 统计的是文件系统已分配的块，du 统计的是目录树里能看到的文件所占空间。一个日志文件被删除但进程还持有句柄，块仍然被占用，du 却看不见它。

第二条反直觉判断是：清理的目标不是“把数字降下来”，而是“让数字可解释”。降下来可能只是把证据删了；可解释才意味着下一次告警你能更快定位。

第三条是日志轮转的因果链：无论 create 还是 copytruncate，轮转窗口期内都可能出现“旧 inode 仍被写、新文件已建”的状态。这时按文件名删，删的是新文件；按大小删，删的可能是正在写的那个。

生活类比很简单：冰箱塞满了，你不会闭着眼睛往外扔东西，你会先看保质期、看是不是别人刚放进去的、看扔了明天还有没有菜。磁盘清理是同一件事，只是保质期换成了 mtime，别人换成了进程。

> 见的不占块
> 占的看不见
> 账要对得上
> 才敢动刀

# 04、架构

```text
[输入] 磁盘告警 / 巡检请求
    |
    v
[模块] 只读采集器（df / du / inode / 持有句柄）
    |
    v
[数据/状态] 容量账本：块占用、目录占用、inode、deleted 句柄
    |
    v
[处理] 分类 + 预演：候选清单、归属、回滚方案、白名单比对
    |
    v
[输出] 待批准清单（不执行删除）
```

这个架构的边界很硬：采集器只读，决策器只出清单，执行器必须拿到人工批准。收益是每一步都能留下证据；代价是多了一次人工介入，慢。

它适用的条件是：单机、目录结构相对清晰、日志是主要增长源。不适用的条件是：数据库数据目录、容器卷、未知业务目录——这些不该进自动清理的候选池。

> 只读先开口
> 预演再出声
> 授权才动手
> 三步不可省

# 05、实战一次

环境假设：Linux + GNU coreutils（du 选项以 GNU coreutils 手册为准，其他发行版或 BSD 系 du 参数差异需按当前官方文档核验）；需要 lsof，没有则用 /proc 遍历替代。

先跑一个最小但完整的 V1——只读采集，不删除任何东西。

```bash
#!/usr/bin/env bash
set -euo pipefail
OUT=/var/tmp/disk-skill
mkdir -p "$OUT"

df -hP        > "$OUT/df_h.txt" 2>&1 || true
df -iP        > "$OUT/df_i.txt" 2>&1 || true

du -xh --max-depth=1 / 2>/dev/null | sort -rh | head -n 15 > "$OUT/du_top.txt" || true
du -ah /var/log 2>/dev/null | sort -rh | head -n 20 > "$OUT/log_top.txt" || true

lsof +L1 2>/dev/null | head -n 20 > "$OUT/deleted_fd.txt" || true

echo "采集完成：$OUT"
```

说明：`-x` 不跨文件系统，避免把挂载的盘算进根分区；`--max-depth=1` 只下钻一层，先看大盘；`+L1` 列出链接数为 0 的已删除但仍打开的文件。

启动与验证：

```bash
chmod +x disk_readonly.sh
./disk_readonly.sh
ls -l /var/tmp/disk-skill
head -n 5 /var/tmp/disk-skill/du_top.txt
```

未在当前环境实测，以下为预期结果，示例输出：

```console
采集完成：/var/tmp/disk-skill
total 20
-rw-r--r-- 1 root root 1024 df_h.txt
-rw-r--r-- 1 root root  512 df_i.txt
-rw-r--r-- 1 root root 2048 du_top.txt
-rw-r--r-- 1 root root 3072 log_top.txt
-rw-r--r-- 1 root root    0 deleted_fd.txt
```

到这里 V1 就完成了：Skill 只输出证据，不输出删除动作。后续所有优化，都建立在这份证据上。

> 命令皆只读
> 输出即证据
> 先跑通三步
> 再谈自动化

# 06、排查

**诊断链一：df 高，du 汇总却明显偏低。**

现象：df 显示接近满，du -xh --max-depth=1 / 加起来差一大截。
怀疑：有文件被删除但进程仍持有。
检查：`lsof +L1`；无 lsof 时用 `find /proc/*/fd -lname '* (deleted)' -printf '%p -> %l\n' 2>/dev/null | head`。
证据：deleted_fd.txt 中出现指向已删除路径的句柄，且属于某个常驻服务。
根因：日志被外部删除，但进程仍持有原 inode，块未释放。
修复：reload 或重启对应服务释放句柄，或对已打开的日志用 truncate 而非 rm。

**错误尝试：** 直接执行 `find / -name "*.log" -delete`。错在三点：没有挂载点边界，会把别的盘一起扫；没有白名单，会命中业务自己写的 .log 文件；没有区分持有状态，删了也不释放空间，反而让 df 和 du 的账更乱。

**诊断链二：du 慢到跑不完，结果还异常大。**

现象：du 扫描耗时极长，数字远超预期。
怀疑：跨了挂载点，把网络盘或大容量数据盘算进来了。
检查：先 `df -h` 看挂载点，再对比加不加 `-x` 的差异。
证据：加 `-x` 后结果回落，说明差异来自其他文件系统。
根因：缺少 `-x` 边界，统计口径不一致。
修复：采集器固定使用 `-x`；确需统计其他盘时单独指定路径。

**诊断链三：容量没满，但写入报错。**

现象：df -h 还有空间，服务却写失败。
怀疑：inode 耗尽，大量小文件。
检查：`df -i`。
证据：inode 使用率接近 100%。
根因：小文件堆积，与块容量无关。
修复：定位小文件目录，纳入候选清单，同样走预演与批准。

> 现象先分层
> 怀疑要可验
> 错一次记牢
> 通配最伤人

# 07、优化

基于上面三条链的证据，V2 只在两处改动：给候选对象加归属信息，给执行动作加闸门。

根因一：候选清单缺少归属，人工无法判断能不能删。修改：每条候选输出路径、大小、mtime、持有进程、是否为白名单内。原因：安全边际要求“确认机会”，没有归属就没有确认。新行为：清单从“一串路径”变成“一张可核验的表”。验证：随机抽三条，人工能独立判断去留。

根因二：执行动作没有闸门。修改：删除前必须拿到人工批准，且必须命中白名单，必须写审计日志，删除后立刻复测容量。原因：检查清单的价值在于把高风险步骤变成逐项可核验的规则。新行为：Skill 输出的是待批准清单，而不是执行结果。验证：在 dry-run 模式下运行，确认没有任何删除调用发生。

白名单配置示例：

```yaml
allow_cleanup:
  - /var/log/app/*.log.gz
never_touch:
  - /var/lib/mysql
  - /var/lib/docker
  - /data
require_approval: true
dry_run: true
```

写法上要注意：白名单按前缀和扩展名双重限定，只写目录等于没写边界；`dry_run` 默认开启，关闭必须是一次显式操作。

> 根因定方向
> 白名单定界
> 批准定权限
> 复测定成败

# 08、演进

```text
[同一输入：磁盘占用告警]
    |
    +--[V1] 只读采集 / 输出证据 / 代价：慢，需人工看
    |
    +--[V2] 候选清单 + 预演 + 人工批准 / 代价：多一步介入
    |
[Trade-off]
得到可解释、可审计、可回滚；失去“一键清空”的速度；
适用边界是日志型增长，不覆盖数据库、容器卷、未知业务目录。
```

正确性上，V2 明显更好，因为它把“删什么”从猜测变成证据。稳定性上，V2 更稳，代价是多了一次人工确认。复杂度上，V2 引入了配置、白名单和审计，需要一个维护者。成本上，V2 增加的是人的时间，减少的是事故时间。

适用范围上，V2 覆盖日志、临时文件、构建缓存这类可再生成的数据；不覆盖任何一次写入都可能不可逆的数据。遗留问题是：人工批准仍是瓶颈，如果告警量大，需要有分级机制，而不是把批准做成形式。

> 旧路快而险
> 新路慢而稳
> 取舍在边界
> 不在快慢

# 09、洞见

## 9.1 告警是容量信号，不是对象级证据

告警告诉你“这块盘紧张”，但没有告诉你“哪个文件可删”。把这两件事混为一谈，是自动清理最常见的设计错误。安全边际的第一层含义，就是承认信号与证据之间存在距离，并且在这段距离里留出确认机会。

## 9.2 更好的 Skill，是能说“不删”的 Skill

反直觉判断：给运维 Skill 增加能力，最先该加的不是“删得更准”，而是“拒绝得更清楚”。一个只会执行的 Skill，出错时你只能回滚；一个会拒绝并给出理由的 Skill，出错时你还能对话。

## 9.3 检查清单的密度，决定安全边际的宽度

反直觉判断：清单不是越长越安全。真正起作用的是那几个卡点——是否只读、是否有归属、是否有批准、是否复测。条目堆到二十条却都能一键跳过，等于没有清单。

## 9.4 容量治理的终点是可解释性

磁盘从 83% 降回 60% 不是终点。终点是下一次告警时，你能在一分钟内说出增长来自哪里、谁在写、能不能删。可解释性才是可复用的资产，清理动作只是一次性收益。

> 少删一分险
> 多留一分证
> 慢半步不亏
> 快一步难收

# 10、系统落地

原来有什么：一条 cron 加 find 的清理脚本，能降数字，说不清原因，出事后无记录。

本篇新增什么：一个只读采集器、一份候选清单结构、一份白名单配置、一道人工批准闸门和一条审计记录。

现在能做什么：面对磁盘告警，能在一轮采集内区分“块不够”“inode 不够”“文件被持有”三种情况，并对候选对象给出大小、时间、归属和回滚方案。

还缺什么：缺少分级批准机制，缺少对多机批量场景的汇总视图，缺少清理后的趋势对比。

下一步如何演进：先把审计记录跑满一个周期，用真实清单反推白名单是否需要收紧；再考虑把“重复出现的候选模式”固化成规则，而不是把批准流程简化掉。

> 原来靠人记
> 现在靠单走
> 能做的有限
> 边界先写明

# 11、小结

```text
Q1 → 告警不等于删除许可，它只说明容量紧张，不说明对象可删
Q2 → 直接 rm 是无证据执行，先出示证据再删是可审计决策
Q3 → 判错的代价是空间没释放、线索被删除、故障更难定位
状态 → 一套只读采集 + 预演清单 + 人工批准的磁盘 Skill V1
```

> 定义给清楚
> 证据给齐全
> 授权给到人
> 复测给闭环

# 12、作业

## 12.1 理解题：为什么 df 显示快满，du 汇总却对不上？

参考答案：两者统计口径不同。df 看文件系统已分配块，du 看目录树中可见文件占用。文件被删除但进程仍持有句柄时，块未释放而目录项已消失，于是出现差额。用 lsof +L1 或 /proc 遍历可定位。

## 12.2 实战题：把只读采集器改造成“输出候选清单但不删除”的版本。

参考答案：在采集基础上增加一步，对超过阈值的大文件或超期日志，输出路径、大小、mtime、持有进程、是否命中白名单，并附回滚方案（可再生成 / 不可回滚）。脚本末尾不得出现任何删除调用，dry_run 默认开启。

## 12.3 排障题：清理后 df 没有任何变化，怎么查？

参考答案：先确认是否删的是被进程持有的文件——查 deleted 句柄；再确认是否删在了别的挂载点——对比加 -x 的 du 结果；最后确认是否 inode 型问题——看 df -i。三种原因的修复动作完全不同，不能一律用重启解决。

## 12.4 架构判断题：是否应该让 Skill 在告警时自动删除白名单内的文件？

参考答案：不建议默认开启。白名单降低了范围风险，但没有消除“轮转窗口内删到正在写的文件”这类时序风险。更稳妥的设计是自动生成清单、自动预演、自动通知，删除动作保留人工批准；只有在清单长期零误报、审计完整的前提下，才考虑对极窄范围开放自动执行。

> 题在纸上问
> 答案在盘上
> 做一遍才懂
> 说十遍还虚

# 13、思考

这篇的核心冲突只有一句话：能不能让 Skill 自动删。芒格的两个模型给出的答案不是“能”或“不能”，而是“先满足什么条件”。安全边际要求你在触碰关键数据前保留恢复空间和确认机会；检查清单要求你把高风险步骤拆成逐项可核验的规则。

所以顺序是固定的：先定位，再预演，再授权清理。告警是起点，不是许可。先能解释为什么删，再讨论能不能自动删。

> 一念辨边界
> 一证定根因
> 一改知取舍
> 一役见真章

我是老李。值班时最怕的不是告警，而是告警之后那句“先清一下日志再说”。清得快，问题可能暂时消失；清得错，问题会变得更难解释。

技术思考问题53：40G硬盘报警，Skill敢删？

磁盘告警一响就想自动清空，删错一个目录就没有回滚。本文用安全边际与检查清单，把运维 Skill 拆成只读定位、预演候选、人工批准三步，给出可核验的落地路径。

架构师

人工智能

40G云盘告警不等于删除许可。构建只读采集→预演清单→人工批准→审计复测的安全清理流程，区分df与du差异、识别deleted句柄、白名单限定边界。先出示可验证证据，再谈自动删，让Skill学会"拒绝"比"删除"更重要。

云服务器

日志文件

文件系统

代码解释

数据库

服务器

容器

Docker

MySQL

Linux

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

技术思考问题53：40G硬盘报警，Skill敢删？-腾讯云开发者社区-腾讯云

技术思考问题53：40G硬盘报警，Skill敢删？

技术思考问题53：40G硬盘报警，Skill敢删？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐