凌晨两点被电话叫醒，这种事我干过不下十次。后来复盘发现，绝大多数故障压根不是什么高深的技术难题，而是某个特别蠢的细节没注意到。下面这些坑，我基本都亲自踩过一遍，写出来给还在值班的朋友省点觉。
动手之前先想清楚怎么退回去
我见过太多人改配置之前不备份，改完发现服务起不来，然后一群人围着终端干瞪眼。我现在的习惯很简单：任何变更先问自己一句，出问题了我几分钟能恢复原样？答不上来就先别动手。
时间点也很关键。周二下午三点和周五晚上八点，风险完全不是一个量级。周五晚上挂了，能帮你的人都在回家路上，周一早上老板上班第一件事就是找你。我们组后来定了个死规矩，周四下午之后不做大变更，要发就周一上午发，留足一整周的处理窗口。
还有回滚方案本身。有人写了回滚步骤，但从来没演练过，真出事的时候发现备份文件是空的，或者旧版本的程序包早被清理了。这种事我遇到过两次，第二次之后就要求所有回滚脚本必须提前在测试环境跑通，跑不通不算方案。
日常最容易翻车的几个细节
- 磁盘监控只看使用率不看 inode，结果小文件写满 inode，df -h 显示还有一半空间，服务照样挂
- 日志不做切割，一个 access.log 涨到 80 个 G，删除的时候句柄没释放，空间还是占着
- 所有操作都用 root，某次手抖在错误的目录下执行了删除命令，数据直接没了
- 定时任务里的脚本没加重定向，输出全堆在系统邮件里，时间长了 /var/spool 撑爆
- 服务器时间不同步，排查问题时日志时间对不上，白白多花两个小时
说个真实的例子。去年我们一台数据库从库延迟突然飙到 40 分钟，第一反应是主库写入量太大，查了半天慢查询没发现问题。最后发现是从库所在机器的 CPU 被另一个无关的定时备份任务吃满了。运维排查最怕的就是只盯着自己以为的那个点，实际上问题在隔壁。所以监控面板一定要能看到同机器上所有进程的资源占用，别只盯数据库指标。
另外，别太相信"已经配好了"。配置漂移这事太常见了，几台机器手动改过的东西，换个人接手根本不知道。我的建议是把所有变更都落到代码里，用 Ansible 或者随便什么工具管起来，哪怕只是几台机器。手动改的东西，三个月后就是一颗定时炸弹。
最后一句大实话：运维这行，做得好没人夸，出一次事故能记你一年。所以别嫌备份麻烦，别嫌演练浪费时间，这些看着多余的步骤，才是让你能安稳睡觉的东西。