编程语言研究书库
精通 DevOps

为什么是 DevOps:一道没人修的墙

为什么是 DevOps:一道没人修的墙

1. 这一章讲什么

这一章回答一个问题:DevOps 到底是怎么来的,为什么上一代方法解决不了它要解决的问题?

作者的做法是把软件工程史走一遍:瀑布式 → 螺旋式 → 敏捷 → DevOps,每一代治上一代的病,最后把「开发与运维之间那道墙」暴露出来。然后给出全书的骨架:DevOps 的八个阶段(Plan、Code、Build、Test、Release、Deploy、Operate、Monitor),后面十二章就是沿着这八个阶段逐个展开。读这本书,这一章是地图。

2. 顶层全景

先给全书反复用的一个词:软件开发生命周期(Software Development Life Cycle,SDLC)——从「有人觉得需要一个软件」开始,到需求、开发、测试、部署、维护,走完一整套流程。所有开发方法论(瀑布、螺旋、敏捷、DevOps)都是这套流程的不同走法1。

这一章的推理链:

  瀑布式:一口气走完,不回头        → 太慢,需求一变全毁
    ↓ 螺旋式:把开发画成圈,每圈先评估风险 → 贵,只适合大项目
      ↓ 敏捷:小步快跑,两周交付一版      → 开发变快了,但运维没跟上
        ↓ DevOps:把运维也拉进圈里,八个阶段自动转成一个环

主线例子(全章共用):一家从零开始做电商应用的创业公司,八个阶段各走一步,看每一步具体干什么、用什么工具。

3. 核心原理

3.1 瀑布式:把造软件当成盖楼

最早的成体系方法是瀑布模型,1970 年代由 Winston Royce 提出(Royce 本人从没叫过它「瀑布」,是后来的人看他画的图——一级一级往下流,像瀑布——给起的名字)2。

它把开发分成七级台阶,一级走完才许下一级开工:系统需求 → 软件需求(写成一份 SRS 文档,相当于开发方和委托方之间的合同)→ 概要设计 → 详细设计 → 编码调试 → 测试 → 上线维护3。

问题不在「分阶段」本身,而在不许回头:需求在第三级发现理解错了,理论上要回到第一级重来。而真实世界里需求几乎必然变。书里点破:瀑布的低效来自「刚性的阶段」和「需求收集、开发、交付、运维各环节之间缺乏整合」4。

3.2 螺旋式:每一圈先问「会死在哪」

1986 年 Barry Boehm 提出螺旋模型,把开发画成一个螺旋,每转一圈交付一个更完整的版本。每一圈分四个象限:定目标 → 风险分析 → 开发测试 → 客户评审5。

关键创新是风险分析进了流程本身:每一圈开工前先评估「这一步最可能死在哪」。代价是贵——每圈都要做正式的风险评估和评审,所以书里说它天生是给「大型、复杂、高风险项目」准备的6。它治病(把风险管理纳入流程),但副作用是流程变重。

3.3 敏捷:小步快跑,但只跑了一半

2001 年,17 位专业人士写下《敏捷宣言》,敏捷从此流行7。做法换成大白话:不从一开始就定死全部计划,而是小步走、勤回头看——每个迭代(常见的是两周)交付一版能用的软件,用户看完给反馈,下一个迭代照反馈调整8。

「一个方法算不算敏捷」有五条判据:拆成小模块、增量交付、客户与开发者紧密协作、方法本身简单易改、随时能吸收需求变更9。宣言里还有十二条原则,这一章逐条讲了,最有味的两条:第 7 条「能工作的软件是进度的主要度量」——不看写了多少文档,看跑起来多少功能;第 10 条「简单」——把工作里没做的部分最大化,也就是能不做就不做10。

敏捷的好处书里给了实例:Spotify 的移动 App 大约每两周发一次更新11。但 Agile 有个结构性的缺口,书里用一家视频流媒体公司点破:开发团队跟客户贴得很紧、交付很快,可一到部署就出事——运维团队跟开发不在一个频道上,高峰时段宕机,用户恼火12。根子是:敏捷把所有力气花在「开发+测试」这一半,另一半「运维+IT 基础设施」没人管。墙上写着:开发关心功能交付,运维关心系统稳定,两边指标相反、互不理解。

3.4 DevOps:把另一半也拉进圈里

2009 年,比利时人 Patrick Debois 造出「DevOps」这个词,并在根特办了第一届 DevOpsDays 大会13。名字就是答案的缩写:Dev(开发)+ Ops(运维),把两个职能合成一个团队、一套流程。

书里特别强调:DevOps 不是某个工具或软件,它是一套实践和文化哲学14。工具换再多,如果上云之后开发和运维还是各干各的(原话是「继续在筒仓里运作」),云的好处照样全部落空15。

DevOps 的目标清单(图 1.7):拆掉筒仓、组建跨职能团队、让 IT 对齐业务、更快更小的发布、整体改进(上市时间、质量、满意度)、减少浪费和缺陷16。

最能说明「为什么值得」的一组数字是运维人数比的变迁:传统时代开发与运维人数比约 6:1 到 8:1(六到八个开发配一个运维),而现代 DevOps 实践下到了 25:1——自动化和云接管了大部分运维杂务,同样的人力可以更多投在开发上17。

成功的七条规矩里,最反直觉的是文化那两条:远离「他们」文化(出问题互相甩锅),拥抱「我们」文化(共担责任);以及不许罚——把失败当学习机会,团队才敢快速试错18。

3.5 八个阶段:一个自动转的环

DevOps 不是线性流程,是环。用主线例子走一遍:那家做电商 App 的创业公司。

阶段干什么(主线例子里的那一步)典型工具(书里点的名)
Plan 计划收集需求:用户认证、商品目录、购物车、支付;定目标、排期、估风险GitHub Project、Jira、Azure DevOps
Code 编码写后端 API、前端界面、数据库结构;用分支管理并行开发Git、GitHub、GitLab
Build 构建编译打包,把源码变成可运行的构件(如 Docker 镜像);依赖管理Maven、npm、pip、Gradle、Docker
Test 测试集成测试、功能测试、性能压测、安全测试Selenium、JMeter、OWASP ZAP
Release 发布打包装备、写发布说明、定部署计划和回滚预案Jenkins、Ansible
Deploy 部署把构件送上生产环境;蓝绿、金丝雀等策略Jenkins、Ansible、Terraform
Operate 运营扩缩容、负载均衡、保活,让系统扛住流量Kubernetes、NGINX、AWS ELB
Monitor 监控盯响应时间、错误率、CPU、内存;把结果反馈回 PlanPrometheus、Grafana

(以上工具名逐字出自原书各阶段小节19。)

两个细节值得带走。第一,环的意思是监控的产出回流到计划:监控阶段收集的指标和用户反馈,送回 Plan 阶段驱动下一轮迭代——这才是「持续改进」四个字的机制,不是口号20。第二,阶段可以定制:金融机构可能在每个阶段里内嵌安全环节(计划时做威胁建模、构建时扫漏洞),教育公司可能单独加一个反馈阶段——书正文用的是上面这套标准八阶段21。

4. 作者的判断与证据

有出处支撑的判断:

  • DevOps 由 Debois 在 2009 年正式命名——有当年 DevOpsDays 博客为证13。
  • 敏捷 2001 年宣言、十二条原则——直接引宣言原文7。
  • Netflix、Amazon、Google、Spotify、Etsy 是 DevOps 早期采用者——书里明写,属作者陈述的行业共识22。

作者引用但没展开的证据:

  • 「2023 Accelerate State of DevOps Report」(DORA/Google)和 Puppet 的同类报告被点为「最流行的两份行业调查」,用来支撑「DevOps 已成主流、但合格人才短缺」的说法23。注意:这两份是行业调查(自报数据),不是受控实验——书里没做这一层区分,我们替它补上。
  • 6:1→25:1 的人数比变化17:方向可信(自动化确实吃掉了重复性运维工作),但书中未给这组数字的原始调查来源,宜当作示意而非精确统计。

属于各家共识、本书只复述的: 瀑布僵化、敏捷漏掉运维——这是 Kim、Humble 等《The DevOps Handbook》的标准叙事,本书参考文献 [1] 就是它24。

5. 边界与局限

  • 只讲「为什么」和「是什么」,不讲「怎么落地」:八阶段里每一段的深度展开是后面各章的事,这一章的深度到「知道每个阶段干什么、叫什么工具」为止。
  • DevOps 的反面教材着墨少:什么时候不该上 DevOps(比如只有三个人的小团队维护一个单体应用),书里只在微服务一节捎带一句「DevOps 也可以在单体架构上实现」25,没有展开决策框架。
  • 2026 年成书,但方法论叙事停在经典口径:GitOps、平台工程等更新的实践要到第 8 章才零星出现。
  • 章末复习题质量高(设计度量体系、从瀑布迁到 DevOps 的迁移策略),说明这本书的定位是教材——它按教材的密度铺概念,不追求某个主题的穷尽。

6. 可带走的

  1. DevOps = 开发 + 运维的合成词,2009 年由 Patrick Debois 正式命名;它首先是文化(拆筒仓、共担责任),其次才是工具链1314。
  2. 软件方法论史是一条治病链:瀑布治混乱、螺旋治风险、敏捷治慢、DevOps 治开发与运维的墙——每代修上代,各自留新病。
  3. 「能工作的软件是进度的主要度量」和「把没做的工作最大化」是敏捷十二条里最常被记住的两条10。
  4. DevOps 八个阶段是环不是线:Plan → Code → Build → Test → Release → Deploy → Operate → Monitor → 回到 Plan19。
  5. 监控阶段的产出必须回流到计划阶段,闭环才成立;断了回流,「持续改进」就是口号20。
  6. 运维人数比 6:1~8:1 → 25:1 的变化,说明自动化吃掉的主要是重复性运维劳动17。
  7. 没有「他们」只有「我们」、失败不罚、凡事用度量——这三条文化规则,工具替代不了18。

7. 原文地图

主题原书章原文位置
SDLC 与瀑布模型1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:24(搜「coined the term “waterfall”」) · text/06-ch01-1-introduction-to-devops.txt:36(搜「linear sequence of phases」)
螺旋模型四象限1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:84(搜「spiral with four quadrants」)
敏捷十二条原则1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:900(搜「Agile Manifesto」)
DevOps 命名与历史1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:327(搜「coined by Patrick Debois」)
敏捷留下的缺口1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:287(搜「gap that comes with the Agile model」)
6:1 到 25:1 人数比1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:405(搜「historical ratio of 6:1 to 8:1」)
八阶段走一遍(电商例子)1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:475(搜「begins with planning」)
成功七规矩(「我们」文化)1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:453(搜「Stay away from “They” culture」)
使能技术(云/容器/VCS/微服务/IaC)1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:767(搜「reduces the “it works on my machine” problem」)
DORA/Puppet 行业报告1 - Introduction to DevOpstext/06-ch01-1-introduction-to-devops.txt:339(搜「2023 Accelerate State of DevOps Report」)

Footnotes

  1. 出处:「1 - Introduction to DevOps」第 12 段(text/06-ch01-1-introduction-to-devops.txt:12,搜「series of phases and processes」)。原文:「The SDLC is a series of phases and processes that guide the creation, testing, deployment, and maintenance of software applications」。 ↩

  2. 出处:「1 - Introduction to DevOps」第 20–24 段(text/06-ch01-1-introduction-to-devops.txt:21,搜「Winston W. Royce」)。Royce 1970 年代提出模型、从未造「waterfall」一词,书里明写。 ↩

  3. 出处:「1 - Introduction to DevOps」第 35–37 段(text/06-ch01-1-introduction-to-devops.txt:36,搜「linear sequence of phases」)。七阶段列举见第 33–74 段。 ↩

  4. 出处:「1 - Introduction to DevOps」Summary 段(text/06-ch01-1-introduction-to-devops.txt:847,搜「rigid phases」)。 ↩

  5. 出处:「1 - Introduction to DevOps」第 77–80 段(text/06-ch01-1-introduction-to-devops.txt:77,搜「introduced by Barry Boehm in 1986」)。 ↩

  6. 出处:「1 - Introduction to DevOps」第 98–99 段(text/06-ch01-1-introduction-to-devops.txt:99,搜「Tailored to large projects」)。 ↩

  7. 出处:「1 - Introduction to DevOps」第 104 段(text/06-ch01-1-introduction-to-devops.txt:104,搜「By 2001, Agile software development emerged」)。 ↩ ↩2

  8. 出处:「1 - Introduction to DevOps」第 148 段(text/06-ch01-1-introduction-to-devops.txt:148,搜「lasts around 2 weeks」)。 ↩

  9. 出处:「1 - Introduction to DevOps」第 151–162 段(text/06-ch01-1-introduction-to-devops.txt:152,搜「considered agile if it incorporates」)。 ↩

  10. 出处:「1 - Introduction to DevOps」第 195–207 段(text/06-ch01-1-introduction-to-devops.txt:195,搜「primary measure of progress」;:207 搜「maximizing the amount of work not done」)。 ↩ ↩2

  11. 出处:「1 - Introduction to DevOps」第 252–253 段(text/06-ch01-1-introduction-to-devops.txt:254,搜「every 2 weeks」)。 ↩

  12. 出处:「1 - Introduction to DevOps」第 286–299 段(text/06-ch01-1-introduction-to-devops.txt:297,搜「gap between “Developer + Tester”」)。 ↩

  13. 出处:「1 - Introduction to DevOps」第 325–329 段(text/06-ch01-1-introduction-to-devops.txt:327,搜「coined by Patrick Debois」)。 ↩ ↩2 ↩3

  14. 出处:「1 - Introduction to DevOps」第 314 段(text/06-ch01-1-introduction-to-devops.txt:314,搜「not a specific tool or software」)。 ↩ ↩2

  15. 出处:「1 - Introduction to DevOps」第 749–750 段(text/06-ch01-1-introduction-to-devops.txt:749,搜「continues to operate in silos」)。 ↩

  16. 出处:「1 - Introduction to DevOps」第 415–447 段(text/06-ch01-1-introduction-to-devops.txt:415,搜「Break down silos」)。 ↩

  17. 出处:「1 - Introduction to DevOps」第 405–408 段(text/06-ch01-1-introduction-to-devops.txt:405,搜「historical ratio of 6:1 to 8:1」)。 ↩ ↩2 ↩3

  18. 出处:「1 - Introduction to DevOps」第 449–467 段(text/06-ch01-1-introduction-to-devops.txt:453,搜「Stay away from “They” culture」;:457 搜「no-punishment environment」)。 ↩ ↩2

  19. 出处:「1 - Introduction to DevOps」第 504–741 段(各阶段小节,text/06-ch01-1-introduction-to-devops.txt:505,搜「various phases of the DevOps life cycle」)。 ↩ ↩2

  20. 出处:「1 - Introduction to DevOps」第 739–741 段(text/06-ch01-1-introduction-to-devops.txt:739,搜「insights are further forwarded」)。 ↩ ↩2

  21. 出处:「1 - Introduction to DevOps」第 492–500 段(text/06-ch01-1-introduction-to-devops.txt:492,搜「multiple or customized phases」)。 ↩

  22. 出处:「1 - Introduction to DevOps」第 336 段(text/06-ch01-1-introduction-to-devops.txt:336,搜「were the early adopters of」)。 ↩

  23. 出处:「1 - Introduction to DevOps」第 338–343 段(text/06-ch01-1-introduction-to-devops.txt:339,搜「2023 Accelerate State of DevOps Report」)。 ↩

  24. 出处:「1 - Introduction to DevOps」参考文献(text/06-ch01-1-introduction-to-devops.txt:888,搜「The DevOps Handbook」)。 ↩

  25. 出处:「1 - Introduction to DevOps」第 826 段(text/06-ch01-1-introduction-to-devops.txt:826,搜「implemented with monolithic architectures as well」)。 ↩

Mastering DevOps — 全书拆解

Previous Page

计划阶段:开工之前把规矩定完

Next Page

On this page

为什么是 DevOps:一道没人修的墙1. 这一章讲什么2. 顶层全景3. 核心原理3.1 瀑布式:把造软件当成盖楼3.2 螺旋式:每一圈先问「会死在哪」3.3 敏捷:小步快跑,但只跑了一半3.4 DevOps:把另一半也拉进圈里3.5 八个阶段:一个自动转的环4. 作者的判断与证据5. 边界与局限6. 可带走的7. 原文地图Footnotes