云服务器系统异常排查流程?

做了这么多年运维，我越来越觉得，云服务器出问题不可怕，可怕的是没有一套清晰的排查流程。每次系统一异常，团队里三个人就有三种不同的排查顺序，有人先看日志，有人先重启，还有人直接提工单找云厂商，乱成一团。后来我逼着自己把每一次故障的处理步骤都记下来，归纳出一套从下到上、从外到内的排查流程。今天我就把这个流程掰开揉碎了讲给你听，配合几个我亲历的典型案例，希望能帮你建立起自己的“肌肉记忆”。

第一步：明确异常现象，确认影响边界

系统异常这个词太宽泛了。是服务器完全无法登录，还是登录上去之后命令执行特别慢?是某个进程突然消失了，还是整个系统频繁重启?不同的异常现象，排查的起点完全不同。

我曾经大半夜接到一个电话，同事说“服务器好像出问题了，你赶紧看一下”。我问他具体什么问题，他说“就是感觉有点卡”。这种模糊的描述让我花了整整一个小时才定位到问题，其实只是某个日志文件写得太快占满了磁盘IO。从那以后，我要求团队在报异常之前必须先回答三个问题：第一，具体什么操作不能做了或者变慢了?第二，大概从什么时候开始的?第三，是个别用户还是所有人都受影响?

举一个清晰的案例。某次一台Nginx代理服务器出现异常，现象是SSH可以正常登录，但执行任何命令都要等十几秒才有响应，连按个回车都感觉有延迟。这个现象本身就给了我们重要提示：系统没有完全死锁，但交互响应极慢，通常意味着某种资源阻塞或者进程调度出了问题。如果我们上来就重启服务器，可能就错过了在现场抓取关键信息的机会。

第二步：尝试保留现场，不要轻易重启

这是很多新手最容易犯的错误。服务器一卡或者一报错，下意识就去控制台点“重启”。重启确实能解决很多临时性的问题，比如内存泄漏、僵尸进程、死锁等，但重启也意味着丢失了宝贵的“案发现场”。很多异常的根因，只有在系统运行态下才能抓到。

我记得有一台数据库云主机出现了周期性负载飙升，每次持续五分钟然后自行恢复。负责的同事每次都是直接重启数据库进程，恢复业务了事，但这个问题隔几天就复发一次。后来我坚持让他不要重启，等下一次异常发生的时候，我们提前登录，用vmstat和perf top实时采样。结果发现每次负载飙升之前，都有一次慢查询触发了大量的临时表磁盘写入，磁盘IO队列深度瞬间冲到几百，导致整个系统卡死。如果把那个慢查询优化掉，问题就根治了。如果每次都用重启糊弄过去，这个病根永远都在。

当然，保留现场不是说不重启业务。如果线上服务已经中断了，你当然可以先把流量切到备用节点，然后在这台有问题的服务器上做排查。实在没有办法必须重启的时候，建议先执行一些关键信息的收集命令，比如ps auxwf、netstat -an、dmesg -T、journalctl -n 500，把这些输出保存到文件里，然后再重启。这样你至少保留了重启前的快照。

第三步：从最底层的系统日志开始查起

当你决定开始排查时，系统日志永远是最好的切入点。Linux把所有内核和大部分系统服务的日志都记录在/var/log/目录下，其中最重要的几个是：messages或者syslog包含了系统整体的内核消息和常见服务日志，dmesg记录了内核环形缓冲区的信息，尤其适合看硬件或驱动相关的错误，还有kern.log专门记录内核产生的日志。

我处理过一起离奇的系统异常：一台云主机每隔两三天就会突然变成只读状态，所有写操作都报“Read-only file system”。重启之后恢复正常，但过段时间又复现。查看/var/log/messages，发现大量“EXT4-fs error”和“Buffer I/O error”的记录，指向磁盘扇区读取失败。这很明显是底层磁盘或者虚拟化层的存储出现了问题。我们把日志提供给云服务商，他们排查后确认是宿主机的一块物理SSD有坏块，导致这台云主机的虚拟磁盘被错误地标记为只读。最终他们把虚拟机热迁移到了另一台健康的宿主机上，问题再也没出现过。如果没有系统日志，我们只会在自己的应用层瞎折腾，永远找不到真相。

另一个案例是内核恐慌导致的系统无故重启。用户说服务器大概一周就会自动重启一次，云控制台里的重启记录显示是“用户主动重启”，但没有人操作过。通过查看dmesg输出，发现了“Kernel panic - not syncing: Fatal exception”的字样，紧接着是一段调用栈，指向了某个内核模块。后来排查发现是服务器的内核版本与某个安全软件的内核模块不兼容，升级内核之后问题解决。

所以当你遇到系统异常，别着急跑各种复杂的命令，先把系统日志的最后几百行拉出来看一看。很多时候，问题的答案就明明白白地写在日志里，只是你没有去看。

第四步：检查系统资源与运行状态

如果日志里没有明显的错误信息，或者你看到的异常现象属于“慢”而不是“挂”，那就要从系统当前的资源使用情况入手。这一步骤我习惯按照CPU、内存、磁盘、网络、进程的顺序来做。

先用top或htop看一眼整体的负载。我需要特别说明的是，load average这个值在云主机环境下有时候会“骗人”。因为它统计的是正在运行和不可中断睡眠状态的进程数。如果你的磁盘很慢，大量进程在等待IO，load average可以非常高，但CPU使用率却很低。这时候如果你只盯着CPU看，就会觉得系统明明很空闲为什么卡得要死，殊不知问题的根源在磁盘。

再来看内存，用free -h。注意看available这一列，它表示系统实际可用的内存，而不是简单的free加上buff/cache。如果available很小而swap used很大，说明内存已经不够用了，系统在频繁地换页，这会导致整体性能急剧下降。我遇到过一台运行多个Node.js应用的云主机，开发者没有给每个进程设置内存上限，结果它们互相争抢，最后把swap用到了4GB，磁盘IO全部消耗在换页上了，整个系统慢到无法操作。给每个进程加上内存限制、并且适当增加云主机内存后，问题才缓解。

磁盘部分，用iostat -x 1来查看每个磁盘的利用率、读写延迟、队列长度。其中有一个关键指标叫await，即平均每次IO请求的处理时间。正常情况下应该低于十毫秒，如果超过五十毫秒甚至上百毫秒，就意味着磁盘性能已经严重不足。另外，如果你用的是云上的网络存储(比如云硬盘)，它的性能跟购买的IOPS和吞吐量有关，有时候其他云主机争抢同一个存储后端也会导致你的IO延迟飙升。这种事情在系统层面没有太好的办法，你能做的就是查看云监控里的存储性能指标，确认是否达到了规格上限，如果是，考虑升级或者迁移到性能更优的存储类型。

网络部分不是所有系统异常都会涉及，但如果你发现系统整体行为卡顿，而top和iostat都看不出异常，不妨用iftop或者nethogs看看有没有异常的网络流量。有一次我们的一台云主机莫名其妙的响应缓慢，top看CPU和内存都正常，iostat看磁盘也空闲，但用netstat发现建立了大量的外部连接，状态基本都是ESTABLISHED。进一步追踪发现，这台机器被植入了挖矿木马，木马程序与外部矿池保持着大量长连接，消耗了系统的连接跟踪表和部分CPU时间片，导致正常服务的网络请求时延增加。清理木马并加固安全之后，系统恢复正常。

第五步：聚焦进程和用户行为

有时候系统本身没有问题，而是某个用户的进程异常导致了整个机器的不稳定。这种情况在多用户的云主机上尤为常见，比如你的服务器同时跑了多个业务进程，或者开放了运维权限给好几个开发人员。

我曾经遇到一个案例，一台云主机的CPU使用率每隔半小时就会飙到100%，持续几分钟后又降下来。用htop观察到，有一个cron用户的进程列表里反复出现一个名字随机的脚本。查看/var/log/cron，发现有一条定时任务每隔三十分钟从某个远程服务器下载并执行一个脚本。这是一个明显的入侵迹象。我们禁用这个定时任务，清理相关的文件和计划任务，并且检查了系统的用户列表，发现有一个不认识的ssh公钥被添加到了authorized_keys里。入侵者是通过弱密码暴力破解进来的。从那以后，我们强制所有的云主机都使用密钥登录，并且定期审计系统用户和定时任务。

另外，还有一种比较隐晦的系统异常：某个进程不停地fork子进程，最终导致进程数达到上限，无法创建新进程。这种“fork炸弹”式的故障，有时候是人为的恶意行为，有时候是程序bug导致的无限递归。遇到这种情况，你可以用ulimit -u临时限制用户的最大进程数，然后找到父进程把它杀掉。但是事后一定要排查清楚是代码问题还是安全问题。

第六步：检查文件系统完整性

文件系统损坏在物理服务器上比较常见，但在云主机上也会发生，尤其是那些没有优雅关机的实例。比如你直接在控制台强制断电重启，或者云平台底层发生了故障，都有可能导致文件系统元数据不一致。

我亲身经历的一次故障：一台云主机重启之后，无法正常启动，通过管理VNC登录看到系统进入了紧急模式，提示“Failed to mount /data”。这意味着存放数据的分区挂载失败了。我们用了fsck命令来检查和修复这个文件系统，输入fsck -y /dev/vdb1，等了好一阵子，修复了大量的inode和块引用错误。再重启之后，分区成功挂载，数据也没有丢失。但这里要特别提醒你，执行fsck之前一定要确认这个分区没有被任何进程使用，最好是用系统盘启动到紧急模式或者是单用户模式下来操作。另外，如果文件系统严重损坏，fsck可能会导致部分数据丢失，所以定期做数据备份永远是最保险的。

还有一种常见的情况是磁盘的inode被耗尽。即使磁盘还有几GB的空闲空间，但如果小文件太多，inode用完了，也无法创建新文件。用df -i可以查看inode的使用情况。我们遇到过一台缓存服务器，因为某个程序的bug，每秒生成几万个极小的临时文件，不到一天就把inode消耗殆尽，导致服务无法写入任何新文件。找到原因后，我们修改了程序逻辑，增加了临时文件的自动清理机制，并且对inode使用率设置了单独的监控告警。

第七步：关注内核参数和系统限制

Linux内核有大量的参数控制着系统的行为，比如文件描述符上限、TCP连接追踪表大小、内存过度分配策略等等。当某些内核参数配置不合理时，系统在高负载下就会出现异常。

一个典型的例子是net.ipv4.ip_local_port_range参数，它定义了本地端口范围。如果你的服务器需要对外发起大量短连接(比如作为代理或者爬虫)，默认的端口范围可能不够用，导致无法建立新的连接，系统日志里会出现“Cannot assign requested address”的错误。我们也遇到过系统日志里出现“nf_conntrack: table full, dropping packet”的警告，这是因为连接追踪表满了，导致后续的网络包被丢弃，表现出来就是部分访问超时或者失败。解决方法就是调整net.netfilter.nf_conntrack_max参数，或者缩短超时时间。

另一个容易被忽视的系统限制是/etc/security/limits.conf里的各种软硬限制。有时候你发现某个服务进程的线程数上不去，或者无法打开更多的文件，就是nofile或者nproc的限制太小。我们有一个Java微服务，在高并发时需要同时维持数千个数据库连接，结果一直报“Too many open files”。查了才发现，系统的默认限制是1024，根本没有考虑到这个服务的大连接特性。修改limits.conf并重启进程后，问题消失。

一套完整的排查流程案例复盘

让我用一个真实的复杂案例，把上面所有的流程串联起来。

去年夏天，我们的一个日志采集集群出现大面积异常。现象是：十几台云主机中有三四台每隔一段时间就会失去响应，既不能SSH登录，也不能通过监控系统获取数据，看起来就像彻底挂掉了。每次必须从控制台强制重启才能恢复，但过几个小时又会重演。

第一步，明确现象。我们确认了只有部分节点异常，而且异常发生的时间点在每天的凌晨零点到两点之间比较集中。第二步，保留现场。我们特意等到异常即将发生的一个晚上，提前登录到一台有异常倾向的机器上，打开多个终端，分别运行dmesg -w、vmstat 1、iotop、journalctl -f，实时观察。

第三步，查看日志。当异常真正发生时，dmesg窗口里跳出了“soft lockup - CPU stuck for 22s”的信息，紧接着是“INFO: rcu_sched self-detected stall on CPU”。这说明内核检测到某个CPU核心卡住了超过二十秒，导致整个系统响应停滞。同时journalctl里发现了大量“kworker”进程的警告。

第四步，检查资源。vmstat显示在异常发生的那一刻，system栏里的上下文切换数值呈指数级飙升，从几千一下子跳到几十万。这通常意味着某个中断风暴或者锁竞争。iotop观察到磁盘写入非常少，基本排除了磁盘IO导致锁死的可能。

第五步，聚焦进程。我们通过perf top采样，发现一个名为“acpi_os”的内核函数占用了极高的CPU时间，而ACPI通常与电源管理和硬件中断有关。这引起我们的警觉，因为云主机本不应该深度涉及ACPI相关的操作。

第六步，联系云厂商。我们把所有的日志和采样数据打包发给云服务商的技术支持。他们从宿主机的层面分析后发现，这批云主机所在的物理节点有BIOS缺陷，在某些条件下会向虚拟机注入错误的ACPI事件，导致虚拟机内核陷入无限循环。最终他们升级了宿主机的微码，并将我们的虚拟机热迁移到了其他节点。

这个案例让我深刻地意识到，一套完整的排查流程不仅能帮你自己理清思路，还能在需要外部支持的时候，提供清晰有力的证据。没有流程，你只会东一榔头西一棒子，最终在混乱中浪费时间。

总结

云服务器系统异常排查，本质上是一场与时间和不确定性的博弈。你需要一套从底向上、层层递进的流程：先明确异常现象是什么，再尽可能保留现场，然后查阅系统日志，接着检查CPU、内存、磁盘、网络四大资源，之后聚焦到具体进程和用户行为，必要时检查文件系统完整性和内核参数。每一步都要有明确的产出，要么排除了某种可能性，要么锁定了嫌疑对象。

我想特别强调一点：流程不是死的，你可以根据实际情况调整顺序，但绝对不能跳过关键步骤。尤其是查看系统日志和保留现场这两个习惯，能让你的排查效率提升好几倍。另外，别忘了利用云厂商提供的监控和诊断工具，有些云平台甚至有健康检查脚本和自动诊断功能，可以帮你快速定位常见问题。

最后，每一次排查结束之后，都花十分钟写一个简短的事故报告。不用多正式，就写明白了发生了什么、怎么查的、根因是什么、以后怎么防。这些积累起来的小文档，就是你和你团队最宝贵的知识库。下一次当系统再给你脸色看的时候，你会发现自己不再慌张，因为你手里有流程，心里有底气。