2. CI/CD 基础回顾：持续集成、持续交付、持续部署的核心概念与典型流水线阶段
在深入 Prometheus 告警与 Runbook 联动之前，必须统一团队对 CI/CD 核心术语与流水线阶段的理解。本章从概念辨析、阶段拆解到典型架构图，为后续告警接入奠定基础。
2.1 三大核心概念辨析
持续集成（CI）、持续交付（CD）与持续部署（CD）常被混用，但它们在自动化深度与人工介入节点上存在本质区别。
| 概念 | 英文 | 核心目标 | 人工介入点 | 典型触发条件 |
|---|---|---|---|---|
| 持续集成 | Continuous Integration | 频繁合并代码并自动构建+测试，尽早发现集成问题 | 代码合并后自动触发，无需人工 | Push / Merge Request |
| 持续交付 | Continuous Delivery | CI 通过后自动部署到类生产环境，但发布到生产需人工审批 | 生产环境部署前需人工确认 | CI 通过 + 审批按钮 |
| 持续部署 | Continuous Deployment | CI 通过后全自动部署到生产环境，零人工干预 | 无人工介入 | CI 通过 + 自动化门禁 |
实践建议： 大多数企业从“持续集成 + 持续交付”起步，保留生产发布的人工审批环节以控制风险。只有测试覆盖率 > 80%、灰度机制完善、回滚能力成熟的团队才建议尝试全自动持续部署。
2.2 典型流水线阶段划分
一条完整的 CI/CD 流水线通常包含以下 6 个标准阶段。每个阶段都可能成为告警接入点。
- 代码检出（Checkout） — 从 Git 仓库拉取指定分支/标签的源代码。
- 静态分析与单元测试（Static Analysis & Unit Test） — 执行 lint、SonarQube 扫描、单元测试并生成覆盖率报告。
- 构建与制品打包（Build & Package） — 编译代码，生成 Docker 镜像、JAR 包或二进制文件，并推送至制品仓库。
- 环境部署（Deploy to Environment） — 依次部署到 Dev / Test / Staging 环境，执行冒烟测试。
- 集成与端到端测试（Integration & E2E Test） — 运行 API 测试、UI 自动化测试、性能基准测试。
- 生产发布（Production Release） — 灰度发布 / 蓝绿部署 / 金丝雀发布，并持续观察业务指标。
告警关注点： 阶段 2（测试失败）、阶段 3（构建超时/制品推送失败）、阶段 5（E2E 失败）、阶段 6（发布后错误率飙升）是 Prometheus 告警与 Runbook 联动的重点场景。
2.3 CI/CD 流水线阶段架构图
下图展示了一条标准流水线的阶段流转与制品传递关系。每个阶段框内标注了该阶段的关键产出物。
2.4 流水线阶段与告警场景映射
将每个阶段可能出现的失败模式与 Prometheus 告警指标对应，是 Runbook 设计的前置工作。
| 流水线阶段 | 典型失败模式 | Prometheus 指标示例 | 告警严重度 |
|---|---|---|---|
| 代码检出 | Git 仓库不可达、分支不存在 | pipeline_checkout_duration_seconds |
warning |
| 静态分析 + UT | 单元测试失败率 > 5%、覆盖率低于阈值 | pipeline_test_failure_ratio |
critical |
| 构建 & 打包 | 编译错误、镜像推送超时 | pipeline_build_duration_seconds |
critical |
| 环境部署 | 部署脚本异常、健康检查失败 | pipeline_deploy_failure_total |
critical |
| 集成 & E2E | API 错误率 > 1%、性能下降 > 20% | pipeline_e2e_error_rate |
critical |
| 生产发布 | 错误率飙升、延迟增加、回滚触发 | http_request_duration_seconds{quantile="0.99"} |
page |
避坑提醒： 不要试图为每个阶段的所有失败模式都创建告警规则。优先覆盖“阻断性失败”（如编译错误、E2E 失败）和“发布后业务指标恶化”。告警过多会导致告警疲劳，Runbook 也会变得臃肿难以维护。
2.5 流水线制品与元数据传递
CI/CD 流水线不仅是阶段的串联，更是制品与元数据的传递管道。理解数据流有助于设计告警标签（Labels）的继承策略。
- 制品： Docker 镜像（含 tag）、JAR 包、Helm Chart 包、配置文件。
- 元数据： 构建 ID（Build ID）、Git Commit SHA、分支名、触发者、时间戳、测试报告 URL。
- 告警标签继承： 当流水线失败时，Prometheus Alert 应携带
build_id、branch、stage等标签，便于 Runbook 快速定位日志与制品。
最佳实践： 在流水线每个阶段结束时，将关键元数据以 Prometheus Counter / Histogram 的形式暴露。例如：
pipeline_stage_duration_seconds{stage="build", status="success"}。这样告警规则可以直接基于这些指标触发，无需额外解析日志。