做了十年运维，最怕的不是技术难题，而是那些你想都想不到的坑。
硬盘坏了不可怕，可怕的是硬盘坏了你才发现备份也是坏的。被人删库不可怕，可怕的是删库的人是你自己。流量暴涨不可怕，可怕的是涨了之后才发现不是业务爆发，是被人爬了。
今天聊几个真实踩过的坑。有的让我凌晨四点从床上蹦起来，有的让我想抽自己一巴掌，有的让我在用户骂声中学会了做人。写出来不是证明我多惨，是希望你看到后能躲开。
案例一：硬盘静默损坏——备份还在，但备份也是坏的
那是一个普通的周二下午，客户打电话说网站打不开。我登上去一看，数据库报错：表不存在。
不对啊，昨天还好好的。
查日志，发现磁盘有坏道，刚好坏在了数据库文件所在的位置。坏道这东西，有时候读得出来，有时候读不出来，昨天还能读，今天就彻底死了。
没事，我有备份。每周全量，每天增量，备份脚本跑了两年从没出过错。
然后我发现，备份文件也是坏的。
为什么？因为备份脚本是从原盘读数据，写到备份盘。原盘坏道的地方，读出来的是乱码，备份脚本老老实实把乱码写进了备份文件。两周前第一次出现坏道的时候，备份就已经开始备份坏数据了。
教训：
- 备份要测试，不能只备份不看能不能恢复。每月随机抽一个备份文件，恢复到测试环境，看看能不能跑起来。
- 监控要到位。SMART告警开了吗？硬盘坏道早期是有征兆的，只不过没人看。
- 3-2-1法则里那个“2种介质”是有道理的。如果当时有一份备份在对象存储，或者有一份是冷备，可能就躲过去了。
最后恢复了多少？大概70%的数据。剩下的，客户自己手工补了一个月。
案例二：rm -rf 跑错目录——删库跑路是真的
凌晨四点，手机响。接起来对面沉默了三秒，然后说：“我把数据删了。”
我一边穿裤子一边问：“哪个目录？”
“/。”
脑子嗡的一下。“你是说根目录？”
“不是根目录，是那个项目的目录……吧？”
等我登上机器，看到 history 里最后一条命令：rm -rf / home/project。
看到那个空格了吗？/ 和 home 之间多了一个空格。他想删 /home/project，实际执行的是 rm -rf / 然后报错说 home/project 不存在，但根目录已经被删了一部分。
那一刻我特别理解为什么有些公司规定 root 密码只有两个人知道。
抢救过程：
- 立即把机器从机房网络断开，防止写入覆盖
- 用 extundelete 扫描被删除的 inode
- 祈祷运气好，删掉的数据块还没被覆盖
运气还行，恢复了90%。但有些配置文件永远找不回来了，因为被删之后系统自己写日志覆盖了。
教训：
- 高危命令加保险：把
rm别名成rm -i，或者用 trash-cli 这种东西 - 权限分级：能不用 root 就别用 root，能删全盘的人越少越好
- 重要目录做不可变标记：
chattr +i了解一下
后来那个人请全团队喝了半个月咖啡。
案例三：流量突增不是好事——被爬虫扒了一层皮
某个周末，监控告警：带宽打满，CPU飙升。
第一反应是业务爆发了？看了一眼数据，平时早高峰 50M，现在 200M，涨了四倍。老板已经在群里发红包庆祝了。
但我总觉得不对劲。业务没做推广，没上热搜，凭什么突然涨四倍？
查访问日志，发现某个 IP 段在疯狂请求搜索接口，每秒几千次，UA 还伪装成 Chrome。这不是用户，是爬虫。
更恶心的是：这个爬虫很聪明，它会换 IP，几百个 IP 轮着来，封不完。它会遵守 robots.txt 吗？不会。它会降低频率吗？不会。
处理过程：
- 第一步：防火墙临时封掉最狠的几个 IP 段
- 第二步：Nginx 限流，每个 IP 每秒最多 5 个请求
- 第三步：搜索接口加验证码（虽然影响用户体验，但比被打死强）
- 第四步：给 CDN 配置好缓存，让爬虫去啃 CDN
打了一天一夜，爬虫终于撤了。事后看日志，这个爬虫至少抓了 200 万条数据。
教训：
- 重要接口必须限流，不限流就是在赌没人搞你
- 爬虫是会进化的，简单的 IP 封禁早就不够用了
- 业务暴涨不一定是好事，先确认来源再庆祝
老板把红包收回去了，说等技术稳定了再发。
案例四：SSL证书过期——早上被用户骂醒
那天早上我是被电话吵醒的，不是闹钟。
“网站打不开了，浏览器说证书无效。”
我迷迷糊糊打开电脑，一看日期：3 月 15 日。再一看证书有效期：到 3 月 14 日。
哦豁。
为什么没发现？
- 监控告警是有的，但我设的是“过期前 7 天提醒”。7 天的时候我在忙别的事，看了一眼邮件想着“下周再说”，然后就忘了。
- Let’s Encrypt 是自动续期的，但这个证书是买的付费证书，不能自动续，要手动操作。
补救过程：
- 赶紧登录证书商后台，重新签发证书
- 上传到服务器，重启 Nginx
- 等 CDN 节点刷新缓存（又等了半小时）
从发现到恢复，一共 45 分钟。这 45 分钟里，用户看到的全是红色警告页面。
教训：
- 重要的事不要相信自己的记忆力，要相信自动化
- 证书监控要设多级：7 天提醒一次，3 天再提醒一次，1 天电话打过来
- 能用自动续期的就别用手动，省那点钱不够买一次事故
后来我给自己定了个规矩：每个月 1 号检查所有证书。虽然笨，但有效。
案例五：内核升级后重启起不来——手贱的代价
那是一个风和日丽的下午，我 SSH 到一台测试服务器，想着好久没更新了，敲了个 yum update -y。
更新列表里有内核。我想着测试机，没事，升就升吧。
升完提示要重启。我敲了 reboot。
然后就起不来了。
发生了什么？新内核和现有驱动不兼容，网卡驱动没加载上，机器起来了但没网络。我连不上，只能去机房（或者让机房管理员接显示器）。
更尴尬的是：这台测试机上跑着一个客户的演示环境，客户第二天要用。我当时说“测试机”的时候，忘了这茬。
抢救过程：
- 让机房管理员帮忙接显示器进系统
- 在 GRUB 启动菜单选择旧内核（幸好没覆盖）
- 进去之后把新内核卸载，恢复原状
教训：
- 生产环境（包括重要测试环境）永远不要手贱
- 内核升级前至少看一眼 release notes，看有没有不兼容变更
- 升级前做快照，出事能回滚
- 重要机器保留至少两个内核版本，别手贱删旧内核
后来我把所有机器的自动更新关了，改用手动，而且只更新安全补丁，内核这种大版本升级必须单独走流程。
写在最后
这些坑我每个都踩过，有的还踩过不止一次。
硬盘坏了的那个客户，后来每次见我都说“备份测了吗”。删库的那个同事，现在写命令前会盯着屏幕看三秒。被爬虫打的那次，我养成了每周看一次访问日志的习惯。证书过期那次，我手机上多了三个提醒闹钟。内核升级翻车之后，我在所有机器上都装了 Grub 菜单超时等待 10 秒。
踩坑是成长的捷径，但有些坑没必要亲自踩。你能看到这篇文章，说明你已经比当时的我幸运了。
最后送运维同行们一句话：服务器不会因为你辛苦就对你温柔，但会因为你细心少出点幺蛾子。