开发和运维别打架

这词儿打哪儿来：2009 年比利时根特

DevOps 这词儿不是哪个大公司发明的，是一个比利时的 IT 顾问气出来的。这人叫 Patrick Debois¹。

2007 年前后，他做一个比利时政府的项目，被开发和运维两边来回拉扯——开发那边写完就甩过来，运维这边接到一堆没法部署的东西。他想，这事儿不应该这样。🟢 high

2008 年他跑去多伦多参加 Agile 大会，在大会的 BoF 环节（一种自由组队聊天的形式）开了个口子叫"敏捷的基础设施"（Agile Infrastructure）。结果就一个人来了——Andrew Schafer。两个人聊得很投，决定继续搞下去¹。

真正引爆是 2009 年 6 月的 Velocity 大会。Flickr 的 John Allspaw 和 Paul Hammond 上去做了一个题目特别炸的演讲：10+ Deploys Per Day: Dev and Ops Cooperation at Flickr——一天部署 10 次以上，开发和运维要怎么协作。Debois 没去现场，在比利时远程看。看完之后旁边人怂恿他：你自己搞个会吧。²

他真就办了。2009 年 10 月 30 日，在比利时根特，第一届 DevOpsDays 开张。Debois 把会议名字砍短当成社交媒体的标签——#DevOps。这词儿从此就传开了。²

开发跟运维以前为啥老打架

要听懂 DevOps，你得先听懂它要解决的疼。这个疼有个专门的名字，叫"困惑之墙"（Wall of Confusion）——Andrew Schafer 和 Lee Thompson 提的³。

这堵墙是个比喻。开发坐墙这边，运维坐墙那边。开发写完代码，往墙上一甩——"喏，给你部署去"。运维接到一坨东西，环境跟开发那边不一样、依赖缺一堆、出事了不知道找谁。🟢 high

为啥会这样？因为两边的 KPI 是反着的。开发的奖金跟"上了多少新功能"挂钩，他天然求变。运维的奖金跟"系统稳不稳、出没出事"挂钩，他天然求稳。变和稳本来就矛盾——你今天加新东西，就有可能把昨天稳的东西搞坏。

这件事	开发怎么想	运维怎么想
主要 KPI	上新功能、做需求	系统稳定、SLA 不破
对"变更"的态度	越多越好，业务在等	越少越好，每次变更都是风险
时间感	这周必须上	让我先评估两周
出事时第一反应	是不是环境配置不对	是不是代码写错了
周末怎么过	写新代码	凌晨被叫起来救火

这表你看完就懂为啥两边非打架不可——他们站的位置就让他们必须打。不是哪个人坏，是结构的问题。

DevOps 到底改了啥：CALMS 五件套

知道了疼在哪儿，DevOps 给的答案就好懂了。Jez Humble（《持续交付》《DevOps Handbook》的作者）总结了一个简单的检查表叫 CALMS⁴，五个字母对应五件要改的事。这是目前业界最常用的一套自检框架。🟢 high

C — Culture（文化，最关键的一条）

拆掉那堵墙。开发和运维一起背 KPI——线上挂了不是运维一个人的责任，发版慢也不是开发一个人的责任。这是 CALMS 里最难做、也最关键的一条。后面四条都是术，这一条是道。

A — Automation（自动化）

凡是能让机器干的事，别让人干。代码合并要自动跑测试（CI），测试通过要自动部署到测试环境（CD），基础设施要写成代码自动起（IaC）。不是为了快，是为了消除"人手一过就出错"的环节。

L — Lean（精益）

从精益生产借来的——小批量、小步快跑、不囤货。一次发 100 个改动，出事根本不知道是哪个改动搞的；一次发 1 个改动，出事一看就知道是它。所以宁愿一天发 10 次每次 1 个，也不要一周发 1 次每次 10 个。

M — Measurement（度量）

用数据说话，不靠"我觉得"。这块儿后来 Google 的 DORA 团队⁵给出了四个最常用的指标，行业里几乎人手一份：

• 部署频率（Deployment Frequency）——多久能发一次版？
• 变更前置时间（Lead Time for Changes）——一个改动从写完代码到上线要多久？
• 变更失败率（Change Failure Rate）——发上去的版本有多少出事？
• 故障恢复时间（Time to Restore / MTTR）——出事到修好要多久？

2024 年那份 DORA 报告里，精英组能做到一天部署多次、出事一小时内恢复、变更失败率 5% 上下⁵。你拿这四个数字往团队头上一套，团队是不是真在做 DevOps，一目了然。

S — Sharing（共享）

出事了不藏着、不甩锅。无指责复盘（blameless postmortem）、文档公开、知识不锁在某个人脑子里。这一条往往最被低估——一个团队 DevOps 做得好不好，看他们出事之后开会的氛围就知道。

CI/CD、SRE、DevOps 工程师又是啥

说到这儿你大概率已经被几个相邻的词搞晕了：DevOps、CI/CD、SRE、DevOps 工程师——这一堆到底什么关系？这一节把它们一次性摆平。

名字	是什么	主要在干啥
DevOps	一套工作方式 + 文化	让开发和运维不扯皮、共担责任、整套交付自动化
CI/CD	一组具体的工程实践	代码合进来就自动跑测试（CI），通过就自动部署到环境（CD）
SRE	Google 发明的一种岗位 + 方法	用写代码的方式来管线上系统的稳定性（SLO / error budget）
DevOps 工程师	一个被滥用的岗位名	多数时候是搭 CI/CD、写 IaC、管 K8s 的人，名字争议很大

说人话的版本：

• DevOps 是个房子。整套文化和方法。
• CI/CD 是房子里的某根承重柱。DevOps 几乎所有团队都靠它撑着，但 CI/CD 只是 DevOps 里"自动化"这块的代表，不是 DevOps 的全部。
• SRE 是另一种盖这个房子的施工队。Google 2003 年内部就在搞了，2016 年出了那本《Site Reliability Engineering》才广为人知⁷。SRE 跟 DevOps 大方向一致（都要破墙），但 SRE 更具体——它告诉你 SLO 怎么定、error budget 怎么算、on-call 怎么排，是一套可执行的工程教条。"class SRE implements DevOps"——SRE 是 DevOps 这个抽象接口的一个具体实现。
• DevOps 工程师就有点尴尬了。理论上根本不该有这个岗位——DevOps 是文化，全员的事儿，怎么能让一个人或一个团队"负责 DevOps"？但现实是这个 title 满招聘网站都是⁶。实际工作就是：搭 Jenkins / GitHub Actions、写 Terraform、管 K8s、配监控告警。本质上是过去那个"运维"换了个洋气的名字。