1. 先把「用户故事」写清楚：流水线为谁服务？
没有用户画像的流水线，最后会变成「平台自嗨」：功能很多，研发却只想绕过。 最小要回答四类诉求：
- 研发：提交后多久知道对错？失败好不好查？
- 安全/合规：哪些门禁不可跳过？证据链在哪？
- 发布/运维：谁可以发到 prod？如何审批与回滚？
- 平台：Runner 够不够？成本与配额如何控？
Pipeline as Product 的定义：把流水线当作可度量、可迭代、有 backlog 的内部产品，而不是一次性脚本项目。
2. 从约束推导架构：一张「需求 → 阶段」的映射表
常见约束与典型对策：
- 必须过 SAST/SCA → 独立 security stage，失败阻断合并；例外走审批工单。
- PR 必须 10 分钟内反馈 → 单测+lint 并行；重任务放 nightly 或 path filter。
- 多版本运行时 → matrix；共享缓存 key 按版本拆分。
- 合规审计 → 每次运行关联 commit、审批人、制品 digest，日志保留策略。
图 1：约束驱动设计。先列不可妥协的规则（SLA、合规、成本），再决定阶段、并行与门禁，而不是先抄一份模板 YAML。
3. 阶段划分：一条「从提交到交付」的价值流
典型阶段（可按团队裁剪）：
- Prepare：检出、依赖恢复、缓存命中。
- Quality fast：format、lint、单测（并行）。
- Build & test deep：集成测、契约测、E2E（可矩阵、可夜间）。
- Security & compliance：SAST、SCA、license、SBOM。
- Package：镜像/制品、签名、版本元数据。
- Deploy：按环境晋级 + 审批 + 观测门禁。
fail fast：越便宜、越快暴露问题的检查越靠前；越贵、越慢的越靠后或抽样。
图 2：阶段价值流。前置阶段负责快反馈；安全与制品在合并前或发布前卡点；部署阶段与观测、审批联动。
4. SLO 与体验：流水线也要「可用性」
给流水线定义 SLI，避免只凭感觉优化：
- P50/P95 时长：PR 检查、主干构建、发布流水线。
- 成功率：区分「真失败」与「平台抖动」。
- 队列时间：Runner 饱和时体验断崖式下降。
- 开发者满意度：季度问卷 + 工单主题分析。
图 3：Pipeline as Product 迭代环。用指标驱动 backlog，发布模板与门禁改进，而不是一次性大重构。
5. 治理与所有权：谁改流水线？谁背锅？
- CODEOWNERS：流水线目录变更必须平台或指定评审。
- 分支保护：required checks 与最小审批人数对齐风险。
- 环境与密钥：生产部署身份短期化（OIDC），与第 16 章一致。
- 文档：Golden Path：新人从模板仓库 scaffold 一条标准流水线。
6. 最小设计清单（开工前过一遍）
- 列出不可妥协约束（SLA、合规、成本上限）。
- 画用户与触发矩阵（PR / main / tag / manual）。
- 划分阶段并标「快/慢」「阻断/建议」。
- 定义 3～5 个流水线 SLI 与看板。
- 指定 owner 与变更评审规则。