云服务器服务中断原因如何排查?

上个季度，我们团队经历了一次让人彻夜难眠的云服务器中断。那是一个周五的晚高峰，用户反馈App无法登录，后台接口响应慢得像蜗牛爬行，监控大屏上一片飘红。整整折腾了四个小时才恢复，事后复盘时我们发现，其实很多排查步骤本可以更高效。今天我就把自己这几年在云服务器故障排查中踩过的坑、攒下的经验，认认真真地梳理出来，希望能帮你少走一些弯路。

先从症状入手，别急着下结论

当你发现服务不可用，第一反应很关键。我见过不少同行一上来就重启服务器，或者直接回滚代码，这样往往治标不治本。正确的做法是先搞清楚“中断”到底是什么样的表现。是页面完全打不开，还是加载特别慢是部分用户受影响，还是所有人都不行是API报错500，还是数据库连接超时

把这些现象记录下来，它们会像侦探小说里的线索一样，指引你找到真正的病因。比如有一次，客户说网站打不开了，我远程一看，首页能加载但图片全碎了，这就明显不是服务器宕机，而是对象存储或者CDN出了问题。如果你不分青红皂白去重启Web服务，那纯粹是浪费时间。

网络链路：最容易被忽视的盲区

云服务器本质上还是一台联网的计算机，只是托管在数据中心里。网络问题导致的中断占比相当高，而且往往伪装成其他故障的样子。

先从最基本的连通性开始检查。用ping命令看看服务器IP能不能通，注意这里的“通”不只是看有没有返回，还要观察丢包率和延迟波动。有一次深夜接到报警，说服务器完全失联，我ping了一下发现延迟从平时的30毫秒飙升到300多毫秒，而且时不时超时。后来查了一圈，是云服务商的一个上游交换机在割接，路由绕了大半个中国。

如果ping正常但服务访问不了，那就需要检查端口了。用telnet或者nc命令去探测特定端口，比如80或443。我习惯随身带着一张常用端口表，因为不同的端口状态能告诉你很多信息。如果22端口能通但80端口不通，那十有八九是Web进程挂了或者防火墙策略变了。这里说个真实的教训，某次我们部署完新版本，忘记把安全组里的8080端口放行，结果监控显示服务端口正常监听，但外面就是访问不到，排查了两小时才发现是云控制台的一个入站规则被误删了。

服务器自身的资源瓶颈

排除网络因素后，就该登录服务器看它自己的状态了。很多时候服务中断不是真的“断”，而是慢到了不可用的程度，根本原因是资源耗尽。

CPU和内存是最直观的指标。用top或者htop命令看一眼，如果CPU使用率长时间100%，那说明计算能力不够用了。但要注意区分是正常业务导致的高负载，还是挖矿病毒或者死循环在作祟。我曾经遇到一个案例，某台服务器的CPU从凌晨两点突然飙到满载，我们一看进程列表，发现一个陌生名字的可执行文件在跑，明显是被入侵植入了挖矿程序。及时杀掉进程、清理定时任务、修补漏洞，这才解决问题。

内存泄漏也是个隐形的杀手。很多Java或者Node.js应用跑着跑着内存占用越来越高，直到OOM Killer被触发，把主进程给干掉了。你可以通过free -h查看内存使用情况，再用dmesg或者查看/var/log/messages里的Out of memory日志来确认是否发生了内存溢出。有一次我们一个微服务每隔三天就会半夜挂掉，查了整整一周才发现是某个分页查询接口没有加limit，一次拉取了几百万条数据到内存里，不崩才怪。

磁盘空间耗尽可能比你想的更常见。我遇到过两次非常尴尬的中断，一次是日志文件把根分区写满了，导致Web服务无法写入临时文件，页面直接白屏。另一次是数据库的binlog积累了几百GB，MySQL直接拒绝写入，所有更新操作全部失败。定期清理日志、配置日志轮转、对关键目录做容量监控，这些看似基础的运维习惯关键时刻能救命。我现在的做法是给每个挂载点设置85%的告警阈值，留出充足的反应时间。

应用层和配置问题

如果服务器本身资源充裕，网络也通畅，那问题大概率出在应用层或者配置文件上。

看一眼你的应用进程还在不在。用ps或者systemctl status检查一下服务状态。有时候进程会悄无声息地退出，原因可能是代码里的未捕获异常、依赖的第三方服务超时、或者是操作系统发出的SIGKILL信号。查看应用自身的错误日志是最直接的，但问题在于很多人没有给日志分级别，错误、警告、信息全混在一起。我建议至少把ERROR级别的日志单独输出到一个文件，这样排查时先看这个，能节省大量时间。

配置文件被改过也是常见的故障源。有一次我们一个合作伙伴说API突然返回401认证失败，我们查了半天，最后发现他们运维人员在服务器上调试时手动修改了Nginx的配置文件，把Authorization头的转发给禁掉了。这种人为操作很难防范，最好的办法是用配置管理工具，比如Ansible或者SaltStack，把所有的配置变更都走版本控制，谁在什么时候改了什么一目了然。

还有一个容易被忽略的点是时钟同步。云服务器的系统时间如果漂移太厉害，会导致HTTPS证书验证失败、JWT令牌失效、分布式系统里的顺序错乱。我就碰到过一次，两台服务器时间差了五分钟，结果消息队列里的任务总是被重复消费，因为时间戳比较的逻辑出了问题。装好ntp或者chrony，确保时间同步服务正常运行，这个小细节比你想的重要得多。

依赖服务的雪崩效应

现代的云应用很少是孤立的，背后往往依赖数据库、缓存、消息队列、对象存储等一系列服务。有时候你自己的服务器一切正常，但只要其中一个依赖出问题，整个链就断了。

数据库慢查询是典型例子。我经历过一次，某电商大促当天，订单查询接口突然全部超时。登录到业务服务器看，CPU和内存都正常，网络延迟也低，但一看数据库服务器的监控，发现有个SQL语句扫描了几百万行，把数据库的IO打满了。那个查询原本走了索引，但因为某个运营人员在前端加了一个模糊匹配的筛选条件，导致索引失效。从那以后，我们在代码审查阶段就把所有SQL的执行计划都过一遍，并且在数据库层面强制设置查询超时时间。

缓存击穿也很常见。假如你的服务依赖Redis做热点数据缓存，一旦Redis宕机或者大量key同时过期，所有请求会瞬间涌向后端数据库，数据库扛不住就会拒绝连接，进而导致整个应用不可用。我和团队处理过一起这样的故障：一个活动的开始时间设置错误，导致原本分散在24小时的缓存key在同一秒全部过期，数据库连接池瞬间被打满，服务瘫痪了二十分钟。解决方案包括给缓存设置随机过期时间、使用互斥锁来防止缓存重建时的并发冲击、以及做多级缓存架构。

另外，第三方API不可用也会造成服务中断。之前有个项目对接了某支付网关，对方服务不稳定，时不时超时。我们的代码里没有设置合理的超时和重试策略，结果支付接口的线程全部阻塞在那里，把整个容器的线程池耗光了，连健康检查的请求都进不来。所以调用任何外部依赖，必须要配置连接超时、读取超时，并且用熔断器模式来保护自己的服务。

云平台自身的问题

这个点很多人不愿意面对，但确实存在。云服务商也不是100%可靠的，他们会有故障，比如某个可用区的电力系统异常、存储集群出现性能抖动、控制平面API限流等等。

我遇到过两次明显的云平台问题。一次是某云厂商的对象存储突发了长达四十分钟的延迟升高，所有上传下载操作都变得极慢。我们自己的服务器没有任何异常，但用户的图片就是传不上去。那时候还没有做跨云备份，只能干等云厂商修复。另一次是某地域的负载均衡集群升级，导致我们的几个实例被错误地标记为不健康，流量切走后又把剩下的实例也压垮了。事后云厂商发了事故报告，承认了他们的健康检查逻辑存在缺陷。

怎么判断是云平台的问题很简单，查看云控制台的健康状态页面，很多厂商都有专门的status页面。同时看看同一可用区里其他服务的表现，如果你的数据库、缓存、消息队列同时出问题，那基本可以肯定是底层基础设施层面的故障。这时候能做的不多，除了等云厂商修复，最好的办法就是提前规划高可用架构，做跨可用区甚至跨云的容灾。

一个完整的排查案例复盘

讲一个印象最深的案例，能把这些要点串起来。

今年三月份，我们一个金融客户的交易系统在下午两点十五分发生服务中断，持续了大概五十分钟。当时的现象是：交易接口的响应时间从平均200毫秒飙升到了超过三十秒，接着开始大量返回503错误，监控显示用户主动取消请求的比例达到了百分之七十。

我们的排查过程如下。第一分钟，确认不是全量故障，内部测试环境能访问，但生产环境不行，说明问题在生产服务器上。第三分钟，ping服务器延迟正常，没有丢包，排除基础网络问题。第五分钟，登录到服务器，用top看到CPU使用率只有百分之三十，内存空闲也很多，但负载平均值却高达十五，明显是IO等待过高。第八分钟，用iostat命令查看磁盘，发现每秒写入量达到了正常值的八十倍，磁盘队列深度爆满。第十分钟，通过lsof -i查看到底是哪个进程在疯狂写磁盘，结果发现是数据库实例在产生大量临时文件。第十三分钟，登陆数据库，执行show processlist命令，看到有十几个相同的查询在执行，这个查询涉及一个没有索引的大表做全表扫描和文件排序。第十五分钟，联系开发团队确认，原来是业务方临时上线了一个报表功能，里面的SQL没经过审核。第十分钟，我们决定先杀掉那些慢查询，然后用一条命令创建缺失的索引。第二十分钟，数据库负载降下来，服务逐步恢复。但这时候发现还有百分之十的请求依然超时，进一步排查才发现，之前的大量超时请求导致应用服务器的连接池里积累了非常多半死不活的连接，需要重启应用才能完全恢复。第五十分钟，全部恢复正常。

事后我们做了几件事：第一，所有新上线的SQL必须经过DBA审核并附带执行计划分析报告。第二，数据库配置了慢查询阈值两秒，并设置了自动kill超过三十秒的查询。第三，应用连接池增加了空闲连接检查和回收的机制。第四，在监控系统里增加了磁盘IO和数据库临时文件使用情况的告警。

养成良好的排查习惯

说了这么多案例和方法，我觉得最重要的其实不是具体的技术细节，而是排查问题的心态和习惯。遇到服务中断，人很容易慌，一慌就容易乱操作。我现在每次遇到故障都会先给自己倒杯水，坐下来按照一个固定的清单来排查。

这个清单大致是这样的：先看监控告警的详细内容，再确认影响范围，然后检查网络连通性，接着看服务器基础资源，之后查看应用日志和进程状态，同时确认依赖服务是否健康，最后才考虑回滚或者扩容这类大动作。每一步的结论都要记录下来，哪怕只是“ping正常”这样的信息，因为有时候最不起眼的线索反而最关键。

另外，不要一个人死磕。团队协作时，一个人负责在控制台和命令行里找线索，另一个人去翻最近的操作变更记录和发布日志，第三人去跟业务方沟通确认故障现象，这样并行推进，效率会高很多。我们有次花了十分钟就定位到一个问题，就是因为三个人分工明确，其中负责查变更记录的那位同事发现数据库连接串在半小时前被人改过，一核对，是配置中心推送了一个错误的值。

总结

云服务器服务中断的原因千奇百怪，但归纳起来无非就几个层面：网络链路的不稳定、服务器自身资源耗尽、应用代码或配置缺陷、依赖服务的雪崩效应，以及云平台底层基础设施的故障。排查的过程本质上就是一个不断缩小范围、排除不可能项的过程。

没有谁能保证自己的服务器永远不中断，但你可以保证的是，当中断发生时，你有一套清晰的排查思路，你手里有完备的监控和日志，你的团队有明确的分工和预案。每一次中断都是一次学习的机会，把故障发生的原因、排查的路径、修复的措施老老实实地写成复盘报告，把这些经验沉淀到你的知识库里，下次再遇到类似的问题，你就能更快地找到答案。