3. 常见故障类型：网络超时、服务宕机、数据不一致、资源耗尽

做流程自动化这些年，我见过最多的故障，翻来覆去就是这四类。说白了，你把这四个“老冤家”摸透了，排查效率至少提升一半。今天咱们就一个一个掰开揉碎了聊。

3.1 网络超时：最隐蔽的“软故障”

网络超时这玩意儿，特别烦人。它不是每次都挂，而是“偶尔抽风”。你盯着它的时候它好好的，你一转身它就报错。

典型表现：

• 流程卡在“等待响应”状态，最后超时退出
• 日志里出现 Connection timed out 或 Read timed out
• 重试几次可能又成功了

我个人的排查习惯：

先看超时时间设置。很多开发同学喜欢用默认值，比如 HTTP 请求默认 30 秒。但自动化流程里，如果下游系统响应慢，30 秒根本不够用。我曾经遇到一个 ERP 接口，生成报表平均要 40 秒，默认超时直接导致流程失败率 80%。

避坑指南：

我曾经踩过一个坑——只配了连接超时，没配读取超时。结果连接建立得很快，但数据一直没传完，流程就卡在那不动了。记住，connectTimeout 和 readTimeout 是两个东西，都得配。

3.2 服务宕机：最直接的“硬故障”

服务宕机，说白了就是“挂了”。你发请求过去，直接返回 502、503，或者干脆连不上。

常见原因：

• 内存泄漏导致 OOM（Out Of Memory）
• 代码异常导致进程崩溃
• 依赖的中间件（如 Redis、MySQL）挂了

我的处理三板斧：

1. 先看监控： 有没有告警？CPU、内存、磁盘 IO 有没有异常？
2. 再看日志： 崩溃前的最后几行日志，往往藏着真相。
3. 最后看代码： 如果是新上线的版本，大概率是代码问题。

自动化流程里的应对：

我建议在流程里加一个“健康检查”步骤。每次调用服务前，先发一个轻量级的 ping 请求。如果 ping 不通，直接走降级逻辑，而不是傻等超时。

3.3 数据不一致：最头疼的“逻辑故障”

数据不一致，是自动化流程里最隐蔽、最难排查的故障。流程跑完了，没报错，但结果不对。你想想看，这多可怕？

典型场景：

• 订单状态在 A 系统是“已支付”，在 B 系统是“待支付”
• 库存扣减了，但订单没生成
• 数据同步延迟，导致两边对不上

为什么会这样？

说白了，就是分布式事务没做好。自动化流程往往涉及多个系统，每个系统都有自己的数据库。如果中间某个步骤失败了，又没有回滚机制，数据就“岔劈”了。

我的排查方法：

1. 找“锚点”： 找一个双方都有的唯一标识（比如订单号），对比两边的数据。
2. 看时间戳： 数据不一致，很多时候是时序问题。谁先写、谁后写，顺序错了就会乱。
3. 查补偿机制： 有没有对账脚本？有没有定时修复任务？

3.4 资源耗尽：最容易被忽视的“慢性病”

资源耗尽，包括 CPU 100%、内存爆满、磁盘写满。这几种故障有个共同特点——它不是突然发生的，而是慢慢“熬”出来的。

CPU 耗尽：

• 现象：流程执行变慢，响应时间越来越长
• 原因：死循环、大量计算、频繁的 GC（垃圾回收）
• 排查：top 命令看哪个进程吃 CPU，再用 jstack 看线程栈

内存耗尽：

• 现象：OOM 错误，进程被系统杀掉
• 原因：内存泄漏、加载了太大的数据（比如一次性查了 100 万条记录）
• 排查：用 jmap 导出堆转储，用 MAT 分析

磁盘写满：

• 现象：写文件失败、数据库报“磁盘空间不足”
• 原因：日志没清理、临时文件堆积、数据库 binlog 太大
• 排查：df -h 看磁盘使用率，du -sh * 找大文件

避坑指南：

我曾经遇到一个案例——磁盘没满，但 inode 用完了。Linux 系统里，每个文件都要占用一个 inode。如果小文件太多（比如日志碎片），inode 会先于磁盘空间耗尽。那时候 df -h 显示还有 50% 空间，但就是写不了文件。所以，排查磁盘问题时，记得用 df -i 看看 inode 使用情况。

3.5 四种故障的对比总结

故障类型	典型特征	排查优先级	自动化应对策略
网络超时	偶发、重试可恢复	中	设置合理超时、重试机制、熔断
服务宕机	完全不可用、报错明确	高	健康检查、自动重启、降级
数据不一致	无报错、结果不对	最高	幂等设计、对账脚本、补偿机制
资源耗尽	逐渐变慢、最终崩溃	高	资源预检、监控告警、自动清理

嗯，这四种故障，基本覆盖了自动化流程里 90% 的线上问题。你想想看，是不是每次出故障，都能归到其中一类？下一章，咱们聊聊具体的排查工具和命令，到时候拿真实案例来练手。