企业官网建设流程全解析

服务器一“夯”，运维群里往往比过年还热闹：业务方急着催恢复，开发急着想理由，主管急着要结论，而你一个人蹲在机房或者盯着远程控制台，满脑子只有一个问题——“到底哪一步出了问题”。

干运维这些年，经手的服务器没有上千台也有几百台，我最深的体会是：夯机并不可怕，可怕的是没有一套顺手、标准、可复现的排查流程。很多兄弟遇到服务器假死，第一反应就是重启，重启完确实能撑一阵子，但下次再夯，问题依旧，业务方对你的信任也在一次次“重启大法”里被消磨干净。

这篇文章就把我日常处理服务器夯机时用的完整排查方案整理出来。从现象分类、现场取证、系统资源排查、硬件健康检查、内核日志分析，到网络层的“假夯机”识别，全部走一遍。你把它当成自己的排查手册来用，遇到问题照着章节翻，基本能在最短时间内锁定方向。

1. 先把“夯机”分清楚：现象分类决定排查方向

“服务器夯机”这个词在不同圈子叫法不一样，有人叫死机，有人叫挂起，有人叫假死，本质上都是服务器不再按预期响应。但“不再响应”这件事，背后的原因天差地别。我一般先把夯机分成三类，类别定对了，排查方向就对了。

1.1 三种典型夯机表现，别上来就重启

第一类是彻底宕机。电源灯灭、风扇不转、远程连接直接断，ping都ping不通。这种问题大多指向硬件：主板、电源、内存、CPU，少部分是系统引导损坏。处理路径很直接——带外管理面板看状态、进机房看指示灯、备件替换。排查核心是“确认坏件”，而不是在那儿敲命令。

第二类是假死无响应。服务器电源灯正常、风扇呼呼转，但业务进程不响应，SSH连不上，ping有时候通有时候不通。这类最坑人，硬件看起来还活着，实际上系统已经卡死或者负载极端异常。常见原因是D状态进程堆积、内存耗尽触发OOM、内核死锁、磁盘I/O卡死，后面我会重点讲。

第三类是应用层夯住。整机正常，ping秒回，SSH秒进，但某个业务进程CPU飙到100%，或者Java应用GC卡死，或者数据库连接池被打满，导致业务表象跟死机一模一样。这类问题根因通常不在系统层，而在应用配置、SQL效率、并发设计上，排查时要学会“跳出系统看业务”。

1.2 排查前的准备：先把“现场”留下来

在讲具体排查步骤之前，我先说说上现场之前必须准备的东西。很多兄弟一接到告警就冲过去乱敲命令，敲完发现系统彻底卡住重启了，什么都没留下。

我建议至少准备这些：

• 一个能访问带外管理系统的通道（iDRAC、iLO、IPMI或者KVM远程控制台），这样即使SSH断了，至少能看到屏幕、能操作控制台。这一步是很多公司没做到位的，平时不带外管理IP和密码归档，真出事的时候抓瞎。
• 一个记事本（或者手机备忘录），记录出问题的时间点、最近一次变更（发布、扩容、改配置）、重启历史。这些信息在后面核对日志时非常关键。
• 如果是物理机，确认好机房和机柜位置，备好串口线或KVM线，确认带外网段能从你当前网络访问。
• 如果你是云服务器，准备好云厂商的控制台VNC入口和快照回滚预案。

最后送你一句话：别慌，每一条命令都有目的，想清楚再打。慌是排查效率最大的敌人。

2. 系统资源层排查：CPU、内存、负载的先后顺序

系统层资源异常是夯机最常见的原因。十次夯机里，起码有六次和负载过高、内存耗尽、D状态进程堆积有关。这个章节我把整个排查顺序和命令用法讲透。

2.1 load高不等于CPU高，先分清CPU忙还是I/O忙

先说load。我见过太多新手一看到load average 80、90就慌了，觉得“完了完了服务器要炸”。其实load高不一定等于CPU忙不过来，关键是区分是CPU饱和还是I/O等待。

很多初学者不知道这个判断方法。你执行uptime和top，看load relative到CPU核数的倍数，再看CPU那一行的%us/%sy/%wa三个数字。

• 如果%us（用户态CPU）高，说明业务进程在真实计算，比如大量编码、压缩、复杂SQL排序。
• 如果%sy（内核态CPU）高，说明系统调用频繁，常见于大量小文件读写、网络中断风暴、系统调用死循环。
• 如果%wa很高，说明I/O在排队，进程大部分时间在等磁盘返回，这时候load高其实是磁盘拖的，CPU反而是闲的。

这招非常关键。因为处理方式完全不一样：CPU高，你要找是哪个进程在烧CPU，考虑扩容、优化代码、限流；I/O高，你要找哪块盘、哪个文件系统在堵，考虑换SSD、调整I/O调度器、优化读写模式。方向搞反了，怎么做都是白费。

2.2 D状态进程：杀不掉的“牛皮糖”怎么处理

继续看top的输出，你会看到有些进程的状态是D，全称是“不可中断睡眠”（Uninterruptible Sleep）。D状态代表进程正在等待内核I/O返回，比如等磁盘读写、等NFS响应、等设备驱动。

D状态进程最让人崩溃的地方在于：你杀不掉它。kill -9对它无效，因为它压根不在用户态，内核不处理这个信号。它能做的就两件事：等I/O返回然后继续跑，或者永远卡在那儿直到系统重启。

排查命令：

top -b -n 1 ps -eo pid,stat,wchan:32,cmd | grep '^ *[0-9]* D' cat /proc/loadavg

注意wchan列，它会告诉你进程卡在内核哪个函数里。比如卡在blkdev_issue_flush就是等磁盘flush完成，卡在wait_on_buffer就是等缓冲区I/O，卡在nfs_wait_bit就是NFS挂载有问题。这个信息能帮你快速定位是本地磁盘还是网络存储的问题。

D状态进程一多，系统基本半瘫痪。新进程调度不进来，SSH都可能连不上，表现形式就跟死机一样。处理路径是：先看I/O设备（磁盘、RAID卡、存储网络），如果I/O没问题再看是不是文件系统卡住，最后考虑内核驱动bug。实在等不了就重启，但重启前一定用前面命令把现场信息留下来。

2.3 内存耗尽与OOM Killer的真凶定位

内存撑爆是另一大夯机来源。物理内存耗光、swap又不够的时候，Linux内核的OOM Killer会启动，开始按分数杀进程。重点来了：杀进程只是表象，你要回答的问题是“谁把内存吃光的”。

排查命令：

free -h ps aux --sort=-%mem | head -20 journalctl -k | grep -i oom grep -i 'out of memory\|oom-killer' /var/log/messages

我处理过很多内存OOM的案例，发现真正的吃内存大户往往是这几种：JVM堆内存被设置成物理机的90%以上，高峰期直接爆掉；中间件线程池配置过大，每个线程占1MB栈空间，几百个线程就几百MB；还有数据库的buffer pool、连接缓存、排序缓冲，叠加起来非常吓人。

有人会问：Linux的page cache是不是占内存的“元凶”？确实，你用free看，cached那一栏经常很高，但这通常是好事——page cache是文件缓存，内核会在内存紧张时自动回收。我不建议一看到内存红就去清drop_caches，这个操作治标不治本，甚至会短暂拖慢性能。先查进程，再考虑清缓存。

另外提醒一个容易被忽略的点：swap的设置。如果swap文件或者swap分区在机械盘上，而系统频繁swap，内存再叠加磁盘I/O，服务器慢到跟死机一样。检查vm.swappiness，一般设置为10左右比较合理，具体值根据业务定。

3. 硬件健康排查：磁盘、内存、供电散热的坑

如果系统资源层查了一圈，D状态进程不多、负载也不高、内存正常，但服务器仍然时不时夯死，那就要往硬件方向排查了。硬件的坑在于它不一定会主动报错，很多时候是“带病工作”到某一天突然彻底趴下，表现为周期性、间歇性的夯机。

3.1 磁盘是最“阴险”的潜伏者

磁盘故障在硬件问题里排名第一，因为它太会装了。RAID卡上的盘出现“降级”，系统可能还在跑，但性能断崖式下跌；某块盘开始大量坏道重映射，每次I/O碰到坏扇区就卡住，表现就是“运行几天就卡死，重启又好了”。

常用排查命令：

dmesg | grep -i 'error\|fail\|timeout\|I/O error' | tail -50 cat /proc/mdstat # 软RAID状态 smartctl -a /dev/sda | grep -E 'Reallocated_Sector|Pending_Sector|UDMA_CRC' iostat -dx 1 3 # 看 %util、await、svctm

smartctl是重点。Reallocated_Sector_Ct（重映射扇区数）只要非0，而且持续增长，这块盘基本可以判死刑了。Pending_Sector代表有扇区正在等待重映射，也是危险信号。UDMA_CRC_Error_Count高一般代表数据线或者背板接触不良。

如果用的是硬RAID卡，比如MegaRAID、LSI，建议直接看卡的日志：

storcli /c0 show all storcli /c0/e0/s0 show all | grep -E 'Status|Media Error|Other Error'

媒体错误和“Other Error”计数器只要非0，就说明盘已经出了问题，哪怕当前RAID状态还是Online，也建议尽快安排备件替换。我见过太多“Online但随时会挂”的盘，等到真的挂了再处理，业务已经断了一轮。

3.2 内存ECC错误与间歇性夯机

内存故障我把它排在第二，因为它的表现太有迷惑性了：稳定运行几个月，突然一天夯机，重启后又能正常跑。这种“间歇性夯机”很大概率是内存颗粒退化，或者ECC纠错机制在频繁“救火”。

内存ECC分两类：Correctable（可纠正）和Uncorrectable（不可纠正）。可纠正错误意味着系统能自己纠错，但纠错次数多了，说明内存颗粒已经在劣化；不可纠正错误一旦出现，往往直接宕机或者panic。

排查命令：

grep -i 'memory error\|ECC\|Corrected' /var/log/messages | tail -50 dmidecode -t memory | grep -E 'Locator|Speed|Part Number'

很多服务器厂商的带外管理面板（iDRAC/iLO）里有内存状态页，能直接看到每个内存槽的错误计数。出现Uncorrectable错误就直接换条子，别扛。出现持续增长的Correctable错误，建议也安排更换，别等它变成不可纠正的那天。

顺带提一句Windows环境。很多Windows服务器蓝屏死机，大家第一反应是打补丁、查驱动，往往忽略硬件。我之前处理过一台Windows Server频繁强制重启的服务器，查来查去最后是两条内存持续报ECC错误，跟系统无关。蓝屏和Linux的panic很多时候根因是同一个硬件问题，带外管理日志要第一时间看。

3.3 温度、电源与降频保护的连环问题

散热问题在夯机排查里也很常见，尤其在夏天和机柜密度高的机房。常见的链路是这样的：机柜风道堵了 → CPU温度过高 → 主板触发降频保护 → 性能暴跌 → 服务超时堆积 → 看起来就像死机。

排查要点：

• 登录带外管理面板，看温度和功率读数，确认是否接近告警阈值。
• 执行sensors看各个传感器温度。
• 确认风扇转速，有没有fan告警，有没有风扇不转。

sensors dmesg | grep -i 'temperature\|thermal'

还有一个容易被忽略的：电源模块冗余失效。双电源服务器如果一路电源坏了，负载全压到另一路，另一路可能过载，尤其在高峰负载时直接保护性断电，服务器瞬间崩溃。带外管理面板的电源状态一定要看，电源告警日志往往在夯机前就已经存在。

液冷服务器的温控策略更复杂一点，冷板、泵、冷却液温度都有传感器，但排查逻辑一样：任何“过热 → 降频 → 卡死”的链路，根因都在散热或者电源供给上，别在系统层瞎折腾。

4. 内核和系统日志：所有谜底其实都在里面

前面查了资源、查了硬件，如果还没锁定问题，剩下的答案基本都在日志里。这是排查夯机的最后一道关，也是最考验功力的一关。很多兄弟觉得日志多、看不懂，其实只要抓住几个关键入口和关键词，比瞎猜效率高得多。

4.1 dmesg 与内核现场关键词

dmesg是内核的日志缓冲区，记录了从开机到现在的内核消息。夯机排查里，我最关注的是panic、BUG、call trace、I/O error、timeout这几个词。

dmesg -T | grep -i 'panic\|BUG\|warning\|call trace' | tail -100 dmesg -T | grep -i 'error\|fail\|timeout' | tail -100

很多兄弟不知道dmesg -T这个参数，它能把内核日志的时间戳转换成人类可读的时间，排查时和系统日志时间线对比，特别实用。如果服务器重启过，dmesg只会显示本次开机后的消息，所以夯机现场的第一手信息最好在刚出问题时就看，别等重启完再看，那时候很多东西已经丢了。

4.2 syslog与journalctl的定位技巧

系统日志文件一般存在/var/log/messages或者被systemd的journal接管。我们重装系统后，系统日志经常被清空，但重启前的历史日志在某些配置下还能保留。

排查命令：

journalctl -xe -n 200 # 最近200条带错误提示 journalctl -p err -n 100 # 只输出错误及以上级别 tail -200 /var/log/messages grep -i 'error\|fatal\|timeout\|deadlock' /var/log/messages | tail -100

journalctl -p err这条命令效率很高，会把内核、systemd、应用的所有错误一次性列出来，比你在几万行日志里翻快得多。注意journal日志默认可能不持久化，如果服务器总是重启，建议提前配置Storage=persistent，否则重启后日志目录可能只剩开机的信息。

业务进程的日志也很关键。比如Java应用的gc日志、Tomcat的catalina.out、MySQL的error log、Nginx的error log，这些才是判断“应用层夯住”的直接证据。找到业务日志和系统日志的交叉点，往往是破案的突破点。

4.3 SysRq魔术键：系统假死时最后的现场留存

如果系统已经假死到SSH进不去、控制台操作卡死，还有一个最后的抢救手段——SysRq魔术键。内核预留了一组组合键，可以在极端情况下打印系统状态，甚至强制重启。

前提是内核参数开启了：

echo 1 > /proc/sys/kernel/sysrq # 或者 sysctl -w kernel.sysrq=1

然后在带外KVM控制台或者物理键盘上，按组合键发送命令：

• Alt+SysRq+T：打印当前所有任务列表，你知道谁在跑就知道谁卡住。
• Alt+SysRq+M：打印内存信息，看内存是否耗尽。
• Alt+SysRq+W：打印不可中断/被阻塞的进程状态。
• Alt+SysRq+S：紧急同步所有文件系统，尽量保住数据。
• Alt+SysRq+B：强制重启。

很多人听到这一套觉得很高端，其实它就是内核预留的“后门”。关键在于：彻底放弃抢救之前，先打一串T、M、W，把内核现场留下来。这些输出在重启前会显示在屏幕上，拍照或者记录输出，对事后定位是救命稻草。

5. 网络层“假夯机”：服务器活着，业务却断了

网络故障经常会伪装成服务器夯机。业务方着急地喊“服务器挂了”，其实服务器活得好好的，CPU、内存、磁盘全正常，就是网络收发包出了问题。这种“假夯机”在现场尤其容易误导人，所以我把网络排查也放进这套方案里。

5.1 连接数、半连接队列与“秒杀式”崩溃

最典型的是海量连接把端口或者连接队列打满。我处理过一个秒杀场景，应用服务CPU和内存完全正常，但用户就是连不上。排查发现nginx的并发连接数到了上限，再加上SYN半连接队列被打满，新连接握手过程都完成不了，表现就和“服务器挂了”一模一样。

排查命令：

ss -lnt ss -st netstat -anp | grep 'SYN_RECV' | wc -l netstat -s | grep -E 'SYNs to LISTEN|drop'

ss是netstat的现代替代，性能更好、输出更全。主要看两个指标：一是已建立连接数是否接近somaxconn，二是半连接队列（SYN_RECV）是否满。半连接异常高，要么是SYN Flood类流量，要么是后端服务响应慢导致大量连接堆积。这时候不能只盯着服务器，要结合网关、负载均衡、防火墙的监控一起判断。

如果确认是被大量连接打满，优先调内核参数tcp_max_syn_backlog、net.ipv4.tcp_syncookies，但本质还是要看后端为什么处理不过来——是线程池太小，SQL太慢，还是下游依赖超时。连接数只是症状，后端容量才是根因。

5.2 网卡丢包与协商异常，看起来像死机

网卡物理损坏、驱动bug、固件问题也可能造成“看似死机”的假象。网卡如果进入了异常状态，收包不处理、发包发不出去，应用层自然全挂，但系统负载看着不高——因为问题发生在数据链路层，CPU根本感知不到。

排查命令：

ip -s link ethtool eth0 ethtool -S eth0 | grep -i 'err\|drop'

重点关注几个计数器：rx_error、rx_dropped、tx_timeout、tx_dropped。如果tx_timeout持续递增，网卡基本已经“半死”状态，常见于老旧网卡驱动兼容性问题，或者网线/模块光衰过大。rx_dropped高也可能是接收队列溢出或者防火墙drop，需要进一步看ethtool -S的详细分类。

很多Linux发行版默认没有ethtool，需要提前装好。这就是平时运维的“弹药储备”价值，等夯机了再装机已经来不及了。

6. 高频原因速查表与两个实战复盘

这部分我把自己历年处理过的夯机案例提炼成一张速查表，再单独复盘两个印象最深的案例。你遇到问题可以先对着表自查，比自己从零摸索快得多。

6.1 夯机原因对照表，直接对照排查

这张表不是我编出来的，是这些年真金白银踩出来的。每个方向背后都有案例，比如“内存持续升高”那条，我处理过三次都是JVM堆配置过大导致的；“偶发重启加温度告警”那条，几乎每次都指向机房机柜的散热盲区。

6.2 两个真实案例：间歇性重启背后的真凶

有一个案例我记得特别清楚。某天凌晨2点，公司一台数据库服务器夯死，所有连接超时，重启之后能正常用，但过一两天又夯一次。第一次排查我以为是磁盘I/O问题，因为夯机时iostat显示util很高。结果重启后我重新检查，发现每次夯机前，/var/log/messages里都有一条/dev/sda: I/O error，紧接着是SCSI层的port reset。

最后用smartctl -a一查，盘上Reallocated_Sector_Ct已经到几千了，坏道重映射导致每次I/O访问到坏扇区区域就卡住。换掉那块盘后，问题彻底消失。这个案例给的最大的教训是：间歇性夯机一定要看smartctl，不要迷信“重启就好”。临时重启维持业务没问题，但根因不挖出来，下一次夯机只是时间问题。

另一个案例是Windows服务器。戴尔R750xs跑Windows Server 2012R2，总在夜间跑批任务时蓝屏死机。运维和开发互相甩锅了好几次，最后我坚持查带外iDRAC日志，发现两条内存条报Correctable ECC错误持续增长，最后触发Uncorrectable直接蓝屏。拔掉故障条子、更换新内存后，跑批任务再也没崩过。这个故事告诉我：跨平台排查时，带外管理日志是统一的突破口。不管是Linux还是Windows，硬件告警信息都在带外系统里，别只在操作系统里打转。

写在最后的几句实在话

最后分享几条自己踩过坑换来的体会，算不上什么高深理论，但都是实打实的运维经验。

第一，夯机排查最忌讳“重装解决法”。不要一出问题就重启、重装、重置，先把现场信息留住。系统日志、内核日志、带外管理日志这三样，是排查的根本。没有现场信息，再厉害的技术也没法定位根因。

第二，时间同步是容易被低估的基础设施。服务器时区和时间不同步，会导致多台服务器日志时间线对不上，排查集群夯机时恨不得砸键盘。把NTP或者chrony配置好，让所有服务器的时间保持一致，排查效率能提升一个档次。

第三，真正优秀的运维不是等夯机了才排查，而是平时就把监控、日志、带外管理工单这些准备做好。我给自己定的目标是：服务器夯机后，10分钟内给出初步方向，30分钟内定位到具体原因。这个目标靠的不光是技术积累，更是流程成熟和工具完备。

希望这份排查方案能帮你在下次遇到服务器夯机的时候，少走点弯路，少熬几个夜。毕竟运维这行，最重要的不是“我能修”，而是“我能快准狠地修好”。