欢迎光临我是溪源。今天想跟大家聊聊我最近在读的一本书——乔梁老师的《持续交付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转型欢迎留言交流心得。感谢你来。坐下来慢慢聊。—— 溪源于编程小馆