主题
典型踩坑实录(短案例集)
本篇定位
12 条短小精悍的踩坑实录。每条按"场景 → 坑点 → 教训"写,都是生产里真实发生过的复合案例。适合收藏,睡前翻一翻,下次就别再踩。
第一人称复合案例,公司/人名/IP/密钥均为化名。
一、命令与误删类
1. rm 删错目录
| 场景 | 夜里清理日志,cd 到一个目录后 rm -rf ./*,结果发现 cd 没成功,人还在上级目录,一把删了半个应用目录。 |
| 坑点 | rm -rf ./* 依赖"我在对的目录"这个前提;cd 失败时 shell 不报错,&& 也没用上。 |
| 教训 | 删之前先 pwd + ls 看一眼;用 && 串联(cd /path && rm -rf ./*);高危删除前先把文件 mv 到临时目录观察一天再真删。 |
2. 通配符误伤
| 场景 | 想删 backup_2025*,手滑写成 backup_2025 *(中间多了空格),shell 把 * 展开成"当前目录所有文件"。 |
| 坑点 | 通配符前一个空格 = 另一个参数;rm 见到 * 就是全删。 |
| 教训 | 通配符删除前先 echo backup_2025* 看展开成什么;永远先 echo 再 rm。 |
二、磁盘与文件系统类
3. 磁盘满了但 df 还有空间
| 场景 | 应用写日志报"No space left",可 df -h 看分区明明用了 60%。 |
| 坑点 | 满的不是磁盘块,是 inode:日志目录下几十万小文件把 inode 耗光了。 |
| 教训 | 磁盘满先 df -h,再 df -i;小文件极多的目录要单独清理。 |
4. 删了文件空间没释放
| 场景 | 删了一个 20G 的大日志文件,df 空间一点没回来。 |
| 坑点 | 有进程还握着这个已删除文件的句柄,内核不释放空间。 |
| 教训 | 别 rm 正在写的日志,用 : > app.log 截断;已发生就 `lsof |
三、时间与时区类
5. 定时任务半夜不跑 / 早 8 小时跑
| 场景 | crontab 里写好"凌晨 2 点跑备份",结果备份在上午 10 点才跑,或干脆不跑。 |
| 坑点 | 容器/新机器时区是 UTC,和业务预期的 CST(UTC+8)差 8 小时;监控时间戳也对不上。 |
| 教训 | 统一确认 timedatectl / /etc/localtime;容器用 TZ=Asia/Shanghai;监控"没数据"先查时间同步。 |
四、缓存与流量类
6. 缓存雪崩
| 场景 | Redis 一大批 key 同一时刻过期,请求全砸到数据库,DB 瞬间被打挂。 |
| 坑点 | 大批 key 设了相同过期时间,到期集体失效。 |
| 教训 | 过期时间加随机抖动;热点 key 永不过期+后台刷新;DB 前加限流兜底。 |
7. 连接数打满
| 场景 | 服务突然 502,ss -s 看 TIME_WAIT 十几万,新连接建不上。 |
| 坑点 | 短连接大量创建/销毁,端口和连接被 TIME_WAIT 占满;应用没复用连接池。 |
| 教训 | 优先应用侧用长连接/连接池;内核 tcp_tw_reuse 可调,但别一上来就调内核,先查应用。 |
五、配置与 reload 类
8. 改了配置没生效
| 场景 | 改了 Nginx 的限流参数,重载后行为没变。 |
| 坑点 | 执行了 nginx -s reload 但实际是另一套配置文件路径;或改完忘了 reload。 |
| 教训 | 改完必 nginx -t 验证是哪个配置;确认 reload 成功;用 nginx -T 打印最终生效配置核对。 |
六、权限与证书类
9. 权限问题:root 也读不了
| 场景 | 切到 root 仍 Permission denied,文件权限看着没问题。 |
| 坑点 | 父目录没有 x 权限;或文件带了 ACL / 隐藏属性(chattr +i)。 |
| 教训 | 权限问题从父目录一路 ls -ld 查;lsattr 看是否被 +i;getfacl 看 ACL。 |
10. 证书到期深夜炸
| 场景 | 半夜客户端大面积报证书错误,才发现 HTTPS 证书当天过期。 |
| 坑点 | 证书有效期 1 年,没人记得到期日,也没监控。 |
| 教训 | 所有证书入库 + 到期前 30/15/7 天告警;用证书巡检脚本定期扫。密钥管理见密钥与证书管理。 |
七、日志与主从类
11. 日志写满根分区
| 场景 | 某个进程 bug 疯狂打日志,一夜把 / 根分区写满,连带数据库写不进去。 |
| 坑点 | 日志没做大小切割和独立分区,bug 日志反噬系统盘。 |
| 教训 | 日志挂独立分区;logrotate 按大小+天数切割;根分区只读保护重要目录。 |
12. 主从切换后写报错
| 场景 | 做了主从切换,应用却还在往旧主写,报只读错误。 |
| 坑点 | 切换前没确认从库延迟为 0,应用配置/代理还指着旧主;数据已不一致。 |
| 教训 | 切主前 Seconds_Behind_Source=0;应用用统一入口(VIP/代理)指向新主;切完停写旧主。灾备流程见容量规划、高可用与灾备。 |
共同的教训
上面 12 条,归到一句话:别依赖"我记得",要依赖"可验证 + 有监控 + 有预案"。 删之前先看、改完先验、到期有告警、变更有回滚。
相关速查
- 这些坑背后的排障方法:信息不全时的排障推理框架
- 能自动发现磁盘/inode/证书问题的脚本:巡检 / 自愈 / 批量操作脚本集、备份 / 清理 / 证书巡检脚本集
- 一次连接数打满的完整夜:值班惊魂:一次告警风暴的真实处置
- 更多真实故障案例:排障案例