1.2 DevOps 与 CI/CD 关系
1.2 DevOps 与 CI/CD 关系
本节摘要：DevOps 是开发（Dev）与运维（Ops）协作的文化与实践集合；CI/CD 是实现 DevOps「快速、可靠交付」目标的核心技术管道。本节从一次真实「周五晚上手工上线」事故切入，说明文化变革与自动化工具如何相互依赖。
本节目标
阅读完本节，你应当能够：
- 解释 DevOps 与 CI/CD 的「文化 vs 工具」分工
- 描述 CI/CD 如何打通 Dev 与 Ops 之间的技术壁垒
- 列举 DevOps 除 CI/CD 外的其他实践域
- 评估团队「有 Jenkins 无 DevOps」的典型症状
一、周五晚上的手工上线
某电商团队在促销前夜由运维 SSH 登录三台生产机，手工替换 WAR 包。开发说「我本地测过了」，运维说「你们从不写部署文档」。22:47 第二台机器启动失败——回滚包在开发笔记本上，运维没有权限访问 Git 分支。促销零点流量涌入，502 持续 40 分钟。
这不是工具问题，是协作模型问题：Dev 只管写代码，Ops 只管守机器，中间缺一条可重复、可审计的交付管道。DevOps 要打破这道墙；CI/CD 是墙上开的门。
二、DevOps 是什么，CI/CD 扮演什么角色
DevOps（Development + Operations）2009 年前后由 Patrick Debois 等人推动，核心不是新工具，而是：
- 共享责任：生产稳定性是全员 KPI，不是 Ops 专属
- 自动化优先：重复劳动进脚本/流水线
- 快速反馈：监控、日志、告警回到开发闭环
- 小步发布：降低单次变更 blast radius
CI/CD 是 DevOps 的技术骨架。没有流水线，「协作」仍停留在会议和工单；有了流水线，集成本身变成可观测事件——谁提交、测了什么、部署到哪，全在 Git 与 CI 日志里。
| 维度 | DevOps | CI/CD |
|---|---|---|
| 性质 | 文化、组织、流程 | 工具链、自动化管道 |
| 范围 | 监控、IaC、安全、On-call | 构建、测试、部署 |
| 成功标志 | 跨职能团队、Blameless Postmortem | 绿 build、可发布制品 |
| 关系 | 指导思想 | 落地载体 |
DevOps 全景 vs CI/CD 位置
三、工程实践：让 Dev 与 Ops 在同一条 Pipeline 上相遇
共享仓库里的 Pipeline as Code
Dev 写业务代码，Ops 审 Pipeline 变更——二者在同一 PR 里对话：
# .github/workflows/deploy.yml — Dev 与 Ops 共同维护 jobs: deploy-staging: environment: staging steps: - run: helm upgrade --install myapp ./chart --set image.tag=${{ github.sha }} deploy-prod: needs: deploy-staging environment: production steps: - run: helm upgrade --install myapp ./chart --set image.tag=${{ github.sha }}
Ops 不再「接包部署」，而是定义环境 gate 与集群策略；Dev 不再「扔过墙」，而是对流水线红灯负责。
「你修 bug 要几个人签字？」文化自检
| 症状 | 可能缺 DevOps | CI/CD 可补什么 |
|---|---|---|
| 修 bug 需 5 人审批 | 责任不清 | 自动化测试代替部分人工 sign-off |
| 开发不懂生产配置 | 知识 silo | 配置进 Git，PR 可见 |
| 运维不懂业务逻辑 | 协作断层 | 部署脚本与代码同仓 |
| 事故互相甩锅 | 无共担 | Blameless review + 流水线审计 |
CALMS 模型对照
- Culture：实验、共担 → CI/CD 让失败便宜，鼓励小步试
- Automation：CI/CD 本体
- Lean：消除等待（等构建、等部署窗口）
- Measurement：DORA 指标、构建时长
- Sharing：Pipeline、Runbook 进版本库
⚠️ 常见坑：只买 DevOps 培训不改考核——开发 KPI 仍只看功能点数，没人写测试，CI 永远红或空跑。
💡 关键直觉：Gene Kim《凤凰项目》里的核心是流动——Work in Progress 越少、反馈越快，交付越稳。CI/CD 缩短的是「从变更到知晓结果」的 WIP 停留时间。
GitLab CI 中的 DevOps 一体化示例
GitLab 把 SCM、CI、Registry、K8s Agent 放同一平台，体现 DevOps「工具链收敛」：
stages: [build, test, deploy] build-job: stage: build script: [docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA ., docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA] test-job: stage: test script: [pytest --junitxml=report.xml] deploy-prod: stage: deploy script: [kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA] environment: { name: production } when: manual
when: manual 是 CD；去掉 manual 且测试够强即走向 CDP——文化是否允许比 yaml 语法更先决。
四、DevOps 运动脉络与落地路径
2009 年比利时工程师 Patrick Debois 组织首届 DevOpsDays，「DevOps」一词从此流传。此前开发与运维的对抗是行业常态：Dev 要新功能快上，Ops 要稳定少变，KPI 天然冲突。DevOps 不是新职位头衔，而是把流动、反馈、持续学习与实验写进组织 DNA。
《Accelerate》一书用严谨统计证明：部署频率、前置时间、失败率、MTTR 四项指标与组织绩效正相关——CI/CD 是提升这四项的最杠杆实践。我们见过「DevOps 转型」只买工具不买信任：Jenkins 装好了，但生产变更仍须 VP 邮件批准，反馈环直径仍是「周」级。
落地三阶段
| 阶段 | 动作 | 周期 |
|---|---|---|
| 1. 可见 | 所有 build 结果 Slack 广播 | 1–2 周 |
| 2. 可重复 | 构建测试全自动化 | 1–3 月 |
| 3. 可演进 | CD/CDP + 监控回滚 | 6–12 月 |
阶段 1 常被跳过——团队不知道 CI 红了几个月。先让失败可见，再谈优化速度。
Ops 角色转变
传统 Ops：接 ticket、手工部署、守夜。DevOps 下 Ops 变成平台工程：维护 K8s 集群、Runner 池、Helm chart 模板、Terraform 模块——让 Dev 自助 deploy，而非替 Dev deploy。Google SRE 把 Ops 称为「软件工程师，只是碰巧做基础设施」。
与 SRE 的边界
SRE（Site Reliability Engineering）强调 error budget：允许一定失败率换取发布速度。DevOps 偏文化，SRE 偏量化实践——二者在 CI/CD 上汇合：error budget 耗尽时，CDP 自动降级为 CD（加 manual gate），直到 metrics 恢复。
一节小结
- DevOps 是文化，CI/CD 是落地管道，二者不可互相替代
- CI/CD 打通 Dev/Ops 技术壁垒：同一 PR、同一日志、同一制品
- DevOps 更广：还含监控、IaC、安全、On-call、Postmortem
- Pipeline as Code 让 Ops 规则可评审、可版本化
- CALMS 帮助诊断「有工具无文化」
- GitLab/Jenkins/GitHub 都是载体，协作模型才是本质
- manual deploy gate 是 CD 与 CDP 的文化分界线
下一节 1.3 我们把 DevOps 原则具体化为 CI/CD 八大原则，并绘制完整生命周期。