服务器挂了，排查第一反应是服务“它怎么又挂了”。但多数时候，器否问题不是出现突然出现的，是问题慢慢烂掉的。排查这事，排查别慌，服务按顺序来。器否 **先看硬件，出现再看系统，问题最后查代码。排查** 别一上来就翻日志，服务那是器否最后一步。 第一步，出现**看机器还活着吗**。问题ping一下IP，通了说明网络层没死。不通？先查网线、交换机端口、防火墙规则。我见过最蠢的案例——机房同事把两台服务器的网线插反了，ping不通，查了半天，最后发现是标签贴错。物理层的事，别忽略。 通了之后，**登上去看负载**。`uptime`命令，看load average三个数。如果长期超过CPU核数，比如8核机器load到10以上，那基本是CPU或磁盘IO扛不住了。这时候别急着杀进程，先看看是哪种负载——`top`进去按1看每个核的使用率，按x高亮排序。CPU飙高，可能是死循环或者密集计算；如果是wa（IO wait）高，那是磁盘在拖后腿。 磁盘这块，**`df -h`看空间，`iostat -x 1`看IOPS**。空间满了，日志写不进去，服务会假死，表现为“连得上但没响应”。IOPS高，多半是数据库在疯狂扫表，或者某个程序在写大文件。我处理过一次，是同事把debug日志级别开到最大，一天写出30GB，磁盘直接爆了。 内存也别漏。`free -m`看available，不是看free——Linux会把内存当缓存用，free低很正常，available低才是真不够。如果swap被大量使用，说明内存真的紧张了，进程可能被换出，响应变慢。 系统层面没问题，**再看进程和端口**。`ps aux`找可疑进程，`ss -tlnp`看端口监听。服务端口没了，多半是进程崩了，看systemd状态或者启动脚本的报错。端口在但连不上，可能是连接数满了——`ss -s`看socket统计，TIME_WAIT堆太多，就得调内核参数或改应用连接池。 这些都查完，还找不到问题，**才轮到日志**。别一上来就tail -f，先看时间点。故障发生前后半小时的日志，用grep过滤ERROR、WARN，配合时间戳排序。重点看有没有OOM（内存耗尽被内核杀）、死锁、超时异常。日志这东西，平时没感觉，出事了就是破案线索。 还有个容易被忽略的——**网络带宽**。`iftop`或者`nload`看实时流量。有时候CPU、内存、磁盘都正常，但服务就是卡，可能是带宽被占满，比如有人在下大文件，或者被DDoS了。内网机器之间互相备份，也会把千兆口打满。 最后说个经验：**排查时先看监控图，别直接上手操作**。如果你有zabbix或Prometheus+grafana，先看CPU、内存、磁盘、网络的趋势图，能快速定位异常是从哪个时间点开始的。再对应那个时间点，看有没有发版、配置变更、定时任务。很多时候，问题不是“坏了”，是“改坏了”。 排查这事，七分靠经验，三分靠工具。但核心逻辑就一条——**从外到内，从硬件到软件，先排除底层再查上层**。别跳步，跳步最容易绕远路。