DevOps 是什么？——从 Dev/Ops 割裂到持续交付环
DevOps / GitOps · 第 1/15 篇
下一篇预告：《GitOps：用 Git 当交付真相源》
开头：功能写完了，为什么上线还要等两周？
开发把功能合进主干，测试说「环境对不上」；运维说「发版窗口下周才有」。两边目标都合理——开发要快迭代，运维要稳——但交接靠工单和口头约定时，等待本身就成了交付瓶颈。
DevOps 要解决的，不是再招一批「既会写代码又会管机器」的人，而是把软件从想法到线上、再回到反馈的整条链路，变成可重复、可自动化、可度量的协作方式。
一、是什么：Development + Operations（以及 QA）
DevOps 是 Development 与 Operations 的合称，强调开发、测试、运维在同一目标下协作：更快、更稳地交付变更。
字面只有 Dev 和 Ops，实践里 QA 同样在环上——自动化测试、质量门禁、发布验收都是环的一部分。
常见示意图是一个「无穷大 / 8 字」环：左侧偏计划与构建，右侧偏部署与运行，中间用自动化与反馈把两边连起来。它要表达的不是某个工具，而是持续循环。
一句话：
DevOps 是一种协作文化与工程实践，用自动化把构建、测试、发布变得更频繁、更可靠，并用线上反馈驱动下一轮计划。
二、为什么：割裂协作的代价
传统分工大致是：
| 角色 | 目标 | 典型行为 |
|---|---|---|
| 开发 | 尽快交付功能 | 频繁合码、希望尽快验证 |
| 运维 | 系统稳定安全 | 谨慎变更、固定发版窗口 |
| 测试 | 质量达标 | 等环境、等构建产物 |
没有共享流水线时，常见后果是：
- 等待放大周期：开发等反馈，或切去别的项目，上下文切换成本更高
- 环境漂移：「我本地没问题」——依赖版本、配置、数据不一致
- 与敏捷目标冲突：迭代计划很短，上线路径却很长
把可自动化的步骤从人工交接里抽出来，团队才能在不牺牲稳定性的前提下提高变更频率。
三、交付环上有哪些阶段？
不必死记英文缩写，先按一条业务变更走一遍：
| 阶段 | 白话 | 常见工具方向（举例） |
|---|---|---|
| Plan | 定目标与范围 | 看板、Issue |
| Code | 写代码、管版本 | Git、GitLab / GitHub |
| Build | 编译/打包 | Maven、Gradle、npm、Go |
| Test | 单测、集成、质量扫描 | JUnit、SonarQube |
| Release / Deploy | 制品进环境 | Docker、K8s、Helm |
| Operate | 运行与变更 | K8s、IaC |
| Monitor | 看健康与体验 | Prometheus、日志、链路 |
| Feedback → Plan | 监控与事故驱动下一轮 | 告警、复盘 |
CI（持续集成）：变更频繁合入主干，并自动构建与测试，尽早暴露冲突与缺陷。
CD 常被拆成两层：
- 持续交付：主干随时可发布，上线仍可人工点一下
- 持续部署：通过质量门禁后自动上到生产（门槛更高）
本系列后文会分别用 Jenkins、GitHub Actions、GitLab CI 做 CI，用 Argo CD 做面向 Kubernetes 的 CD（GitOps）。
四、DevOps ≠ 某个产品名
容易踩的坑：
- 把「装了 Jenkins」当成「做了 DevOps」——工具只是载体，流程与责任边界没改，环仍然断
- 只自动化构建、不测、不观测——只是把坏变更更快推上去
- 运维仍靠 SSH 手改生产——与后面要讲的 GitOps（声明式、可审计）直接冲突
文化侧要回答：谁对「从提交到线上」负责？失败时如何回滚？度量什么（变更前置时间、失败率、恢复时间）？
工程侧要回答：仓库怎么管？流水线谁维护？制品放哪？谁有权改生产？
五、本系列地图
概念 01 DevOps（本篇） → 02 GitOps
CI 工具链 03 入门 → 04 Jenkins → 05 GitHub Actions
→ 06 SonarQube → 07 Harbor
GitOps 08 环境规划 → 09–11 Argo CD 与清单
端到端 12 GitLab CI × Argo → 13 GHA × Argo → 14 Jenkins × Argo
进阶 15 多集群与回滚你已有 Docker / K8s 基础时，可把重点放在「流水线怎么产出镜像」和「集群状态怎么跟 Git 对齐」。Harbor 安装细节见 Docker 系列 · Harbor，本系列只讲如何接入 CI/CD。
小结
- DevOps 解决的是 Dev / Ops（含 QA）协作与交付路径过长 的问题
- 核心是一条可反馈的环，不是某一个安装包
- CI 保证「合得进、测得过」；CD（尤其 GitOps）保证「集群状态可声明、可追溯」
下一篇把镜头对准 GitOps：为什么要把期望状态放进 Git，以及它和「传统流水线里 kubectl apply」差在哪里。