分类： 故障排查

近期处理了一起极其荒谬且破坏力极强的 P0 级生产事故。核心业务团队在做 Monorepo（单体代码仓库）微服务大版本发布时，15 个微服务通过 Jenkins Pipeline parallel 并发构建部署，结果上线后核心链路全面崩溃，Nginx Ingress 瞬间爆出海量 502。

排查发现，根本不是 K8s 调度问题或 Harbor 镜像源拉取故障，而是 订单服务（Order）的 Pod 里，居然跑着用户服务（User）的镜像。最终定位的罪魁祸首：Jenkins Shared Library（共享库）中滥用了脚本级全局变量，在 parallel 并发执行下触发了典型的线程安全问题，导致变量相互覆盖（串量）。

一句话结论：在 Jenkins vars/ 共享库脚本中定义方法外部的全局变量，其实例在同一个 Pipeline 运行期的 parallel 阶段是完全共享的。并发读写这些变量必然导致数据污染。修复方案：必须将所有状态变量严格限定在 call() 方法内部，强制实现共享库的无状态化。

事故现场与离谱的报错

排查过程中，我们查看了 K8s 集群的实时状况。订单服务（Order）的 Pod 陷入了 CrashLoopBackOff：

$ kubectl logs order-deployment-5f6b9c9d-8x2a -n prod-ns
Error: Invalid or missing Spring Boot configuration. 
Application 'user-service' failed to start.

日志显示这个 Pod 内部启动的居然是 user-service。去检视 Jenkins 构建日志，发现了令人窒息的一幕：

[Pipeline] // 并行分支: build-order-service
[Pipeline] sh (docker build)
+ docker build -t harbor.corp.com/prod/order-service:v1.2.3-45 .
...
[Pipeline] // 并行分支: build-user-service
[Pipeline] sh (docker build)
+ docker build -t harbor.corp.com/prod/user-service:v1.2.3-45 .
...
[Pipeline] sh (helm upgrade) # 此时 order 分支的 helm 部署命令
+ helm upgrade order-service ./chart --set image=harbor.corp.com/prod/user-service:v1.2.3-45

注意看最后一行，order-service 的分支在执行 Helm 部署时，注入的 Image 参数竟然变成了 user-service 的镜像！

原理剖析：全局变量是万恶之源

去翻看负责 CI/CD 脚本的开发人员写的 Jenkins Shared Library 代码，简直触目惊心：

// 错误代码示例：vars/standardBuilder.groovy
def currentImage = ""       // 【致命错误】脚本级全局变量
def deployYaml = ""         // 【致命错误】脚本级全局变量

def call(Map config) {
    currentImage = "${config.imageName}:${config.tag}"
    deployYaml = "${config.appName}-deployment.yaml"

    // 模拟耗时构建操作
    sh "docker build -t ${currentImage} ."
    sh "docker push ${currentImage}"

    // 部署阶段
    sh "helm upgrade ${config.appName} ./chart --set image=${currentImage}"
}

而在他们的 Jenkinsfile 中，调用方式是这样的：

parallel(
    'order': { standardBuilder(appName: 'order', imageName: 'order-service', tag: 'v1.2') },
    'user':  { standardBuilder(appName: 'user',  imageName: 'user-service',  tag: 'v1.2') }
)

为什么这绝对不可原谅？

很多刚接触 Jenkins Pipeline 的人把它当成简单的 Bash 脚本写，缺乏基本的“防御性编程”思维。在 Jenkins CPS（Continuation Passing Style）引擎的底层实现中，vars/standardBuilder.groovy 并不是每次调用都重新实例化的纯函数。 整个文件在编译后会成为继承自 CpsScript 的一个类。在同一个 Pipeline Run 中，vars/ 下的单例对象是被缓存的，文件顶层的 def currentImage 变成了这个单例对象的一个实例属性（Field）。

当 parallel 启动多个分支（在 Jenkins 中是底层的绿色线程 Green Threads）并发调用 standardBuilder() 时，执行时序就变成了：

1. 分支 A (Order)：写入 currentImage = "order-service:v1.2"

2. 分支 B (User)：写入 currentImage = "user-service:v1.2" （此时实例属性被覆盖）

3. 分支 A (Order)：执行完 docker push，准备执行 helm upgrade，读取 currentImage，读到了 "user-service:v1.2"。

这不仅导致了严重的生产环境发版错乱，如果是带有危险操作（如 DB 变更脚本）的流水线，这种串量能直接把数据库干废。

进阶踩坑：CPS 序列化风暴与 OOM

除了上述的并发污染问题，在脚本级定义变量还会引发另一个经典灾难：NotSerializableException 报错与 Jenkins Master 内存泄漏。

如果有人在这个全局作用域放了一些非序列化对象（比如 JSON 解析结果、HTTP Client 实例）：

import groovy.json.JsonSlurper

def parsedConfig = null // 脚本级变量

def call() {
    def slurper = new JsonSlurper() // JsonSlurper 返回的是非序列化的 LazyMap
    parsedConfig = slurper.parseText(readFile('config.json'))
    sh "echo 'Building...'"
}

Jenkins 的 CPS 引擎为了保证在 Master 节点重启后能够恢复 Pipeline 的执行状态，会在遇到每一个 Pipeline Steps（如 sh, echo, sleep）时，暂停当前线程，并将整个 CpsScript 对象及其绑定的变量树完整序列化并落盘（存储到 build.xml 中）。 如果 parsedConfig 是一个不可序列化的对象，流水线会当场 Crash。如果是一个体积庞大的 Map，并发数一高，每次执行 sh 都要把几 MB 的数据做深拷贝和 XML 序列化，会导致 Jenkins Master 的 CPU 瞬间打满，触发频繁的 GC 停顿甚至 OOM（OutOfMemoryError）。

最佳实践与防御性加固

对于重度依赖 Jenkins 驱动核心 CI/CD 的团队，必须在架构层面掐断这种低级失误。

1. 强制无状态化共享库（Pure Functions）

所有共享库 vars/ 下的方法，必须是纯函数，严禁在 call() 之外定义任何非 final 变量。 修正后的代码：

// 正确代码：vars/standardBuilder.groovy
def call(Map config) {
    // 变量作用域严格限制在方法内部（闭包内本地变量），每次调用独立分配栈空间
    def currentImage = "${config.imageName}:${config.tag}"
    def deployYaml = "${config.appName}-deployment.yaml"

    sh "docker build -t ${currentImage} ."
    sh "docker push ${currentImage}"
    sh "helm upgrade ${config.appName} ./chart --set image=${currentImage}"
}

2. IO 操作与数据解析严格剥离（@NonCPS）

如果必须进行复杂的 JSON 解析或遍历操作，必须封装为独立的函数并打上 @NonCPS 注解，确保这部分逻辑由 JVM 原生线程直接执行，不参与 CPS 的序列化。 注意： @NonCPS 方法内部绝对不能调用任何 Jenkins Pipeline 原生步骤（如 sh, readFile）。

@NonCPS
def parseMyConfig(String jsonStr) {
    // 纯 Groovy/Java 原生执行，无需考虑序列化问题
    return new groovy.json.JsonSlurperClassic().parseText(jsonStr) 
}

def call() {
    def jsonContent = readFile('config.json')
    def configMap = parseMyConfig(jsonContent)
    // 继续后续流程...
}

3. K8s Dynamic Agent 的工作空间硬隔离

除了内存里的变量，物理层面的 Workspace 同样容易发生并发冲突。在 parallel 执行阶段，尽量确保每个并行任务申请独立的 K8s Pod (Agent)，或者显式使用 dir 指令分配子目录，避免同一节点上的 I/O 踩踏：

parallel(
    'order': { 
        node('k8s-agent') { // 分配独立的 Pod
            checkout scm
            standardBuilder(...)
        }
    }
)

同类问题速查（排查清单）

1. Pipeline 并行分支行为异常/串数据：立刻检查 vars/ 目录下的共享库文件，全局搜索是否存在未被包含在方法内的 def、String、Map、List 定义，或误用了 @Field。

2. 构建日志报 java.io.NotSerializableException：检查脚本中是否将 Matcher（正则匹配对象）、JsonSlurper 返回结果、Connection 等非序列化对象保留在了方法外层，或跨越了 sh/echo 等 Pipeline Step 的边界。

3. Jenkins Master CPU 极高或 Full GC 频发：检查 Jenkins 系统管理中的线程转储（Thread Dump），搜索 CpsThread 和 xstream 相关的堆栈，大概率是 Pipeline 定义了超大数组/Map并在执行 Steps 时引发了海量序列化开销。

4. 并发构建文件损坏/拉错代码：检查 parallel 代码块，是否多个并发逻辑复用了同一个 node 并且没有使用 dir('sub-dir') 隔离 Workspace。