云上常见故障模式与快速恢复手册：照着做，别慌
凌晨三点，手机又响了。告警说“订单服务不可用”。你迷迷糊糊打开电脑，看着一堆监控图表，脑子里一片空白。从哪里开始查？先看日志还是先看CPU？要不要重启？
这是每个运维都经历过的场景：故障来了，人先慌了。
如果有一本手册，照着做就能恢复，是不是就不用慌了？
今天整理一份云上常见故障模式与快速恢复手册。不是理论分析，是照着做的步骤。遇到故障，打开对应的章节，按顺序执行。
01 故障一：服务假死（进程在，但请求不响应）
现象：健康检查失败或超时，监控显示服务不响应请求，但进程还在。
快速判定：
尝试访问服务（curl或浏览器），无响应或超时
登录服务器，
ps aux | grep java进程存在curl localhost:端口/health无响应
恢复步骤：
立即重启服务（K8s环境会自动重启，检查livenessProbe）
如果重启无效，查看日志是否有死锁或线程池满
摘掉该节点流量，让其他节点承接
验证：健康检查恢复，请求正常响应。
后续排查：分析线程堆栈（jstack），定位死锁或卡住的代码。
02 故障二：数据库连接池爆满
现象：应用日志报“Timeout waiting for connection”，接口响应变慢或超时。
快速判定：
查看连接池监控，活跃连接数接近最大值
查看数据库连接数，是否接近上限
恢复步骤：
临时调大连接池上限（如从20调到50，治标）
重启应用释放僵死连接
如果数据库连接数打满，临时调大
max_connections
验证：应用恢复正常，连接池活跃数下降。
后续排查：检查是否有连接泄漏（未关闭连接），检查慢查询是否持有连接过久。
03 故障三：CPU持续飙高
现象：监控显示CPU使用率持续>80%，接口响应变慢。
快速判定：
top查看哪个进程CPU高如果是Java应用，用
top -H -p <pid>看哪个线程
恢复步骤：
如果是正常业务增长，扩容
如果是异常（死循环、大量计算），重启服务
紧急情况：临时降低日志级别，减少日志打印开销
验证：CPU使用率下降，接口响应恢复正常。
后续排查：火焰图分析热点代码，定位CPU消耗在哪。
04 故障四：磁盘写满
现象：监控磁盘使用率>90%，服务可能因无法写日志而异常。
快速判定：df -h 查看磁盘使用率。
恢复步骤：
du -sh /* | sort -rh | head -10找出大目录清理日志：
find /var/log -type f -mtime +7 -delete（删除7天前日志）清理临时文件：
/tmp、/var/tmp扩容磁盘（云上可在线扩容）
验证：磁盘使用率下降，服务恢复。
后续排查：检查日志轮转策略，是否日志写太快；检查是否有core dump文件。
05 故障五：内存泄漏
现象：服务运行一段时间后变慢，重启后恢复，过段时间又慢。
快速判定：
监控内存使用率持续上升，不回落
重启后内存恢复正常，但逐步上涨
恢复步骤：
重启服务（立即恢复，治标）
配置自动重启（K8s livenessProbe）
如果无法自动重启，增加内存上限临时顶住
验证：重启后内存回落，服务恢复。
后续排查：分析堆转储（heap dump），找出泄漏的对象。
06 故障六：依赖下游超时
现象：接口响应变慢，调用链显示下游服务耗时长。
快速判定：
查看调用链，定位耗时在下游
直接调用下游服务，确认是否慢
恢复步骤：
临时调小超时时间，让调用快速失败
开启熔断，直接走降级逻辑（返回缓存或默认值）
联系下游团队
验证：接口响应时间恢复正常（虽然可能返回降级数据）。
后续排查：下游容量不足？网络问题？下游代码bug？
07 故障七：死锁
现象：服务无响应，但不报错，线程卡住。
快速判定：
多次打印线程堆栈（
jstack），看到多个线程等待同一把锁日志无ERROR，但请求无返回
恢复步骤：
重启服务（唯一快速解法）
如果无法重启，尝试kill阻塞线程（不推荐，可能状态不一致）
验证：重启后服务恢复正常。
后续排查：分析代码锁顺序，避免循环等待。
写在最后
故障不可怕，可怕的是不知道怎么办。
这份手册，建议打印出来或存成书签。下次遇到故障，别慌，找到对应章节，照着步骤做。先恢复，再复盘。
那家客户的运维负责人把这份手册放到了团队Wiki首页，每次故障后更新。他说：“以前故障来了各凭经验，现在照着做，新人也能恢复。”
你的故障手册，写了吗？
