坑1：重启服务忘检查依赖
事故经过： 同事重启缓存服务，没有确认依赖关系，导致分布式锁服务失败，支付模块在业务高峰期中断。
预防方案：
重启前做「三重确认」：
- 检查上下游依赖，确认影响范围
- 确认启动脚本有健康检查
- 选择业务低峰期，预留 3-5 倍处理时间
采用「分阶段重启」：先重启从节点，确认稳定后再重启主节点。
坑2：配置修改出错
常见错误：
- Nginx 配置语法错误，服务无法启动
- 数据库连接池配置写错（
max_active=2000写成200） - 安全组规则设置过于宽松
预防方案：
三步流程：备份 → 修改 → 验证
# 修改 Nginx 配置前先备份
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d)
# 修改后验证语法
nginx -t
# 确认无误再重载
nginx -s reload
关键配置用 Git 管理，每次变更有记录，出问题可以快速回滚。
坑3：备份从没验证过
事故经过： 硬件故障需要恢复数据，发现备份已经一周没有成功执行——存储空间满了，备份任务静默失败。
预防方案：
遵循「3-2-1 备份原则」：
- 3 份数据副本
- 2 种不同存储介质
- 1 份异地存储
每周随机验证 1-2 个备份，在测试环境实际恢复，确认数据完整性。
监控备份任务执行状态、文件大小、存储容量，任何异常立即告警。
坑4：网络排查没有方法论
常见场景： 应用连接问题排查了 2 小时，最后发现是 DNS 解析指向了已下线的服务器。
排查方法论： 按 OSI 模型从底层往上排查
物理层 → 数据链路层 → 网络层 → 传输层 → 应用层
常用工具：
# 检查 DNS 解析
nslookup domain.com
dig domain.com
# 检查端口连通性
telnet host port
nc -zv host port
# 抓包分析
tcpdump -i eth0 host target_ip
坑5：权限管理混乱
风险场景：
- 多人共用同一个账号
- 普通员工有 root 权限
- 离职员工权限没有及时回收
真实案例： 外包人员离职后权限未回收，3 个月后服务器被植入挖矿程序。
预防方案：
最小权限原则：按角色分配权限，root 访问限制在 1-2 人。
权限生命周期管理：角色变更后 24 小时内回收权限。
加强远程登录安全：
# 禁止 root 直接登录
PermitRootLogin no
# 限制允许登录的 IP
AllowUsers user@192.168.1.*
# 定期轮换密钥
总结
大多数运维事故不是来自意外，而是来自操作疏忽。建立标准流程、强化监控、定期复盘——这三点能避免 80% 的重复性故障。