1. 为什么我建议每个运维都收藏这份排查清单服务器出故障的时候最怕的不是故障本身而是面对一堆报警信息不知道怎么下手。我见过太多刚入行的同事一看服务挂了就慌了神又是重启又是重装折腾几个小时最后发现只是磁盘满了或者是某个服务忘了开机自启。这种经历经历过一次就知道一套系统的排查思路比临时百度管用得多。这篇文章想讲的是服务器日常运维中最常见的12种基本故障。它们不涉及高深的内核调优也不需要复杂的监控系统就是每一个运维、每一个自己鼓捣服务器的开发者都会遇到的典型问题。从硬件层面的开机无响应、内存报错到系统层面的磁盘爆满、负载过高再到应用层面的数据库连不上、端口被占用我都会拆开揉碎了讲一遍内容包括故障长什么样、一般是什么原因、按什么顺序去查、用什么命令验证以及我实操中踩过的坑。不管你是刚接触服务器的新手还是已经有几年经验的运维这份清单都可以当成一份落地的手册。遇到问题的时候翻到对应小节按步骤走一遍大概率能省下不少折腾的时间。另外文中所有命令都在常见的 Linux 发行版上验证过CentOS、Ubuntu、Debian 系都能直接用Windows Server 的部分场景我会单独标注。2. 服务器出故障之前先看懂症状和影响面在逐条列12种故障之前我想先说一个更重要的逻辑排查故障的第一步永远不是动手改配置而是搞清楚“这台服务器现在到底是什么状态”“这个故障影响到了谁”。没有这个判断很容易在小问题上乱打一气。2.1 怎么快速判断服务器是不是真的“挂了”有一种很典型的场景业务方跑过来喊“服务器挂了”你 ssh 一登机器明明通着负载也不高。这时候不要急着反驳先分清楚是“机器挂了”还是“服务挂了”。机器层面的故障ping 不通ssh 连不上物理机电源灯异常或者云控制台显示实例运行中但你完全无法访问。服务层面的故障机器正常但是某个应用进程没了端口不响应数据库连接被拒网页打不开。这两类问题的排查路径完全不同。机器层面的问题优先看硬件状态、网络配置、云平台告警服务层面的问题优先看进程状态、日志文件、端口监听情况。我见过有人花了一晚上重装系统最后发现只是负载均衡配置把后端摘掉了这种教训一次就够。2.2 故障影响面的快速评估技巧拿到故障通报后最快评估影响面的方式有三个看监控面板、看访问日志、看错误日志的时间线。监控面板CPU、内存、磁盘、带宽有没有明显拐点如果有拐点前后的时间差就是故障发生时间。访问日志nginx 或业务应用的 access log 在某个时间段内5xx、4xx 比例是否突然升高。错误日志应用日志中 Exception、Error 级别的输出通常会在故障前后留下非常完整的现场记录。我自己的习惯是收到报警先花两分钟把这三样扫一遍心里有底了再开始动手。这比直接登录服务器敲命令要高效得多因为你很可能根本不知道去哪里敲命令。3. 12种基本故障的完整拆解与排查路径下面进入正题。这12种故障是我根据这些年实际遇到的情况按“现象、原因、排查、解决”的框架整理出来的。每一个都能独立成篇但放在一起看你会发现服务器出问题其实就集中在几个层级上硬件、操作系统、网络、应用。3.1 第1种机器无法开机或者反复重启现象物理机按电源键没反应或者开机到一半自动重启云服务器在控制台显示运行中但连不上重启后依然无法进入系统。常见原因内存条接触不良或损坏、电源模块供电不足、主板电容鼓包、系统引导文件损坏、内核 panic 后自动重启。排查路径物理机优先看前面板指示灯和报警声不同品牌Dell、HP、浪潮、联想的报错含义不一样说明书里都有对照表。打开机箱重新插拔内存、显卡、硬盘数据线这是最简单也最高频见效的操作。能进 BIOS/UEFI 就进去看硬件识别情况特别是内存容量是否被正确识别、硬盘是否掉盘。如果能启动到 grub 菜单但进不了系统常见原因是引导损坏可以用系统安装盘进入 rescue 模式修复。云服务器出现这种情况优先去控制台看“系统日志”或“VNC 登录”那里能看到真实的开机过程。实操心得很多时候开不了机真的是内存条松了尤其是机房机器搬迁之后。搬动过的机器出这个问题的概率极高我建议物理机开机异常第一件事永远是打开机箱看硬件别一上来就重装系统。3.2 第2种磁盘空间不足导致服务异常现象数据库写入失败、日志文件突然不更新、临时文件无法创建、服务启动时报 No space left on device但 df -h 看起来空间还剩不少。原因分析空间不足可能不只是“文件大”还有 inode 耗尽、被删除文件仍被进程占用、分区挂载异常等情况。排查路径先df -h看空间再df -i看 inode 使用率两条命令必须一起用。用du -sh /* 2/dev/null从根目录往下逐层定位大目录找到是哪个路径在疯狂增长。用lsof | grep deleted查看是否有被删掉但还被进程占用的文件。如果有重启对应进程或服务才能真正释放空间。运维重点磁盘爆满不是一次性事件而是一个过程。平时就要通过 cron 做每日磁盘空间巡检超过80%就该预警。日志定期切割、归档、清理数据库备份保留周期要有明确策略不要等报警了才开始处理。注意清理大文件时先确认是什么应用在写直接删文件不一定有效有些进程会继续占用句柄必须重启进程或者 truncate 文件而不是 rm。3.3 第3种CPU 负载异常飙高现象uptime里的 load average 超过核数好几倍应用响应变慢但 top 命令看到的 CPU 使用率却不是特别高。原因分析load average 高既可能是 CPU 密集型任务也可能是不可中断睡眠的进程太多比如磁盘 IO 卡住了进程在等 IO这种状态也会计入 load。排查路径top -c按 CPU 排序看哪个进程最吃 CPU。按数字 1 看每个核心的使用情况。如果 CPU 使用率低但负载高用iostat -x 1看磁盘 %util 和 wa 的值判断是不是磁盘慢拖累了整个系统。用ps aux --sort-%cpu | head -20拿完整的进程列表。如果是云服务器还可能是同物理机上的邻居吵闹这种情况看监控曲线通常会有规律性。解决思路应用层 CPU 高就优化代码逻辑或者扩容进程异常导致的高占用先确认是不是被入侵再做处理磁盘 IO 导致的假负载核心问题在磁盘去看第5种故障。3.4 第4种内存耗尽触发 OOM Killer现象某个应用进程突然消失/var/log/messages 或 dmesg 里有 Out of memory 的字样系统服务变得极不稳定。原因分析应用内存泄漏、并发量过大、JVM 或脚本引擎堆内存设置不合理、Swap 配置过小或未配置。排查路径free -h看内存总量和 Swap 使用情况top查看进程中 RES 和 VIRT 占用。dmesg | grep -i oom查看操作系统杀掉了哪个进程这是最重要的现场证据。如果 Java 应用经常出问题用 jmap 导出堆内存做分析排查是否有对象没有被回收。给关键服务配置 systemd 的 OOMScoreAdjust 或修改 oom_score_adj让系统在极端情况下优先保留重要进程。实操心得OOM 最坑的地方是系统把进程杀了之后表面上看日志只会有简单的 Killed process如果不看 dmesg 根本找不到凶手。另外别以为加内存就解决一切问题内存泄漏的代码在 512G 的机器上一样能爆。3.5 第5种磁盘 IO 延迟过高或吞吐骤降现象数据库查询无故变慢、文件读写卡顿、iostat 显示 %util 接近100%但应用日志里看不到明显的报错。原因分析机械盘老化坏道、SSD 寿命耗尽、RAID 组重建期间性能下降、批量任务瞬间写入太大、云磁盘类型本身 IOPS 就有限。排查路径iostat -x 1看每个磁盘的 rkB/s、wkB/s、%util、await 值。%util 高不一定有问题还得看 await 是否比平时高。iotop定位是哪个进程在大量读写磁盘。检查是否在跑数据库全量备份、日志清理、批量数据导入之类的定时任务。云硬盘看监控面板的 IOPS 和吞吐量指标超出规格限制会出现排队。解决思路如果确认是磁盘性能不够解决方案无非是提升磁盘规格、把热点数据放到缓存、优化 SQL 减少扫描量、把批量任务错峰执行。如果坏道导致的 IO 错误做好备份之后及时更换硬盘。3.6 第6种网络不通或丢包严重现象服务器 ping 不通、ping 通但 TCP 连接超时、丢包率忽高忽低、外网访问非常慢。排查路径从自身链路开始查ip addr确认 IP 配置没问题ip route确认默认路由存在。ping 网关确认本机到网关是否通如果网关都不通问题在物理链路或虚拟网络配置。ping 公网 IP比如 223.5.5.5确认外网出口是否正常。注意一定要 ping IP不要 ping 域名这样能区分 DNS 问题和网络问题。丢包就用mtr 目标IP分段看是哪一跳出了问题。自建机房的机器注意检查交换机端口模式是否匹配。安全组/防火墙规则、iptables 和云平台的网络 ACL 也要一并核查很多“网络不通”实际上是访问控制被拦了。常见坑服务器本地 ping 自己的公网 IP 是通的但外网访问不了这种情况多半是云平台安全组没放行对应端口。不要先怀疑系统防火墙先看安全组外到内的规则。3.7 第7种SSH 无法连接或频繁断开现象ssh 登录卡在输入密码前的那一步、连上去没多久就断线、连接被拒绝或者是提示 Host key verification failed。排查路径先确认 sshd 服务是否在运行systemctl status sshd查看状态。确认 22 端口是否在监听ss -lntp | grep 22。检查 /var/log/secure 或 /var/log/auth.log看有没有认证失败的记录这能区分是密码错误、网络问题还是有人爆破导致被 fail2ban 拉黑。Host key verification failed 经常出现在重装系统之后清掉本地 known_hosts 里对应的旧记录再连。云服务器还要检查安全组是否放行了 22 端口源 IP 是否限制得过死。经验之谈如果你经常性地需要连一台机器强烈建议用密钥认证而不是密码。配置好之后不仅省去输密码的麻烦还能在 sshd_config 里把 PasswordAuthentication 关掉减少爆破风险。至于很多人问的“怎么每次连服务器不输入密码”就是密钥对里的公钥放到服务器的 authorized_keys 文件里本地私钥留好权限一定要设置正确私钥 600~/.ssh 目录 700。3.8 第8种服务进程崩溃或自动退出现象某个进程运行一段时间就自己退出了systemd 管理的服务会反复重启应用日志的最后几条记录很突然。排查路径看 systemd 日志journalctl -u 服务名 -n 100 --no-pager。查应用日志文件里最后的异常堆栈特别是 OutOfMemory、Segmentation fault、Aborted 这类关键词。如果是 Java 应用带上 -XX:HeapDumpOnOutOfMemoryError 参数崩溃时自动生成 dump 文件事后分析。如果是编译型语言检查是否因为内存越界导致 core dump配合 gdb 看堆栈。排查是否有外部定时任务或监控脚本把它停了比如kill、pkill、重启策略等。实操心得systemd 的 Restarton-failure 配置是双刃剑。进程崩溃后自动拉起确实省心但对于需要维护状态的进程频繁崩溃重启会造成更多数据不一致的问题。我建议线上服务先关掉自动重启人工确认原因后再拉起来不然你会被无限重启的日志淹没。3.9 第9种数据库连接数或端口被占满现象应用报 too many connections 或 Connection refused端口检查发现大量 TIME_WAIT 或 ESTABLISHED 连接服务端口无法绑定。原因分析应用连接池配置过大、慢查询堆积导致连接长期不释放、短连接请求量过高、连接泄漏没关闭、数据库 max_connections 设置偏小。排查路径ss -s看系统连接统计ss -ant | awk {print $1} | sort | uniq -c看各连接状态数量。TIME_WAIT 太多可以调整内核参数 net.ipv4.tcp_fin_timeout 和端口范围 net.ipv4.ip_local_port_range但根本办法还是让应用尽量用长连接。MySQL 中执行show processlist查看当前连接在干什么有没有大量 Sleep 空连接。把应用连接池的最大值调到一个合理区间并设置连接空闲回收时间。经验之谈有一回排查一个“端口被占满”的问题服务器上根本没几个服务最后发现是日志收集 Agent 的 HTTP 连接没走代理每次上报都新建一个 TCP 连接然后堆积成 TIME_WAIT。问题不在服务器而在客户端的使用方式上。3.10 第10种系统时间偏差过大导致认证和同步失败现象HTTPS 证书校验失败输密码登录服务器提示认证错误集群节点间通信报时间戳异常定时任务执行时间与预期不符。原因分析服务器没有配置时间同步或者配置的时间服务器不可用。排查路径date -R看当前时间和时区。timedatectl查看 NTP 同步状态确认 NTP synchronized 是否为 yes。手动执行chronyc sources -v或ntpq -p查看时间源是否处于可达状态。解决思路在 Linux 服务器上装 chrony 并配置好可靠的时间服务器然后开启开机自启。云服务器可以直接用云平台提供的内网 NTP 地址自建机房可以用国内的时间服务器地址。时间同步这个问题看似不起眼但证书校验、分布式事务、日志排障全都依赖它必须重视。提示如果修改了时区记得也要同步修改 crontab 里定时任务的执行时间否则按旧时区算的任务会在错误的时间点执行。3.11 第11种硬件告警风扇、电源、温度异常现象物理机前面板亮黄灯报警IPMI/带外管理系统推送风扇转速异常或温度过高告警机房巡检发现噪音变大。排查路径用ipmitool sensor list查看各硬件传感器读数重点是 CPU 温度、系统风扇转速、电源状态。检查机房环境温度确认空调是否正常工作、机柜风道是否被堵住。如果风扇报错先看是不是灰尘太多导致转速异常清理灰尘后一般能恢复。电源模块报警时优先确认电源线连接和机房供电双电源机器的另一路电源是否正常。实操心得风扇和电源这类硬件告警很多时候不会立刻让机器宕机但它是一个强信号。如果带外管理显示某个风扇转速为0别看机器还在跑就无所谓这种故障大概率在一周内会变成实际宕机。提前安排停机更换比半夜被叫起来处理强得多。3.12 第12种虚拟化或集群环境中的故障转移异常现象虚拟机漂移失败、集群节点心跳丢失、负载均衡后端被健康检查摘掉、共享存储掉线导致服务不可用。排查路径先确认物理宿主机和虚拟化平台控制面是否正常宿主机负载是否过高。检查集群节点之间的心跳网络是否通畅防火墙是否放行了集群通信端口。查看虚拟化平台的日志比如 vCenter、Proxmox、OpenStack 的对应日志。如果涉及共享存储检查存储网络和锁机制确认没有出现脑裂。经验之谈集群环境出问题时最关键的是“恢复优先于排查”。在脑裂场景下两个节点同时认为自己是主节点此时强行干预可能会造成数据损坏。高级做法是先隔离非活跃节点再由主节点恢复服务最后慢慢看日志分析原因。新手在集群故障里最容易犯的错就是一上来乱动多个节点结果越搞越乱。4. 一次真实故障排查的完整过程记录光说不练假把式我分享一个最近遇到的实战案例。事情的过程是凌晨两点监控平台报警一台运行 MySQL 的服务器 CPU 负载持续走高数据库查询变慢部分接口超时。我的排查步骤是这样的先通过堡垒机登录服务器执行uptime看到 load average 已经到 30 以上这台是16核的机器。执行top -c发现 mysqld 进程 CPU 占用接近 900%也就是占了差不多9个核。接着用mysql -e show processlist查看 SQL 情况发现有大量相同的 SELECT 语句在跑状态是 Sending data。进一步分析发现这些 SQL 都在查同一张历史记录表而这张表的数据量因为某个业务任务扩容从200万行涨到了8000万行但索引没有调整。确认没有其他异常后我先给这张表加了联合索引然后暂停了那个业务任务CPU 负载在几分钟内就降下来了。整个过程大概花了30分钟。复盘下来真正的问题不是服务器本身而是应用侧的数据量变化导致了慢查询。这个案例也说明了一个道理服务器故障的根源往往不只在服务器上应用对资源的消耗方式才是常态。5. 故障排查工具与命令速查表为了方便大家随时查阅我把文章里涉及的主要命令整理成了一张速查表。下面的内容建议截图保存或者放进自己的运维笔记里。排查场景核心命令关键输出解读CPU 负载top -c、uptimeload average 连续高于核数说明有瓶颈内存状态free -h、dmesg | grep -i oomOOM 记录显示被杀的进程名磁盘空间df -h、df -iinode 100%时文件无法创建磁盘 IOiostat -x 1、iotop%util 高且 await 高说明盘慢网络连通ping、mtr、ip addr分段判断问题出在哪个链路端口监听ss -lntp、netstat -tunlp确认服务是否正确绑定端口SSH 日志journalctl -u sshd、/var/log/secure查看认证失败来源 IP服务状态systemctl status 服务名查看进程死活和启动报错服务日志journalctl -u 服务名 -n 100查看最近一次崩溃前的日志时间同步timedatectl、chronyc sources -vNTP synchronized 状态和时间源是否可达硬件传感器ipmitool sensor list查看风扇、温度、电源等硬件状态系统日志总入口journalctl -xe大部分系统服务异常会记录在这里6. 排查过程中的三个关键心态分享几个我从实战里悟出来的经验希望在关键时刻能帮你稳住心态。第一先恢复服务再找根因这两件事可以有先后顺序。生产环境里服务多挂一分钟损失就多一分钟。如果确认是某个进程异常先重启服务恢复可用性再去看日志分析原因完全没有问题。不要一上来就想一次定位到底那是理想情况。第二变更记录是排查故障最好的朋友。很多服务器故障不是无缘无故出现的大概率是最近有人改了什么。安全组规则改了发布新版本了定时任务新增了磁盘快照策略变了如果你有完整的变更记录故障排查能少走一半弯路。我强烈建议任何服务器操作都有一个简单的变更记录文档哪怕是群聊里的 所有人 通知都行。第三报警不一定是故障但每个报警都值得看一眼。频繁误报会导致人疲劳等真出问题的时候反而没人响应。科学的做法是完善监控项的阈值比如磁盘使用率80%告警是提醒95%告警才是紧急分级处理而不是把所有事都当成一样的严重级别。7. 一份实用的服务器日常巡检清单最后分享一个我一直在用的每日巡检模板。这套东西不复杂但能提前发现大部分“还没爆发的故障”。硬件层检查 RAID 状态是否正常硬盘灯有没有异常带外管理有没有告警。系统层CPU 负载、内存使用率、磁盘空间、inode 使用率、系统日志中是否有新的 error 记录。应用层核心服务的进程是否在运行、端口是否正常监听、应用日志有没有新的 Exception。网络层外网连通性、DNS 解析正常性、带宽使用情况、安全组与防火墙规则是否被改动过。备份层确认今天的备份任务执行成功并且备份文件可以正常读取。备份不能恢复等于没有备份。这套巡检用脚本自动化执行每天出个报告推送到群里比人肉去看靠谱得多。等哪天真出事了你就会发现平时养成的小习惯才是最大的救命稻草。这次的12种故障和排查方法就先写到这里。下次你遇到服务器报警的时候别慌先深呼吸看看系统日志看看负载曲线按这条思路一步步走问题大概率很快就能浮出水面。