云服务器运行问题排查方法?

你有没有这种感觉：云服务器大部分时间都好好的，但总有一些“小毛病”时不时冒出来。有时候是网站响应突然慢了半拍，有时候是某个脚本执行到一半卡住了，还有时候是SSH连上去感觉按键有延迟。这些问题说大不大，说小不小，但又特别消耗精力。我现在越来越觉得，云服务器运维最考验人的，不是处理那些轰轰烈烈的宕机事故，而是这些说不清道不明的“运行问题”。今天我就把这些年积累的排查方法，从头到尾捋一遍，希望能帮你省下一些半夜挠头的时间。

先搞清楚“运行问题”到底指的是什么

在开始排查之前，我们得先给“运行问题”画个范围。它不是那种服务器彻底挂掉、网络完全不通的“硬故障”，而是服务还在、网络也通，但用着就是不顺畅的“软故障”。常见的有：响应时间变长、偶尔出现超时、CPU或内存使用率异常波动、磁盘IO时不时飙高、网络偶尔丢包或重传、进程还在但像睡着了一样不干活。这些问题有一个共同特点：它们不是一直出现，而是间歇性发作。这就给排查增加了难度，因为你守在机器前的时候，它可能表现正常，你一转身，它又犯了。

我处理过最磨人的一个运行问题，是某台云主机每天凌晨一点左右会有一阵“呼吸急促”。监控显示，那个时候磁盘读延迟会从两毫秒跳到六十毫秒，持续大约十五分钟，然后又恢复正常。白天怎么查都查不出来问题，因为白天根本就没有这个现象。最后我们连续蹲了一周的凌晨监控，才发现是云平台在那个时间段做内部快照，而云主机的磁盘恰好和快照任务落到了同一个存储后端。这不是配置问题，也不是代码问题，而是云平台资源竞争导致的。既然不能改变云平台的内部调度，我们就把业务里那个时间段的离线任务调整到了别的时段，错开了这个高峰期。问题虽然不是彻底“解决”了，但至少不再影响用户体验了。

第一步：先问自己三个问题

当你准备排查一个运行问题时，不要急着登录服务器。花两分钟想清楚三个问题。

第一个问题：问题是什么时候开始出现的?是今天突然出现的，还是一直都有，只是最近变严重了?如果知道确切的时间点，你可以去翻翻那个时间点前后有没有做过变更，比如发布了新代码、修改了配置、增加了定时任务、或者云平台发过维护通知。我有个习惯，每次做变更都会在固定的地方记录下来，哪怕只是在记事本里写一行“下午三点改了Nginx的keepalive参数”。这样出了问题往回查，能省下大半天的时间。

第二个问题：问题的范围有多大?是只有一台云主机有问题，还是同一个集群里的多台都有?是只有某个特定的接口慢，还是整个网站都卡?是只有某个地域的用户反馈，还是全球用户都遇到了?范围能帮你区分问题是出在这台机器自身，还是上游的负载均衡、下游的数据库、或者是网络链路上的某个节点。有一次用户反馈图片加载慢，我们查了自己的服务器，一切正常。后来发现只有某个省份的移动用户反映这个问题，那就是运营商互联互通的老毛病了，不是我们能修的。

第三个问题：问题可以被稳定复现吗?如果能找到一个操作每次都触发问题，那排查起来就简单多了。比如每次执行某个报表查询的时候，磁盘IO就会飙升。那你就盯着这个操作去分析。如果问题完全是随机的，复现不了，那就要靠监控和日志来收集信息了，可能需要多观察几个发作周期，才能找到规律。

巧用系统状态快照和时间点对比

运行问题最大的难点在于“动态”。很多指标在你登录查看的时候已经恢复正常了，你看不到异常发生时的样子。解决这个问题的一个有效方法，是建立一个“状态快照库”。

我每台云主机上都跑着一个简单的抓取脚本，每五分钟执行一次，把vmstat、iostat、netstat、ps aux、以及关键服务的进程状态和资源占用，全部输出到一份带时间戳的文本文件里。这些文件保存七天。当用户反馈“十分钟前好像卡了一下”的时候，我就可以拿出十分钟前的那份快照，看看当时是什么情况。CPU是不是有个尖峰，磁盘是不是在忙，有没有异常的进程在跑。没有这份历史快照，你就只能“守株待兔”，等下一次发作的时候现场抓，效率低得多。

有一次，一个客户抱怨说每天下午两点半左右，API接口的响应时间会从100毫秒变成2秒。我调出每天两点半的系统快照，发现一个规律：每次响应变慢的同时，都有一个名为“sync”的进程在大量占用磁盘写IO。sync是系统把内存缓冲数据写回磁盘的命令。原来这台云主机的内存里缓存了大量的脏页，达到了某个阈值后，内核会主动触发同步写。调整了vm.dirty_ratio和vm.dirty_background_ratio参数，让脏页更均匀地写回磁盘，不再突然集中爆发，响应时间就平稳了。没有这些历史快照，我可能永远发现不了这个规律。

运行日志分析法

日志是排查运行问题的基本盘。但很多人看日志只看错误级别的，觉得info和debug级别的没用。其实在排查“运行不畅”这类问题时，info级别的日志往往更关键，因为它告诉你程序在每一个关键节点花了多少时间。

我在一个电商系统的订单接口里，加了一条日志，记录从接收请求到返回响应的总耗时，以及每个子步骤(参数校验、库存查询、价格计算、订单写入、消息发送)分别花了多少毫秒。有一次，接口突然变慢，总耗时从200毫秒变成了1.5秒。我去看日志的分步骤耗时，发现“库存查询”这一步从原来的50毫秒变成了1.2秒。而库存查询调用的下游服务，在那段时间的日志里显示有大量的GC停顿。问题一下子就定位到了下游的缓存服务身上。如果没有这些分步骤的耗时日志，我可能要满世界猜到底是谁慢了。

日志分析还有一个技巧是看“增量”。不要只盯着某个时刻的日志，而是看两个相邻时段之间的日志增量。比如正常运行的时候，每分钟产生了多少条某种类型的日志。异常的时候，同类型的日志是不是突然变多了。大量的重试日志、超时日志、连接关闭日志，往往是问题的先兆。一台数据库云主机在“慢”的时候，错误日志里什么都没有，但是普通日志里出现了很多“Aborted connection”的记录，说明客户端频繁断开连接，这提示我可能是连接池配置不合理，或者网络设备在强制关闭空闲连接。

进程级 profiling

有时候日志和系统快照都不足以解释为什么服务变慢了，这时候就需要深入到进程内部去看。Linux提供了很多profiling工具，比如strace、perf、blktrace等。

我曾遇到过一台运行Node.js应用的云主机，吞吐量莫名其妙下降了百分之四十。用top看，CPU使用率不高，内存正常，磁盘闲着，但就是处理请求的速度上不去。我用了strace -p 抓了一下Node进程的系统调用，发现进程大量的时间花在futex系统调用上，这是一种用户态锁的等待操作。原来Node.js是单线程事件循环，按理说不应该出现锁竞争。进一步用perf top采样，发现热点集中在libuv的epoll_wait上。最后定位到是Node.js版本的一个bug，在大量定时器存在的情况下会导致事件循环的唤醒延迟。升级了Node.js的补丁版本之后，吞吐量恢复了正常。如果没有strace和perf，靠看日志是永远看不出这个问题的。

另一个案例，一台PHP-FPM服务器的响应时间从100毫秒涨到了500毫秒。用strace跟踪一个PHP请求的完整处理过程，发现它在执行file_get_contents去读一个远程API的时候，耗了400毫秒。原来那个远程API的响应变慢了。这不是PHP-FPM的问题，而是外部依赖的问题。知道了这一点，我们就可以做两件事：给这个远程调用加缓存，以及设置更短的超时时间避免拖垮整个请求。

模拟和复现

对于那些难以在线上直接抓到的运行问题，有时候最好的方法是在测试环境里模拟相同的条件，然后尝试复现。模拟的手段包括压测工具、流量回放、故障注入等。

曾经有一台云主机，用户反映上传大文件的时候，上传速度会越来越慢，最后卡住。在生产环境不能随便上传大文件测试，因为会影响其他用户。我们在测试环境里用同样的云主机规格，部署了同样的服务，然后用ab和curl模拟并发上传。通过多次测试，发现当上传速度达到某个阈值时，CPU的软中断(si)会急剧升高，占用了百分之五十的CPU。进一步排查，是虚拟网卡的驱动配置里，多队列没有打开，导致所有的网络中断都挤在同一个CPU核心上。在云主机的控制台里开启了网卡多队列，并且在操作系统里配置了中断亲缘性，上传速度就稳定了。

模拟还有一个好处，就是可以安全地尝试各种修复方案，看看哪个有效，哪个无效。比如说，你怀疑是内存不足导致系统变慢，那就在测试环境里限制内存，看能否复现同样的现象。如果能复现，那就证实了你的假设，然后再去考虑是加内存还是优化应用。

分层排查法

云服务器运行问题涉及的层次很多。从硬件虚拟化、到操作系统内核、到系统服务、到中间件、到应用代码，都有可能成为瓶颈。我习惯用分层排查法，每次只聚焦一层，确认这一层没有问题，再进入下一层。

第一层，硬件和虚拟化。在云主机上，你无法直接看到物理硬件，但可以通过云监控查看是否有CPU steal time、磁盘IO毛刺、网络丢包等。如果这一层有问题，通常是云服务商的事情，你需要收集证据，提工单。

第二层，操作系统内核。查看系统整体的CPU、内存、IO、网络占用情况，查看内核日志，检查是否有异常的内核线程占用了大量资源。在这一层，你要确认问题不是因为系统参数设置不当导致的。

第三层，系统服务。比如systemd管理的各种服务、cron任务、监控代理、安全软件等。有时候是这些辅助服务出了问题，影响了主业务。

第四层，应用程序。这是大多数运行问题的最终落脚点。通过应用自身的日志、性能剖析工具、链路追踪等手段，找到代码层面的瓶颈。

每一层都有一套对应的工具和检查清单。我建议把这套清单写下来，排查的时候一条一条过，不要跳跃。因为跳跃往往会让你漏掉某层的线索，然后在错误的方向上浪费大量时间。

从用户角度的“端到端”测试

有时候，从服务器内部看一切正常，但用户就是觉得慢。这时候你需要从用户的角度去感受问题。用一台不在云主机所在网络里的机器，模拟真实用户的访问。

最土但是最有效的方法，就是用curl命令加上-w参数，记录下DNS解析时间、TCP连接时间、TLS握手时间、首字节时间、总传输时间。把这些数据多测几次，看看哪个阶段的耗时不正常。比如DNS解析时间超过100毫秒，可能是DNS服务商的问题，或者本地DNS缓存失效。TCP连接时间长，可能是网络链路绕路，或者服务器端 backlog 队列满了。首字节时间长，通常指向服务器端处理请求的延迟。

有一次，客户抱怨页面加载很慢，我们自己在国内测试觉得还好。但是这位客户在海外。我们用一台海外的云主机做了测试，发现TLS握手时间达到了1.2秒。进一步排查，是服务器端只支持TLS1.2，而客户端的网络路径上有设备在做深度的SSL包检测，导致了额外的延迟。我们升级服务器支持TLS1.3，握手时间降到了200毫秒以内。

多维度数据交叉验证

单一的指标往往有欺骗性。比如CPU使用率低，不代表系统不繁忙，因为可能是IO等待。磁盘使用率低，不代表磁盘性能好，因为可能是大量的随机小IO导致延迟高。所以要把多个维度的数据放在一起看，互相印证。

我有个习惯，每次遇到运行问题，会把监控面板同时打开几个关键的图表：CPU使用率(分成user、system、iowait、steal)、内存使用率和swap、磁盘IOPS和延迟、网络入出带宽和重传率、以及Nginx或者应用层的请求耗时分布。然后我盯着这些图表，看它们之间有没有同步波动。比如，请求耗时升高的同时，磁盘延迟也在升高，那就是IO问题。请求耗时升高的同时，CPU system部分升高，那可能是系统调用太多。请求耗时升高，但是其他指标都平稳，那问题可能在应用内部，比如锁竞争或者GC。

有一次，请求耗时出现规律性的锯齿状波动，每隔三十秒就有一个尖峰。我同时看了CPU、IO、网络都和这个尖峰同步。但奇怪的是，每个指标尖峰的幅度都不大，单独看都不至于引起耗时翻倍。后来我把所有图表叠加在一起，发现这些尖峰虽然单独不大，但是叠加在一起，造成了一种“共振”效应。最后定位到是一个监控脚本每三十秒运行一次，它同时做了一堆事情：读取磁盘、发送网络数据、消耗CPU。优化了这个监控脚本的执行方式，耗时曲线就平了。

排查中的沟通技巧

这一点很少有人提，但我认为非常重要。排查运行问题往往不是你一个人的事，你可能需要和同事、客户、甚至云服务商的技术支持沟通。怎么描述问题，直接影响你获得帮助的效率。

我一个朋友曾经给云厂商提工单，写的是“我的服务器很慢，请帮忙看看”。这种描述没有任何信息量，对方只能回复一些通用的排查步骤。浪费了三天时间，问题没解决。后来我帮他重新组织了一下描述：我们有一台云主机，实例ID是什么，从今天上午十点开始，响应时间从50毫秒上升到300毫秒，期间CPU使用率从20%降到5%，但磁盘await从2ms升到80ms，这个现象在昨天同一时段没有出现，我们自行检查了应用日志没有发现异常，请协助检查云盘后端是否有性能抖动。只过了两个小时，对方就回复说，他们发现该云盘所在的存储集群有负载不均，正在进行优化调整。问题很快解决了。

所以，总结一下和外部沟通的要点：给出具体的实例ID和时间段，附上监控数据截图或者数字，说明你已经做了哪些排查，以及你希望对方帮你查什么。这样既显得专业，也能让对方更快地定位到你的问题。

总结

云服务器运行问题的排查，说到底是一套系统化的方法，而不是灵机一动的猜测。从问自己三个问题开始，明确问题的起点、范围和可复现性。然后利用历史快照和时间点对比，找到异常发生的具体时刻。接着深入日志和进程，用量化的数据来验证假设。如果线上难以排查，就在测试环境里模拟复现。分层排查确保你不会遗漏任何一个层次的线索。从用户角度做端到端测试，避免陷入服务器内部的盲区。多维度数据交叉验证，防止被单一指标误导。最后，别忘了沟通的技巧，让需要协作的人能够快速帮到你。

我想说的是，这些方法不是一次就能掌握全的，但只要你每次排查完后都反思一下：这次用到了哪些方法，下次还有哪些方法可以试试，你就会越来越熟练。云服务器是一个复杂的系统，但复杂系统的运行也是有规律可循的。掌握了正确的排查方法，那些让你头疼的运行问题，最终都会变成你经验库里的一个案例。等到你再遇到类似的问题时，你会微微一笑，然后从容地打开命令行，开始你的表演。