处理服务器故障时，80% 的运维新手会先重启而不是先看日志，这个习惯直接导致故障原因被掩盖，三天后同一问题再次爆发。

从硬件监控到系统日志：先锁定根因再动手

某电商公司双十一大促期间，一台 Web 服务器 CPU 持续 95%，值班运维直接重启进程。结果 10 分钟后负载再次飙升，最后发现是 Nginx 配置中 keepalive 时间设置过长导致连接堆积。正确做法：用 top 看异常进程，用 journalctl -xe 过滤最近 10 分钟的系统日志，用 netstat -ant | grep :80 检查连接状态。比如确认 TIME_WAIT 超过 2 万个时，调整 net.ipv4.tcp_tw_reuse 参数才是关键，而不是盲目重启。

磁盘写满的应急排查：别急着删文件

某 SaaS 平台服务器磁盘告警达到 95%，新手习惯用 du -sh /* 从根目录逐个找大文件，耗时 10 分钟只找到几个日志文件。实际上应该先用 df -i 看 inode 是否占满：如果 Inode 使用率 100%，说明小文件过多，常见于邮件队列或 session 文件堆积。此时用 find / -type f -name "*.tmp" | wc -l 快速定位临时文件目录，再用 ls -1 | wc -l 确认具体目录下文件数量。比如 /var/spool/mqueue 下超过 5 万个文件，直接清理该目录即可释放 inode。

网络延迟排查：从 ping 到 tcpdump 的阶梯方法

用户反馈服务器响应慢，运维第一反应是 ping 外网。但 ping 通只说明网络层通，不代表应用层正常。实际案例中一台数据库服务器 ping 延迟只有 2ms，但应用查询超时。此时用 curl -w "@curl-format.txt" -o /dev/null -s http://localhost:8080 测试本机接口耗时，发现 90% 的时间花在 time_total 上。再用 ss -tlnp 检查端口监听状态，发现 MySQL 监听在 127.0.0.1 而非 0.0.0.0，导致外部连接被拒绝。真正高效的排查路径是：先确认本地服务是否正常，再检查防火墙规则（iptables -L -n），最后抓包（tcpdump -i eth0 port 3306 -w dump.pcap）分析握手阶段失败原因。

• 误区一：把重启当万能药。正确做法是先保留故障现场（如 journalctl --since "5 minutes ago" 导出日志），再执行重启操作。
• 误区二：监控只看 CPU 和内存。磁盘 IO（iostat -x 1）、网络丢包率（mtr -r）同样关键，建议在 Zabbix 中额外添加这两个指标。
• 误区三：忽略时间同步。服务器时间偏差超过 5 分钟会导致日志时间戳错乱，排查时误判事件顺序。每天用 chronyc tracking 检查偏移量，偏差超过 1ms 即需校准。