配置文件写错一个小数点，服务就起不来
上周五下午，公司内网突然访问不了监控系统。排查一圈发现，是有人在修改 Nginx 配置时，把一个端口号写成了 80.8，而不是 8080。Nginx 启动直接报错，但因为是热更新，没人注意到日志输出。直到用户连不上才被发现。
这种低级错误其实特别常见。数字、符号、缩进，差一点都不行。YAML 尤其敏感，多一个空格都能让服务瘫痪。建议改完配置先用命令行工具验证一下，比如：
nginx -tdocker-compose config误删生产数据库的惨剧
有位同行朋友，在清理测试环境时，手一滑执行了这条命令：
rm -rf /data/mysql/*后来靠备份恢复了八成数据，但那两小时的订单全丢了。现在他们所有高危操作都上了二次确认脚本，而且生产环境禁止直接登录 root。类似 rm、drop database 这种命令，必须加白名单审批。
DNS 改错了，全公司上不了外网
有一次，运维同事调整 DNS 轮询策略，想把流量导到新服务器。结果把 A 记录写错了 IP，还 TTL 设成了 86400 秒。等发现不对，缓存刷新不过来，全国各地办公室陆续断网。
后来只能紧急联系各 ISP 刷新，等了快两个小时才恢复正常。现在改 DNS 都选在凌晨，TTL 提前降到 300，改完盯着监控看十分钟，确认没问题再走人。
防火墙规则堵死了自己
远程维护最怕的就是改完防火墙，把自己踢出去。有人配 iptables 时，加了一条 DROP 所有未授权 IP 的规则，但忘了把自己的办公 IP 加进去。保存应用后，SSH 直接断连。
机房又在郊区，等物理接入花了四十分钟。现在这类操作都通过跳板机定时任务执行，规则加完自动回滚，除非手动取消。宁可慢一点，也不能把自己锁在外面。
别让“我觉得没问题”成为事故导火索
很多错误不是技术不够，而是太自信。一句“我以前这么干过”，就敢在白天高峰期动核心服务。其实只要多走一步：打个快照、留个回滚方案、拉相关同事进群，就能避免大部分问题。
运维这行，不怕犯错，怕的是同一个错误反复犯。把每次故障记下来，变成检查清单，下次自然少踩坑。