3. CI/CD流水线架构概述
在深入 OpenTelemetry 监控之前，必须清晰理解 CI/CD 流水线的核心架构。本章将拆解典型 CI/CD 流程的四个阶段，分析自助流水线的关键特征，并明确可观测性在其中的具体需求。
3.1 典型 CI/CD 流程：代码提交 → 构建 → 测试 → 部署
一个标准的 CI/CD 流水线通常包含四个核心阶段，每个阶段都有明确的输入、输出和检查点。下表总结了各阶段的关键活动与产出物：
| 阶段 | 触发条件 | 核心活动 | 关键产出物 | 常见失败原因 |
|---|---|---|---|---|
| 代码提交 | 开发者推送代码至远程仓库 | 代码审查、静态分析、合规检查 | 代码变更集、Commit SHA | 代码风格违规、安全漏洞 |
| 构建 | 代码合并或标签触发 | 依赖下载、编译、打包、镜像构建 | 二进制包、Docker 镜像、构建日志 | 依赖冲突、编译错误、磁盘空间不足 |
| 测试 | 构建成功 | 单元测试、集成测试、性能测试、安全扫描 | 测试报告、覆盖率数据、性能基线 | 测试用例失败、超时、环境配置错误 |
| 部署 | 测试全部通过 | 环境准备、灰度发布、蓝绿部署、健康检查 | 部署版本、回滚脚本、监控告警 | 配置错误、资源不足、健康检查失败 |
实践要点： 每个阶段都应生成结构化的元数据（如构建 ID、测试结果摘要、部署环境标签），这些数据是后续可观测性追踪的基础。
下图展示了典型 CI/CD 流水线的阶段流转与关键检查点：
3.2 自助流水线特点
自助流水线（Self-Service Pipeline）是现代 DevOps 平台的核心能力，它允许开发团队自主创建、配置和执行流水线，而无需等待运维或平台团队介入。其核心特点包括：
- 模板化与标准化： 提供预定义的流水线模板（如 Java 构建、Node.js 部署），确保团队遵循统一规范，同时保留参数化定制能力。
- 声明式配置： 使用 YAML 或 JSON 文件定义流水线步骤，支持版本控制，便于审计和回滚。
- 动态资源分配： 根据流水线负载自动扩缩构建节点或测试环境，避免资源浪费。
- 权限与隔离： 每个团队拥有独立的命名空间和资源配额，流水线执行互不干扰。
- 可插拔集成： 支持通过插件或 Webhook 集成第三方工具（如 SonarQube、Jira、Slack）。
关键区别： 传统流水线由运维团队集中管理，变更周期长；自助流水线将控制权下放给开发团队，同时通过平台治理确保安全与合规。
下图展示了自助流水线的核心组件与交互关系：
3.3 可观测性需求
在自助流水线环境中，可观测性不再是可选项，而是保障交付质量和效率的基础设施。核心需求可归纳为以下三个维度：
| 维度 | 需求描述 | 典型数据源 | 关键指标示例 |
|---|---|---|---|
| 链路追踪 | 追踪一次代码提交从触发到部署完成的完整执行路径，识别瓶颈和失败点 | 流水线事件、API 调用链、步骤耗时 | 端到端耗时、各阶段耗时占比、失败步骤分布 |
| 指标监控 | 实时采集流水线运行状态、资源使用率和成功率，支持告警和趋势分析 | 构建队列长度、节点 CPU/内存、测试通过率 | 流水线成功率、平均构建时间、资源利用率 |
| 日志聚合 | 集中收集构建日志、测试输出、部署日志，支持快速检索和关联分析 | 构建日志、测试报告、部署事件 | 错误日志频率、日志搜索响应时间、日志存储量 |
常见误区： 很多团队只关注流水线是否成功/失败，而忽略了中间状态的可见性。例如，构建阶段耗时从 2 分钟增长到 10 分钟，但流水线仍然“成功”，这种性能退化只有通过持续的可观测性才能发现。
下图展示了可观测性数据在流水线中的采集与流转路径：
实施建议： 从最简单的链路追踪开始，为每个流水线步骤注入 Span（跨度），逐步叠加指标和日志。初期可以只关注端到端耗时和成功率，后续再细化到每个步骤的资源消耗和错误分布。