6. DevOps 工程体系

DevOps 不是「Jenkins + Docker」，也不是一个岗位名称。它是一组把需求、代码、构建、测试、发布、运行、观测和反馈连成闭环的工程约束。这一域把本站已有的容器、Kubernetes、GitOps、可观测性和安全章节串成一条可执行的交付链。

层级:

L4 · 实战

难度:

进阶

预计:

30 分钟

前置:

Git、容器、Kubernetes 基础

架构图

图：DevOps 是一个反馈闭环，而不是一条单向流水线。任何一段断开，交付都会退化成手工操作。

阶段与本站章节

阶段

关键问题

对应章节

Plan

需求是否可验收？容量与成本是否清楚？

学习路线、调度与弹性

Code

分支策略、评审、提交规范

CI/CD 流水线

Build

构建是否可重复？制品是否可追溯？

CI/CD 流水线、GitOps

Test

单测、集成、端到端、策略扫描

供应链安全、策略、密钥与供应链

Release

版本、变更审批、数据库迁移

发布与变更

Deploy

GitOps、灰度、回滚

GitOps 与渐进式发布

Operate

SLO、值班、事件响应

SRE 与事件响应

Observe

指标、日志、链路、告警

可观测性、Prometheus

Feedback

复盘、DORA、平台改进

平台工程、平台工程与多集群

三条闭环

CI 闭环：提交 → 构建 → 测试 → 扫描 → 签名 → 制品。目标是「任何人拿到同一个 commit，都能得到同一个镜像 digest」。

GitOps 闭环：Git 中的期望状态 → 控制器同步 → 集群实际状态 → 漂移检测。目标是「集群状态可审计、可回滚」。

SRE 闭环：SLI/SLO → 告警 → 事件响应 → 复盘 → 改进项。目标是「用错误预算管理发布风险，而不是靠感觉」。

四条工程约束

  1. 构建一次，处处部署：同一镜像 digest 从 dev 推到 prod，不在环境里重新构建。

  2. 配置与代码分离：镜像不变，环境差异用 Helm/Kustomize/ConfigMap 注入。

  3. 所有变更可回滚：应用、配置、数据库迁移、基础设施都要有回滚路径。

  4. 用指标决定发布：灰度是否继续，由错误率、延迟、饱和度决定，不由会议决定。

与「平台工程」的边界

DevOps 关注「团队如何协作交付」，平台工程关注「把重复的交付能力做成自助产品」。前者是流程与文化，后者是产品与工具。两者不是替代关系：没有 DevOps 的反馈闭环，平台工程会变成一堆无人维护的 Portal；没有平台工程，DevOps 会退化成每个团队重复造流水线。

本域文章

关联章节