IT运维避坑指南：6个踩过的坑和血泪教训

Q：第一个坑是什么？

踩过一个，服务器日志占满磁盘，凌晨三点报警。查了下，是应用日志没配轮转，单个文件撑到10GB，直接撑爆系统分区。原因很简单，默认配置只管写不管删，日志框架的maxHistory设成0，等于无限保留。

正确做法是上线前就配好Logrotate，每天轮转，保留7天。用log4j的话，RollingFileAppender加TimeBasedTriggeringPolicy，再设个SizeBasedTriggeringPolicy兜底，单个文件超500MB就切。

别信默认配置，日志系统默认都是往死里写，你不配就等着炸。

Q：数据库备份踩过什么坑？

有次客户数据丢了，问备份在哪。一查，定时任务没起来，crontab写的路径不对，备份脚本跑了两年全是空文件。备份脚本里mysqldump输出重定向到/tmp/backup.sql，但/tmp被系统定时清理，实际备份文件早没了。

原因更蠢，部署时测试过能跑，但忘了加cron环境变量。脚本里用的mysqldump是绝对路径，但cron环境PATH不包含/usr/local/mysql/bin，脚本直接报错退出，输出空文件。

正确做法是备份脚本里所有命令用绝对路径，备份文件存到独立磁盘，加个邮件通知。每天检查备份文件大小，小于100MB就报警。别等丢数据才后悔。

Q：防火墙配置有什么典型错误？

开发说端口开了，但生产环境连不上。查半天，iptables规则顺序写反了。允许规则写在拒绝规则后面，所有流量全被最后一条REJECT拦住。

还有一次，安全组策略只配了入站规则，出站全放开。被黑客拿去做DDoS反射，带宽打满，客户投诉。

正确做法是规则按最小权限原则配，允许指定IP的入站，出站也限制到只有必要端口。用ufw或firewalld管理，别手写iptables，容易写错顺序。

Q：监控告警有什么坑？

配了CPU监控，阈值设90%，但业务高峰期经常误报。原因是用top看CPU使用率，但没区分用户态和系统态。实际是系统态占60%，用户态只占20%，系统态高是因为频繁上下文切换。

正确做法是监控时区分cpu.user和cpu.system，单独设告警。用户态持续超90%才报警，系统态超30%就查是不是有进程在抢锁。告警通道用微信或钉钉机器人，别只发邮件，没人看。

Q：SSL证书续期出过什么问题？

某天用户访问网站，浏览器提示证书过期。查了下，证书有效期一年，但没人记得续。更气的是，当时用的免费证书，续期流程要手动验证域名所有权，过期后才开始弄，用户投诉半天。

正确做法是用acme.sh或Certbot配自动续期，提前30天发告警。脚本里加个cron每月跑一次，续期失败就发短信。别手动续，人总会忘。

Q：最后一个坑是什么？

配置变更没走流程，直接上生产改配置。改完后服务挂了，回滚也没备份。后来发现，改的是连接池参数，数值设太大，数据库连接数爆了。

正确做法是配置变更前备份，改完后先灰度发布。用Ansible或SaltStack管理配置，版本控制。别直接ssh进去改，改完就跑。

核心原则：所有变更都先测试，所有操作都有备份，所有告警都配通知。别信经验，信流程。