欢迎光临，我是溪源。

今天想跟大家聊聊我最近在读的一本书——乔梁老师的《持续交付2.0：业务引领的DevOps精要》。说真的，这本书第一章就让我有种“相见恨晚”的感觉！

作为研发客官，大家心里可能都曾有过这样的疑问。溪源之前面对产品功能和部署发布时，也多次思考过以下问题：

团队熬了几个通宵把功能写完了，结果上线的时候存在各种问题；
研发过程中，感觉很多东西并不是客户真正需要的功能，产品设计没有站在用户角度思考；
产品发布后，业务方/用户说“这根本不是我们要的东西”。
如果你对这些画面感同身受，那今天这篇文章，值得你放下“锅铲”慢慢看😄

一、软件交付的“三代”：从瀑布到敏捷到DevOps

我们先花三分钟快速回顾一下软件工程方法论的演进史。

1.0时代：瀑布模型（Waterfall Model）——“年初定菜谱，年底才上桌”
最早的软件开发方式叫瀑布模型，它的核心特征是严格按阶段顺序推进，每个阶段完成后才能进入下一个，不允许回头修改。

就像老字号餐馆的年夜饭套餐——提前半年定好菜单，采购、备料、烹饪，每个环节环环相扣，上一道吃一道，一旦开始做就不能改。

具体流程是：需求分析 → 系统设计 → 编码实现 → 集成测试 → 部署上线。每个阶段的产出都要经过正式评审，变更成本呈指数级增长。

相信这种研发模式，绝大多数研发客官做项目的时候都经历过。

等代码真正跑起来，已经是大半年后了。用户说“我要的不是这个”——想改需求？对不起，架构已经定了、代码已经写了、测试已经过了，要改得从头再来。这种变更成本随阶段递增的特性，是瀑布模型最大的痛点。

2.0时代：敏捷开发（Agile Development）——“别写菜单了，先炒个拿手菜试试”

首先我们先了解一下敏捷宣言的核心思想是：与其花半年做完美计划，不如快速做出可运行的软件，通过持续反馈不断调整。它强调响应变化高于遵循计划。

敏捷开发采用迭代（Iteration）和增量（Increment） 的方式，2-4周一个版本，用户能更早看到产品、更早提反馈。

但敏捷有个短板：它主要解决了“怎么快速开发”的问题，却没解决“怎么快速部署”的问题。

这就好比你每周都能炒出一道新菜，请几位老顾客在后厨试吃，反馈很不错。但要把这道菜正式写入大堂菜单、让所有服务员知道、让前台能正常出餐——这中间还有一大段路要走。

在软件领域，这就演变成了开发与运维的经典矛盾：开发关心的是需求实现的效率和灵活性，运维关心的是系统的稳定性和可靠性。

开发团队
说：“我的代码在开发环境跑得好好的，功能都测试通过了，你赶紧部署上线啊！”
运维团队
说：“你说上线就上线？你这代码里引用了新版本的依赖库，生产环境的服务器版本不一样；配置文件你用的是本地路径，到生产环境全得改；还有数据库表结构你改了，我这边的数据迁移脚本还没写呢。你这代码在我这儿根本跑不起来！”
这就是业界常说的 “Dev和Ops之间的鸿沟” ：开发说“你快上菜”，运维说“你灶台的火候和我这儿不一样，端上去会糊”。

3.0时代：DevOps——“谁写的代码谁负责到底”

DevOps这个概念的诞生，就是为了填平上面那道鸿沟。它是一组实践与方法论，核心目标是缩短系统变更从开发提交到部署上线的周期，同时保证部署的可靠性和系统的稳定性。

简单说就是：开发和运维不再是对立的两拨人，而是一个共同对最终结果负责的团队。

DevOps的三大核心理念：

协作
：开发和运维共同制定部署规范、环境标准、监控方案
自动化
：构建-测试-部署流程全部自动化，减少人为操作失误
度量
：用数据说话，部署频率、变更前置时间、故障恢复时间都能量化
在DevOps实践推动下，持续集成（Continuous Integration，简称CI） 和持续交付（Continuous Delivery，简称CD） 逐渐成为标配——

CI（持续集成）
：开发人员每天多次将代码合并到主干分支，每次合并都触发自动化构建和自动化测试，尽早发现集成错误
CD（持续交付）
：代码通过自动化测试后，自动部署到类生产环境（Staging Environment），确保随时可以一键发布
二、持续交付1.0 vs 2.0：快不是目的，对才是

我们这部分再仔细复盘理解一下持续交付到底是什么？

持续交付1.0是什么？

它的核心是构建一条自动化部署流水线（Deployment Pipeline），涵盖代码提交、静态检查、单元测试、集成测试、部署到类生产环境等环节。它的目标是实现 “任何通过测试的构建版本都可随时发布”。

它解决了“代码写好了怎么又快又稳地部署”这个问题，本质上是一个工程效率的提升方案。

但乔梁老师在实践辅导中发现了一个普遍性问题：很多团队虽然实现了“随时发布”的能力，但发布出去的功能根本没有解决业务问题，甚至没人用。

这就是典型的 “做了很多功能，却没产生业务价值”——效率再高，方向错了也是白费。

于是，持续交付2.0应运而生。它的核心升级点是：从“技术导向”转向“业务价值导向”，不再只关注“能不能快速发布”，更关注 “发布的东西有没有真正产生业务价值”。

书中提出了一个核心框架——持续交付2.0双环模型。

图片
三、双环模型：软件交付的“北斗导航”
探索环（Discovery Loop）——先验证“做不做”
探索环解决的是 “有没有价值” 的问题，核心是价值探索。它包含四个步骤：

提问（Question）
：用户的真实痛点是什么？我们要解决什么业务问题？
锚定（Anchor）
：如何衡量这个问题被解决了？定义结果指标（Outcome Metric），比如留存率、转化率、NPS
共创（Co-create）
：团队共同 brainstorm，提出多种可能的解决方案
精炼（Refine）
：从多个方案中选出最小可行性方案（Minimum Viable Product，简称MVP），准备进入验证环
图片
验证环（Validation Loop）——快速验证“能不能做成”
验证环解决的是 “能不能实现” 的问题，核心是快速验证。它也包含四个步骤：

构建（Build）
：把MVP方案变成可运行的软件
运行（Run）
：部署到真实或类生产环境，让目标用户使用
监测（Monitor）
：收集系统指标（System Metrics） 和业务指标（Business Metrics），如响应时间、错误率、用户行为数据
决策（Decide）
：基于数据做出决策——继续优化（Pivot）、扩大推广（Scale）还是直接放弃（Stop）
探索环 → 验证环 → 再探索 → 再验证……形成一个持续迭代的“8”字。

图片
双环模型的核心思想是：任何一个功能上线前，都要在“探索环”中先论证价值，再到“验证环”中用真实数据检验效果。双环转得越快，试错成本越低，交付的风险越小。

四、持续交付核心原则
书中还提炼了持续交付2.0的四个核心原则：

原则1：坚持少做（Less is More）
在制品数量（Work In Progress）越少，交付效率越高。 不要同时启动太多需求，优先做那些价值最高、验证最快的。

原则2：持续分解问题（Continuous Decomposition）
大问题拆成小问题，大版本拆成小迭代。 每次只验证一个假设，每次只部署一个变更。变更粒度越小，出问题时定位越容易。

原则3：快速反馈（Fast Feedback）
反馈越快，纠错成本越低。 代码提交后几分钟内得到自动化测试反馈，功能上线后几小时内得到用户数据反馈。反馈周期的长短直接决定了学习速度。

原则4：持续改进（Continuous Improvement）
没有完美，只有更好。 每完成一轮验证，都做复盘回顾（Retrospective），找到下一个可优化的环节。能力是在循环中长出来的，不是一开始就规划好的。

图片
五、写在最后：从“做完”到“做对”
读完第一章，我最深的感受是：

持续交付1.0关心的是“怎么更快地做完”，持续交付2.0关心的是“怎么更快地做对”。

一字之差，天壤之别。

在VUCA时代——易变（Volatile）、不确定（Uncertain）、复杂（Complex）、模糊（Ambiguous）——你不可能一次性想清楚所有问题。与其花半年憋一个大招，不如每周做一个版本去验证一个假设。

快速失败、快速学习、快速调整，这才是现代软件交付的生存之道。

就像开小馆一样，与其花一年策划一个“完美”的菜单，不如先推几道招牌菜，听顾客说什么，边经营边调整。——用户的声音，永远比你的想象更靠谱。

以上是对《持续交付2.0》第一章内容的思考复盘，不涉及后续章节的扩展。如果你也在实践DevOps转型，欢迎留言交流心得。🍵

感谢你来。坐下来，慢慢聊。

—— 溪源，于编程小馆