CI失败日志的解读与分析技巧

日志，说白了就是系统给咱们留下的一堆“破案线索”。

很多新手一看到满屏的报错就慌，尤其那红通通的字，感觉天都要塌了。其实不用怕，我做了这么多年CI，总结了两个字——“拆解”。

先看一张图，理解我们分析日志的整体思路。

一、日志分类：先看大方向

打开一个失败的CI构建日志，别急着从头读到尾。先看头部信息。

• 构建阶段：是在编译（build）环节挂的？跑单元测试（test）时报的错？还是部署（deploy）时出了问题？
• 任务编号：比如 Jenkins 的 Build #1234。有这个编号，才能定位到具体那次构建。
• 运行环境：用了哪个分支，JDK版本是多少，Node版本是多少。很多问题换了个环境就没了。

二、关键信号的识别

日志里有些词，我们得一眼认出来。我把它们分成了几类，用表格总结一下：

信号类型	关键词（示例）	通常含义
致命错误	FATAL, BUILD FAILED	流程中断，必须修复
断言失败	AssertionError, assert false	代码或逻辑条件不符合预期
异常崩溃	NullPointerException, Segmentation Fault	运行时错误，内存或空值
超时	Timeout, deadline exceeded	某个步骤跑太久
依赖问题	ModuleNotFoundError, cannot resolve	配置或网络原因导致找不到依赖

三、解读的几项核心技巧

这里我总结了几个实战方法。

1. 消除噪音

日志里有大量的 INFO 和 WARN。很多WARN其实只是提醒，不是故障。比如 WARN: Using deprecated API，它会影响最终结果吗？不一定。先专注看 ERROR 和 FATAL。噪音太多，容易分心。

2. 分析错误堆栈

错误堆栈是我们破案的最强线索。看这段示例：

java.lang.NullPointerException
    at com.example.service.UserService.getUser(UserService.java:25)
    at com.example.controller.UserController.doSomething(UserController.java:12)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

怎么看？

• 第一行：异常类型。这里是空指针。
• 第二行：代码在哪个类的哪一行报的错。这就是我们的目标。别去管那些 NativeMethodAccessorImpl 之类系统框架的调用。

我记得有一次，一个同事盯着堆栈看了半天，非说错误在第三方库里。其实真正出问题的地方就在业务代码那几行。说白了，找到你自己的代码，就是找到问题的根。

3. 连读命令行输出

如果是在CI脚本里执行shell命令，比如测试命令：

npm run test
... (很多输出)
Error: Test "should return user" failed.
AssertionError: expected 1 to equal 2

那我们就知道，是名为 should return user 的测试用例断言失败了，预期值是2，实际得到1。这种错误信息非常直接，按图索骥就能找到对应的测试文件。

四、常见错误模式与应对

我把工作中经常遇到的几种日志模式列出来，再给点建议。

1. 全是红色，找不到具体错误：先检查构建阶段。如果是单元测试阶段，可能是一个测试失败导致构建失败，但日志没有打印失败详情。可以加一个 --verbose 参数重新运行。
2. 依赖下载失败：看日志头部的网络信息。可能是镜像源配置不对，也可能是网络代理没配置。比如Maven项目，检查 settings.xml 里是不是写了公司内部的仓库地址。
3. 莫名其妙的超时：看是不是有死循环或者资源竞争。比如一个API请求没有设置超时时间，一直等。个人习惯是在所有外部调用都设置一个超时值，比如5秒。

五、培养结构化阅读习惯

我建议大家养成一种习惯：抛开内容，先看日志的结构。

• 先确定日志的总体长度——是几百行还是几万行？
• 再看开头部分的运行环境信息。
• 然后跳到最后，看退出码（exit code）。0代表成功，非0就是失败。
• 最后用关键词搜索错误发生点。

这样做的好处是，不会在无关的日志里浪费时间。你想想看，如果一个构建只有500行日志，你可以很快看完。如果是5万行，那你还是一行一行翻，效率就太低了。