4. CI/CD 流水线架构概览
在构建跨团队 SLI 口径与 Metric 体系之前，必须统一理解 CI/CD 流水线的标准阶段划分以及多团队协作下的拓扑结构。本章将定义典型流水线的五个核心阶段，并分析在组织级协作场景中流水线如何从线性管道演变为网状拓扑。
4.1 典型 CI/CD 流水线阶段
一条完整的 CI/CD 流水线通常包含以下五个阶段，每个阶段都有明确的输入、输出和关键质量指标（KQI）。
| 阶段 | 核心活动 | 典型工具 | 阶段产物 |
|---|---|---|---|
| 代码提交 | 开发者推送代码变更至版本控制系统，触发 Webhook | GitHub / GitLab / Bitbucket | Commit SHA、PR 元数据、变更文件列表 |
| 构建 | 编译源码、依赖管理、生成制品（JAR/Docker Image） | Maven / Gradle / Docker Build | 构建日志、制品版本号、构建时长 |
| 测试 | 单元测试、集成测试、安全扫描、代码质量检查 | JUnit / SonarQube / Trivy | 测试报告、覆盖率、漏洞列表 |
| 部署 | 将制品部署至目标环境（开发/测试/预发布） | Kubernetes / Ansible / Terraform | 部署清单、环境状态、回滚点 |
| 发布 | 生产环境上线、灰度策略、流量切换、监控验证 | ArgoCD / Spinnaker / Feature Flag | 发布记录、错误率、SLO 达成状态 |
SLI 设计提示： 每个阶段都应至少定义两个 SLI——一个反映速度（如构建时长 P50），一个反映质量（如构建失败率）。避免只关注速度而忽略质量。
4.2 流水线阶段流程关系
下图展示了五个阶段之间的串行依赖关系以及每个阶段的关键质量门禁。箭头表示制品或元数据的流动方向，门禁符号表示只有通过质量检查才能进入下一阶段。
4.3 多团队协作场景下的流水线拓扑
当多个团队（如前端团队、后端团队、数据团队、SRE 团队）共享同一套 CI/CD 基础设施时，流水线拓扑会从简单的单链结构演变为复杂的扇入/扇出与并行网关结构。以下是三种常见的多团队拓扑模式。
4.3.1 扇入模式（Fan-In）
多个团队的制品在同一个聚合流水线中合并、集成测试并统一部署。适用于微服务架构下的集成测试环境。
- 适用场景： 跨团队集成测试、端到端验证
- SLI 关注点： 聚合构建等待时间、集成测试失败率
- 风险： 单个团队阻塞整个流水线
4.3.2 扇出模式（Fan-Out）
一个上游事件（如基础镜像更新）触发多个下游团队流水线并行执行。适用于公共依赖变更后的全量回归。
- 适用场景： 基础库升级、安全补丁发布
- SLI 关注点： 扇出完成率、下游流水线启动延迟
- 风险： 资源竞争导致构建队列积压
4.3.3 并行网关模式（Parallel Gateway）
同一个流水线内，多个团队的任务并行执行，所有任务完成后汇聚到下一阶段。适用于独立模块的并行构建与测试。
- 适用场景： 前后端分离构建、多语言并行编译
- SLI 关注点： 并行阶段最长路径耗时、汇聚等待时间
- 风险： 长尾任务拖慢整体流水线
架构决策： 在多团队拓扑中，建议为每个团队分配独立的流水线命名空间（如 team-a/build, team-b/test），并在聚合层使用事件驱动而非定时轮询来触发下游流水线，以减少资源空转和延迟。
4.4 多团队流水线拓扑示例
下图展示了一个包含三个团队（前端、后端、SRE）的典型多团队流水线拓扑。前端和后端团队各自拥有独立的构建与测试流水线，最终在集成测试阶段扇入，SRE 团队在发布阶段介入执行安全与合规检查。
4.5 拓扑选择对照表
在实际架构中，不同拓扑模式适用于不同的组织结构和交付节奏。下表总结了三种模式的适用条件与 SLI 设计建议。
| 拓扑模式 | 适用组织 | 交付节奏 | 推荐 SLI 口径 |
|---|---|---|---|
| 扇入（Fan-In） | 微服务团队、平台工程团队 | 日级集成 | 集成等待时间、聚合构建成功率 |
| 扇出（Fan-Out） | 基础架构团队、安全团队 | 事件驱动 | 扇出完成率、下游触发延迟 |
| 并行网关 | 全功能团队、特性团队 | 持续交付 | 最长路径耗时、汇聚等待时间 |
常见误区： 不要在所有场景下都使用扇入模式。当团队间依赖极弱时，扇入会增加不必要的等待时间，此时应优先采用并行网关或独立流水线 + 异步通知的方式。
4.6 本章小结
- 典型 CI/CD 流水线包含代码提交、构建、测试、部署、发布五个阶段，每个阶段都有对应的质量门禁。
- 多团队协作场景下，流水线拓扑会演变为扇入、扇出、并行网关三种基本模式。
- SLI 口径设计必须与流水线拓扑匹配：扇入关注等待时间，扇出关注完成率，并行网关关注最长路径。
- 在架构层面，建议为每个团队分配独立的流水线命名空间，并使用事件驱动机制减少资源空转。