DevOps 基础：核心概念、CI/CD 与基础设施即代码
在开始接触具体工具链之前，有必要先厘清 DevOps 的底层逻辑。DevOps 并非一个可安装的软件包，也不是某个岗位的职称，而是一套围绕“价值流动”展开的工程文化与实践集合。它的核心目标，是消除开发团队与运维团队之间长期存在的“部门墙”，让软件从代码提交到生产环境运行的整个过程变得更快、更稳、更可预测。
核心概念：三个维度理解 DevOps
要快速建立对 DevOps 的整体认知，可以从以下三个维度切入：
- 文化（Culture）：强调共享责任、跨职能协作与相互信任。开发不再“扔过墙”就结束，运维也不再被动接收“神秘产物”。
- 流程（Process）：将传统瀑布式的长周期交付，拆解为小批量、高频次的迭代循环。每一轮迭代都包含需求、编码、构建、测试、部署、运行反馈。
- 工具（Tools）：用自动化工具链承载上述流程，减少人工干预带来的延迟与错误。工具是文化的载体，也是流程的固化形式。
这三者缺一不可。只买工具不改变文化，工具会成为新的“流程负担”；只喊口号不落地工具，流程则永远停留在文档里。
持续集成与持续部署（CI/CD）
CI/CD 是 DevOps 落地最核心的工程实践。它由三个递进阶段组成，但常被混为一谈。
持续集成（Continuous Integration, CI）
开发人员频繁地将代码变更合并到主干分支（通常每天多次）。每次合并都会触发一次自动化构建与测试，从而尽早发现集成冲突与回归缺陷。CI 的核心价值在于“尽早反馈”，避免“集成分地狱”在项目后期集中爆发。
持续交付（Continuous Delivery, CD）
在 CI 的基础上，确保每一次通过测试的构建产物，都具备随时部署到生产环境的条件。部署动作本身可能仍需人工审批，但整个流程已经标准化、可重复。
持续部署（Continuous Deployment, CD）
持续交付的进一步延伸：任何通过自动化测试的提交，都会自动部署到生产环境，无需人工干预。这要求测试体系极其健壮，通常适用于微服务架构或对快速迭代有强需求的业务。
下图展示了 CI/CD 流水线中从代码提交到生产部署的完整链路，以及各阶段对应的典型工具与产物：
基础设施即代码（IaC）
传统运维中，服务器、网络、负载均衡等资源的配置依赖人工点击控制台或手写脚本，环境差异导致“在我机器上是好的”成为常态。IaC 的核心思想，是将基础设施的期望状态用声明式或编程式代码描述，并纳入版本控制。
IaC 带来三个直接收益：
- 可重复性：同一份代码可以反复创建完全一致的环境（开发、测试、预发、生产）。
- 可审计性：所有变更都通过代码评审与版本记录，谁在何时改了什么一目了然。
- 自愈能力：当实际状态与期望状态发生偏移时，工具可以自动纠正或告警。
根据管理对象的不同，IaC 分为两类：
| 类型 | 管理对象 | 典型工具 | 示例场景 |
|---|---|---|---|
| 配置管理 | 单台服务器内部的软件状态（安装、配置、服务） | Ansible, Puppet, Chef | 确保所有 Web 服务器都安装 Nginx 1.24 并开放 443 端口 |
| 基础设施编排 | 云资源整体拓扑（VPC、子网、虚拟机、负载均衡） | Terraform, CloudFormation, Pulumi | 一键创建包含 3 台应用服务器和 1 个 RDS 数据库的完整环境 |
以下是一个使用 Terraform 声明 AWS 安全组规则的简化示例，展示“代码即基础设施”的直观形态：
resource "aws_security_group" "web_sg" {
name = "web-server-sg"
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}这段代码描述了安全组的期望状态。执行 terraform apply 后，云平台会创建或更新对应资源；执行 terraform plan 则可以预览变更内容，避免“手一抖删了生产库”。
典型场景：一次完整的变更之旅
假设一个电商团队需要为订单服务新增一个超时取消功能。在 DevOps 模式下，流程如下：
- 开发人员创建功能分支，编写代码与单元测试，提交后发起 Merge Request。
- CI 流水线自动触发：编译、跑测试、构建 Docker 镜像，并将镜像推送至私有仓库。
- IaC 代码同步更新：在 Terraform 仓库中修改订单服务的环境变量与实例数量。
- CD 流水线将新镜像部署到预发环境，运行集成测试与冒烟测试。
- 审批通过后，流水线执行滚动更新，将生产环境实例逐步替换为新版本，期间自动进行健康检查。
- 监控系统发现错误率异常，触发自动回滚至上一版本，同时告警通知值班人员。
整个过程从代码提交到上线，可能仅需 30 分钟，且每一步都有日志与审计记录。
常见误区与复盘
很多团队用 Jenkins 拉了个构建任务，就宣称“已落地 CI/CD”。实际上，如果构建后仍需人工手动登录服务器替换 jar 包，那只是“自动化构建”，并未实现持续部署的价值。真正的 CD 必须包含环境编排与部署动作的自动化。
如果脚本是命令式地“先创建 A，再等待 10 秒，再创建 B”，这仍然是脆弱的自动化。IaC 的核心是声明期望状态，由工具负责收敛差异。例如 Terraform 会通过状态文件自动识别哪些资源需要新增、修改或销毁，而不是机械地重复执行命令。
即使使用了 IaC，如果允许运维人员临时登录服务器手动修改配置文件，代码与真实环境就会逐渐脱节。正确的做法是：任何变更都必须通过修改代码并走流水线生效，服务器本身应被视为“不可变对象”。
复盘清单
在团队落地 DevOps 基础能力时，建议对照以下清单进行自检：
- 代码合并到主干后，是否能在 10 分钟内自动完成构建与单元测试？
- 测试环境是否可以通过一条命令或一次点击完全重建？
- 生产环境的部署是否无需 SSH 登录服务器执行手工命令？
- 基础设施的变更是否经过代码评审并保留历史版本？
- 当部署失败时，回滚操作是否比手动修复更快、更可靠？
- 团队是否用同一个指标（如前置时间）来衡量交付效率？
如果以上问题的答案多为“否”，那么当前团队仍处于“伪 DevOps”阶段，需要优先补齐 CI/CD 流水线的自动化程度，并逐步将基础设施纳入版本控制。只有将文化、流程与工具三者协同推进，DevOps 才能真正成为提升组织效能的引擎，而非一套停留在 PPT 上的概念。