硬件罢工、软件崩溃、网络失联、环境捣乱，其中硬件故障占比最高，宕机事故里相当一部分都跟硬盘、内存、电源有关。
很多新手运维一看到服务器报警就头皮发麻，其实大部分故障都有迹可循，搞清楚这些基础问题,起码能让你在老板面前多撑十分钟。
硬件故障：服务器最直接的“物理伤害”
服务器硬件故障是运维老手的必修课，硬件这东西不讲情面，坏了就是坏了,但你得能从蛛丝马迹里判断到底是谁在闹脾气。
硬盘故障：数据安全的头号杀手
硬盘是服务器里故障率最高的部件，没有之一，机械硬盘内部有磁头和盘片，高速旋转下稍有震动或灰尘就可能出坏道，固态硬盘虽然耐摔，但写入次数有限,主控芯片也会老化。
常见的硬盘故障信号包括：
- 开机自检卡在RAID界面，提示硬盘掉线
- 系统日志里频繁出现I/O错误，读写速度骤降
- 硬盘指示灯异常闪烁或干脆不亮
- 服务器运行中听到“咔哒咔哒”的异响，这是磁头敲盘的经典症状
遇到硬盘报警，别犹豫，第一时间检查RAID阵列状态，用管理卡界面或命令行工具看是单块盘掉线还是阵列整体损坏，单盘故障在热备盘存在的情况下通常不影响业务，但阵列崩溃或者多盘同时掉线,那就得准备数据恢复了。
内存故障：看似随机实则规律
内存故障最迷惑人，因为它表现得很“随机”，系统跑着跑着突然蓝屏，或者某个进程莫名其妙报错，重启后又恢复正常,这种间歇性故障最折磨人。
内存出错的特征其实有迹可循：
- 同一进程反复崩溃，错误日志指向不同的内存地址
- 服务器在负载高峰期更容易宕机
- 系统启动时蜂鸣器报警，不同报警音对应不同内存插槽
排查内存问题，最实用的办法就是跑Memtest86+，让机器全内存跑个四五轮循环，不过在实际生产环境，更快的办法是直接替换排查把疑似内存条拔下来，换一根确认没问题的插上去,跑几天看是否复现。
电源与散热：机房里的隐形杀手
双电源服务器如果一路电源挂了，另一路在硬扛，你可能完全察觉不到，直到另一个电源也撑不住了，整台机器直接断电，这就是为什么监控系统必须覆盖电源状态,不能只看服务器是否在线。
散热问题更隐蔽，机房空调出风口被堵、服务器前面板积灰，都可能让进风温度在半小时内飙升，CPU过热会触发降频，性能断崖式下跌，但服务器看起来还在“正常运行”，行业共识认为，机房温度控制在18-27摄氏度是设备长期稳定运行的基础条件。
- 进风口温度超过35度就要警惕
- CPU温度超过85度会自动降频保护
- 风扇转速异常升高且持续不降，多半是散热通道堵塞
软件层面：系统与服务的“逻辑死锁”
硬件没塌，软件翻了车,这种故障更考验排查思路。
系统崩溃与内核报错
Linux系统跑着跑着突然无法SSH登录，或者Windows Server蓝屏自动重启，先别急着重装系统，查看系统的日志目录，Linux看/var/log/messages或journalctl -xe，Windows看事件查看器里的系统日志，通常能找到具体的崩溃原因，内核升级后导致的驱动不兼容,是常见诱因之一。
服务进程僵死与端口冲突
服务器本身没宕，但网站打不开、接口超时，多半是服务进程出了问题，用ps aux看进程状态，如果发现进程处于僵尸状态（Z），或者CPU占用飙到100%但业务毫无响应，那就得考虑重启服务或调整配置了，端口冲突也是个老问题，服务宕了但端口还被占用，新进程起不来，netstat -tlnp查一下,把残留进程杀掉再放服务。
配置变更引发的连锁故障
运维圈有条不成文的规矩：大多数故障都是改出来的，值班期间没事别手痒去动配置文件，如果有变更需求，一定要走变更流程,做好备份和回滚方案。
- 修改/etc/配置文件前先复制一份带时间戳的备份
- nginx或Apache改完配置先跑
nginx -t或apachectl -t测试语法 - 数据库连接数、缓存大小等参数调整要小幅多次，别一步到位
网络故障：机房里的“交通瘫痪”
服务器网络出问题，业务方第一反应就是“服务器挂了”，但你心里得门儿清很多网络故障根本不关服务器的事。
基础网络排查步法
先ping网关确认本机网络栈是否正常，再ping公网IP判断路由链路，最后ping域名看DNS解析有没有出问题，如果ping IP通但ping域名不通，那问题出在DNS上，检查/etc/resolv.conf或Windows的网络适配器设置，内网服务器之间不通，确认一下VLAN划分和防火墙策略，安全组、iptables规则改过之后,最常见的就是把正常流量也拦掉了。
带宽与连接数瓶颈引起的业务卡顿
服务器CPU、内存都平稳，但业务反馈页面加载极慢，这时候要看看带宽是跑满了，用iftop或nload看一眼实时流量，有时候是有人在上传大文件、有人在跑同步任务，把出口带宽吃干了，连接数满也是相似的道理ss -s看socket统计，如果TIME_WAIT或ESTABLISHED数量异常高,多半是短连接请求过多或连接未被正常释放。
故障排查方法：让新手也能稳定“编剧”
头疼医头脚疼医脚是排查大忌，很多故障环环相扣，得按顺序来,才不会把简单问题搞复杂。
先硬件后软件，先外设后核心
排查流程有优先级,这个顺序能帮你省掉大量无效操作：
- 先查电源指示灯、各硬件指示灯是否正常
- 再看系统能否正常引导，有没有报错画面
- 检查系统日志和硬件日志，二者结合判断
- 最后才考虑重装系统换硬件等大招
日志定位法：让服务器“开口说话”
dmesg命令查看内核最新日志，硬件故障和设备认领信息都会在这里出现journalctl -u 服务名查看指定服务的启动和运行日志- 应用日志一般放在
/var/log/或者应用自身目录的logs文件夹里 - Windows系统的事件查看器→Windows日志→系统，红色错误级别记录就是重点
日志信息虽多，但别大海捞针，先用时间段过滤，再按错误级别筛选,基本能锁定核心问题。
机房环境与物理因素：容易被忽视的“暗礁”
服务器内部线缆松动、板卡上的灰尘积太厚、机柜里网线被踩断这些看似低级的问题,在真实机房环境里出现的频率远高于你的想象。
- 机柜内设备密集，散热通道设计不合理，服务器长期在高温临界点运行
- 网线接头氧化或松动，导致间歇性丢包，间歇性网络故障排查很头疼
- 电源线被误碰脱落，或者PDU（电源分配单元）过载跳闸，直接整柜断电
进机房巡检时，摸一下服务器外壳温度、看一眼指示灯状态、理一理线缆走向，花不了十分钟,但能避开不少倒霉事。
Q&A：服务器基础故障相关问题排查
服务器硬件故障怎么排查？
先看指示灯和报警声音，再进管理卡界面查看硬件健康状态，开机自检阶段密切关注BIOS报错和RAID卡信息，进入系统后查看日志，如果是线上业务，建议优先切换流量再慢慢排查,保障业务优先。
服务器宕机后第一件事该做什么？
先确认服务不可用的影响范围，是单台机器还是整个集群，单台机器宕机，先尝试通过带外管理接口（如iLO、iDRAC）或物理控制台重启；集群多台宕机，优先检查电源、网络交换机和机房环境，记录宕机时间点和系统断电前的最后日志,为后续定位留下证据。
服务器故障日志怎么看？
Linux系统优先查看/var/log/messages、/var/log/syslog和内核日志，用tail -n 500按时间顺序查看最新记录，Windows系统打开事件查看器，过滤级别为“错误”和“严重”的事件，重点关注系统、应用程序和硬件事件节点，日志看不懂的报错代码，复制到搜索引擎里搜,往往能直接找到社区里的同类案例和解决思路。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/771511.html
