02-DevOps 是什么

DevOps 不是一个工具，也不是一个团队，而是"开发（Dev）"和"运维（Ops）"之间协作方式的一次工程化重塑。它的目标用一句话讲清：让代码从提交到线上运行的过程更短、更可靠、更可重复。

本章把 DevOps 拆成三块讲清楚：CALMS 文化框架、DORA 四指标、与 SRE/平台工程的边界。工具链细节留给后续章节。

延伸指标#

除了最初的 DORA 四指标，还有一些指标值得关注：

可靠性（Reliability）：DORA 在 2021 年报告中新增的第 5 个指标，衡量系统运行时的可用性/延迟/可扩展性；落地上对应 SRE 体系里的 SLI/SLO/错误预算，衡量"系统有多稳"
部署规模：每次部署涉及的服务数、配置变更数
恢复成本：一次事故从发现到恢复投入的工时

这些指标和 DORA 四指标配合使用，能更全面地反映团队工程能力。

CALMS 五要素#

CALMS 的前身 CAMS 由 John Willis 和 Damon Edwards 在 2010 年首届美国 DevOpsDays 后提出，后来 Jez Humble 补上 L（Lean，精益）扩展为 CALMS。它是一套文化框架，比任何工具都重要。一个团队 DevOps 转型失败，几乎都不是工具问题，而是 CALMS 中某一环没打通。

要素	全称	含义	落地信号
C	Culture	共担责任的文化	开发出 bug 不甩锅给运维，运维不把生产当黑盒
A	Automation	自动化一切可重复的事	构建、测试、部署、回滚都不靠人手敲命令
L	Lean	精益，消除浪费	小批量交付，消灭"半年大版本"
M	Measurement	度量一切	部署频率、失败率、恢复时间有数据可看
S	Sharing	跨角色共享	运维写的 runbook 进 Git，开发写的告警规则进运维知识库

CALMS 的顺序不是偶然——Culture 在前，Automation 在后。先有"共担责任"的文化，再上 CI/CD 工具才有意义；反过来强行推工具，团队会用各种方式绕过它。

一个常见的反模式：公司买了最贵的 CI/CD 平台，但开发出 bug 仍然甩锅给运维（"我代码在本地能跑，是你们环境问题"），运维把生产当黑盒（"开发改了什么我不知道，反正别动我的线上"）。这种情况下工具再好也救不了——Culture 没打通，Automation 只是把低效的流程自动化了而已。

DORA 四指标#

DORA（DevOps Research and Assessment）团队通过对数千家团队的统计研究，提炼出衡量 DevOps 成熟度的四个核心指标。这四个指标既是诊断工具，也是改进方向。

指标	含义	精英团队水平	低水平团队
部署频率（Deployment Frequency）	单位时间内成功部署到生产的次数	每天多次	每月少于一次
变更前置时间（Lead Time for Changes）	从代码提交到运行在生产的时间	不到 1 小时	超过 6 个月
变更失败率（Change Failure Rate）	部署后导致故障的比例	0-15%	46-60%
平均恢复时间（MTTR）	从故障发生到服务恢复的时间	不到 1 小时	超过 6 个月

四个指标两两配对，构成"速度"和"稳定性"两个维度：

text
        速度维度                      稳定性维度
   ┌─────────────────┐          ┌─────────────────┐
   │  部署频率        │          │  变更失败率      │
   │  变更前置时间    │          │  MTTR           │
   └─────────────────┘          └─────────────────┘

关键洞察：精英团队同时拿高速度和高稳定性，二者不是 trade-off。低水平团队"慢但稳"或"快但常出事"，本质都是工程能力不足；精英团队靠自动化测试、灰度发布、快速回滚把"快"和"稳"同时做到。

如何用 DORA 指标#

DORA 指标不是 KPI 考核工具，是诊断工具。正确用法：

先量一次基线——知道现在在哪一档（低/中/高/精英）
找瓶颈——四个指标里哪个最差？部署频率低可能是 CI 慢；MTTR 长可能是监控不全
针对性改进——CI 慢就优化缓存和并行；监控不全就补可观测性
3 个月后再量——看改善效果

错误用法：把"部署频率"当 KPI 逼团队每天部署 10 次。频率是结果不是目标，强行提高频率只会让变更失败率飙升。

与 SRE、平台工程的边界#

DevOps、SRE、平台工程三个概念经常被混用，它们其实是同一件事的不同侧面：

维度	DevOps	SRE	平台工程
回答的问题	工具怎么搭？协作怎么做？	指标怎么定？决策怎么做？	开发者体验怎么优化？
核心产物	CI/CD 流水线、Git 工作流、镜像仓库	SLO、错误预算、告警策略、事故复盘	内部开发者平台（IDP）、黄金路径、Backstage
面向角色	全员	SRE 工程师 / 运维专家	平台工程师 / 全体开发
关注点	流程自动化	系统可靠性	开发者体验和效率
典型工具	Git、Jenkins、Harbor、ArgoCD	Prometheus、Sentry、PagerDuty	Backstage、Crossplane、Terraform

三者的关系是层层叠加而不是互斥：

text
DevOps（工具链底座）
   └─ SRE（在 DevOps 之上加可靠性方法论）
        └─ 平台工程（把 DevOps + SRE 沉淀成开发者自助平台）

本路线的定位：DevOps 工程实践管"工具怎么搭"，是 SRE 和平台工程的基础。先把 CI/CD、制品管理、IaC、可观测性这套工具链搭起来，SRE 才有数据可看，平台工程才有原料封装。

实战要点#

不要为了 DORA 指标而追求 DORA 指标。先从"部署频率"入手——它是最容易改善、也最能带动其他三个指标的入口。每天能部署一次，变更前置时间和 MTTR 自然会跟着降。
CALMS 的 Culture 是天花板。团队没有"出事故一起扛"的文化，再好的工具也救不了——开发会绕过 CI，运维会手改线上。
DevOps 不是 DevOps 团队。设立一个"DevOps 团队"专门做工具，反而会形成新的部门墙；正确做法是把 DevOps 能力下沉到每个开发小组。

小结#

DevOps 是一套关于"协作和自动化"的工程方法论。CALMS 给出文化框架，DORA 给出度量标尺，本路线后续 30 章都在讲"怎么把这套方法论落地成具体的工具链"。读完本章你应该能回答：我们团队 DORA 四指标现在大概在什么水平？CALMS 哪一环最薄弱？下一章开始从 Git 这个最基础的协作工具讲起。