3. GitLab CI 流水线核心组件：Job、Stage、Pipeline 的结构与生命周期

在构建 SLI 采集体系之前，必须精确理解 GitLab CI 的三个核心抽象：Job（作业）、Stage（阶段）和 Pipeline（流水线）。这三者构成了流水线的执行骨架，也是 SLI 指标采集的锚点。只有厘清它们的结构关系与生命周期状态，才能设计出高精度的故障排查与告警降噪规则。

3.1 三层组件结构

GitLab CI 采用严格的层级嵌套结构：Pipeline 包含多个 Stage，Stage 包含多个 Job。每个 Job 是实际执行的最小单元，Stage 控制并行与串行顺序，Pipeline 代表一次完整的集成流程。

3.2 Job 生命周期与状态机

Job 是 SLI 指标的最小采集单元。一个 Job 从创建到结束经历严格的状态转换，每个状态都对应可观测的指标点。

# 典型 Job 定义示例
job_build:
  stage: build
  script:
    - echo "Compiling..."
    - make build
  artifacts:
    paths:
      - dist/
  retry: 2
  timeout: 30 minutes

3.3 Stage 执行模型与依赖关系

Stage 定义了 Job 之间的执行顺序和并行边界。默认情况下，同一 Stage 内的 Job 并行执行，不同 Stage 按 stages 列表顺序串行执行。这种模型直接影响 SLI 中的“阶段阻塞时间”和“关键路径”计算。

# 阶段定义示例
stages:
  - build
  - test
  - deploy

# 依赖控制：test 阶段需要 build 阶段的 artifacts
test_job:
  stage: test
  needs: ["build_job"]
  script:
    - npm test

3.4 Pipeline 生命周期与触发类型

Pipeline 的生命周期从触发事件开始，到所有 Stage 执行完毕或中断结束。不同的触发类型对应不同的 SLI 基线，必须分开统计。

3.5 生命周期状态转换与 SLI 采集点

完整的 Pipeline 生命周期包含以下状态转换，每个转换点都是 SLI 采集的黄金位置：

1. created → pending：Pipeline 被创建，等待 Runner 资源。采集：创建时间、排队时长。
2. pending → running：第一个 Job 开始执行。采集：排队延迟、Runner 分配耗时。
3. running → passed/failed：所有 Stage 执行完毕。采集：各阶段耗时、失败 Job 分布。
4. running → canceled：手动取消或级联取消。采集：取消原因、已执行 Job 比例。

3.6 组件关系对 SLI 采集的影响

理解三层组件的结构关系后，可以总结出以下 SLI 采集原则：