第3章 CI/CD流水线设计与实践
面试问答卡片
Q1: 如何设计一条高效的CI/CD流水线？
考察点：架构思维、阶段划分合理性、对CI/CD最佳实践的掌握。
回答框架：按“四步递进”组织：①明确业务约束 → ②按质控点划分阶段（构建、单元测试、集成测试、安全扫描、部署） → ③每阶段明确通过/阻断条件 → ④选型工具并说明理由。最后补充优化闭环（反馈速度、并行度）。
示例回答：“一条高效流水线须从业务出发：小团队用GitLab CI + Docker，快速反馈；大规模则用Jenkins X或Tekton，支持K8s原生编排。我按五阶段设计：代码检查→构建→单元测试→安全扫描→金丝雀部署。每阶段失败自动触发告警和回滚，流水线平均耗时控制在8分钟内。”
可能追问：如何保证流水线安全性？如何平衡速度快与质量高？
Q2: 如何选择CI/CD工具？
考察点：工具生态理解、场景匹配能力、迁移成本意识。
回答框架：三维度比较：①团队规模与维护成本 → ②云原生友好度（K8s集成、Operator） → ③插件/扩展生态。给出优先排序：轻量级场景优先GitLab CI / GitHub Actions；企业级优先Jenkins / Tekton。举例说明迁移风险。
示例回答：“100人以下小团队推荐GitLab CI，零运维、YAML即配置；大团队或合规严格环境选Jenkins+Blue Ocean，权限和审计日志完善。关键看是否支持Pipeline as Code、Secret管理、并行Agent。我曾将Jenkins迁移到Tekton，虽然学习成本高但扩展性提升3倍。”
可能追问：Drone CI与GitLab CI对比？如何评估工具寿命？
Q3: 流水线构建失败后，你的排查与恢复流程是什么？
考察点：故障定位、根因分析、团队协作沟通能力。
回答框架：STAR模型：S（情况）描述失败现象 → T（目标）恢复流水线并找到根因 → A（行动）逐层排查（构建日志、依赖缓存、环境差异、测试用例） → R（结果）修复后增加防护措施（单元测试、缓存锁、环境快照）。
示例回答：“一次构建因依赖版本不一致失败。我首先定位到npm缓存过期，然后锁定package-lock版本，增加依赖缓存校验步骤。之后在流水线中增加缓存清理hook，同类问题未再发生。整个过程从报警到修复耗时12分钟。”
可能追问：如何区分基础设施故障和应用代码故障？如何告警分级？
项目案例：微服务CI/CD平台化改造
| 维度 | 内容 |
|---|---|
| 项目名称 | 微服务CI/CD平台化改造（Jenkins→GitLab CI + ArgoCD） |
| 业务背景 | 原有Jenkins单机架构导致构建排队严重、部署人工介入、环境配置混乱。目标：实现全自动、声明式、多环境流水线。 |
| 规模指标 | 120个微服务，800+开发人员，日均构建600+次，部署频率从1次/天提升至10+次/天。 |
| 技术栈 | GitLab CI + ArgoCD + K8s + Helm + SonarQube + Harbor + Prometheus |
| 核心难点 | ①多环境参数管理（dev/staging/prod）②灰度发布与回滚自动化③安全扫描嵌入不拖慢流水线 |
| 面试高频追问 | “金丝雀发布如何实现？”“ArgoCD Image Updater如何处理镜像更新？”“配置漂移如何检测？” |
| 可迁移回答话术 | “我使用Helm Values模板+环境变量注入解决多环境参数管理；ArgoCD Rollout实现金丝雀发布，Metrics分析无异常后自动提升流量；配置漂移通过kube-cop或自建差分检测Job定期比对desired vs actual state。” |
流水线设计决策表（知识结构）
| 流水线阶段 | 关键动作 | 推荐工具（小/中/大规模） | 常见失败原因 |
|---|---|---|---|
| 代码检查 | lint、格式、复杂度 | ESLint / SonarQube / CodeClimate | 规则配置冲突、扫描超时 |
| 构建 | 编译、打包、镜像生成 | Maven / Gradle / Docker / Buildpacks | 依赖版本不一致、缓存失效 |
| 单元测试 | Jest / JUnit + 覆盖率门禁 | Jest / JUnit / pytest + JaCoCo | 环境差异、Flaky test |
| 安全扫描 | SAST/DAST/容器漏洞 | Trivy / Snyk / Checkmarx / OWASP ZAP | 扫描超时、误报过多 |
| 部署 | 灰度发布/蓝绿/滚动 | ArgoCD / Spinnaker / Flux | 配置漂移、镜像拉取失败 |