ops什么意思

DevOps-持续交付的价值

转⾃⾼效运维

前⾔

随着云计算、容器等新兴技术的发展，“持续交付”这个⽼⽣常谈的问题，忽如⼀夜春风来，仿佛找到了从理想通向现实的⼤门。各类相关⼯具、

产品、服务，也是纷纷出现：如Jenkins2.0，JenkinsX，阿⾥云效，NetflixSpinnaker，JfrogArtifactory等等。

你了解持续交付吗？

持续交付，到底是什么意思，它的定义是什么？《持续交付：发布可靠软件的系统⽅法》⼀书中把“持续交付”定义为：

持续交付是软件研发⼈员，如何将⼀个好点⼦，以最快的速度交付给⽤户的⽅法。

即使熟知了定义和⽅法论，其实也还是如海市蜃楼⼀般，⽆法落地，因为⼤家所贡献的最佳实践才是持续交付理论的核⼼。只有真正在⼯作中贯彻

和使⽤这些实践⼯具，才能体会持续交付的真正含义和作⽤。

持续集成、持续交付和持续部署的关系

了解了持续交付，你可能会说“持续集成”、“持续部署”⼜是什么意思，

它们和“持续交付”有什么关系呢。那我就给你简单解释⼀下。

我们通常会把软件研发⼯作拆解，拆分成不同模块或不同团队后进⾏编码，编码完成后，进⾏集成构建和测试。这个从编码到构建再到测试的反复

持续过程，就叫作“持续集成”。

“持续集成”⼀旦完成，则代表产品处在⼀个可交付状态，但并不代表这是最优状态，还需要根据外部使⽤者的反馈逐步优化。当然这⾥的使⽤者

并不⼀定是真正的⽤户，还可能是测试⼈员、产品⼈员、⽤户体验⼯程师、安全⼯程师、企业领导等等。

这个在“持续集成”之后，获取外部对软件的反馈再通过“持续集成”进⾏优化的过程就叫作“持续交付”，它是“持续集成”的⾃然延续。

那“持续部署”⼜是什么呢？软件的发布和部署通常是最艰难的⼀个步骤。

传统安装型软件，要现场调试，要⽤户购买等等，其难度可想⽽知。即使是可达度最⾼的互联⽹应⽤，由于⽣产环境的多样性（各种软件安装，配

置等）、架构的复杂性（分布式，微服务）、影响的⼴泛性（需要灰度发布）等等，就算产品已是待交付的状态，要真正达到⽤户可⽤的标准，还

有⼤量的问题需要解决。

⽽“持续部署”就是将可交付产品，快速且安全地交付⽤户使⽤的⼀套⽅法和系统，它是“持续交付”的最后“⼀公⾥”。

可见，“持续交付”是⼀个承上启下的过程，它使“持续集成”有了实际业务价值，形成了闭环，⽽⼜为将来达到“持续部署”的⾼级⽬标做好了

铺垫。

虽然从概念上你可以这样理解，但从实践和我个⼈多年的经验来说，往往是从“持续部署”（⾃动化发布）开始推进“持续交付”，这才是⼀条优

选的路径。

持续交付的显性价值

持续交付也通常以“发布流⽔线”的⽅式来解释，即研发团队从开发，到测试，再到部署，最终将产品交付给最终⽤户使⽤的过程。如下图：

虽然持续交付着重打造的是发布流⽔线的部分，但它所要达到的⽬标是在“最终⽤户”和“研发团队”之间建⽴紧密的反馈环：通过持续交付新的

软件版本，以验证新想法和软件改动的正确性，并衡量这些改动对软件价值的影响。

这⾥说的“软件价值”，说⽩了就是收⼊、⽇活、GMV等KPI指标了。

在互联⽹应⽤盛⾏、速度为王的今天，持续交付的价值更是被突显出来。持续交付的能⼒，正成为评定⼀家互联⽹公司研发能⼒的重要指标。

持续交付的隐性价值

除了上⾯这些你⼀眼就能看出来的价值外，如果作为不同的⾓⾊、站在不同的⾓度去看持续交付之后的变化，你还会发现其他⼀些隐性价值，⽽其

中有⼀些影响甚⾄远远超过你的预期。

或者可以这么说，通过介绍持续交付的隐性价值，我希望你能够了解到，⽆论是什么企业，⽆论你的职位⾼低，都可以或者应该去尝试持续交付，

它⼀定会让你觉得物超所值。

如果你是CTO或者是⼀个较⼤规模研发团队的管理者

1.你是不是时常困扰于技术选型的问题？

技术选型最⼤的难点在于影响⼤，⼜难以验证（或者验证效率低下）。⽽造成这些困境的绝⼤多数原因是没有合适的测试环境，⽐如环境差异造成

测试数据缺乏说服⼒，⼜⽐如缺少隔离环境造成服务冲突等等。⽽这正是持续交付的⽤武之地。

持续交付的实施，将全⾯改善企业对测试环境的管理⽅法，使得环境管理更合理、更⾃由。我也将在后续章节⾥介绍如何做好环境管理。

2.你是不是经常头痛于已制定的标准难以落地？

标准、规范、流程的落地，都需要载体，⽽最好的载体就是平台⼯具。⽽持续交付是⼀整套平台⼯具的落地，⼏乎涵盖了研发的整个⽣命周期，是

天然的、最佳的载体。

另外，持续交付的落地本⾝就伴随着各类标准、规范、流程的制定和实施，可以说两者相互依存，是⾮常好的管理思想落地⽅案。

3.你是不是时常考虑如何提⾼跨部门协作的效率？

我看到的每⼀个持续交付实施团队，都可以说是最厉害的“拆墙⼤队”，拆的就是各个研发协作部门间的“隔离墙”。

持续交付能够向各个协作部门输出统⼀的标准、流程和⼯具，提升沟通效率；并且通过⼤量的⾃动化，进⼀步提升各部门⼯作效率；还可以快速集

成，把各个分散的团队，⽆论是横向的业务研发团队，还是纵向的技术框架团队，紧紧地联系在⼀起，共同进退。

4.你是不是担⼼“⿊天鹅”的降临？

既然叫“⿊天鹅”，那就是说明它的产⽣有⼀定的必然性。正应了⼀句⽼话“是福不是祸，是祸躲不过”，既然躲不过，那就解决它呗。其实任何

故障都有⼀个天敌，叫作：快速恢复。

假设，所有的故障都可以在3分钟内恢复，你是不是觉得天下⽆敌了。那恢复故障最快、最有效的⼿段⼜是什么呢？当然就是回滚（或重新部署）

了，⽽这正是持续交付所包含和着⼒打造的能⼒之⼀。

如果你是TeamLeader

1.你⼀定希望团队的知识能够传承。

互联⽹公司的⼈才流动之频繁已经远远超过了你我的想象。⼈来⼈往，如何将知识传承下来呢？其实在这⽅⾯，持续交付也能为团队提供很多帮

助。

⾸先，持续交付将团队赖以⽣存的⼯作流程进⾏了固化；其次，利⽤代码静态检查等⼯具，能够很好地传承团队多年来的代码规范，并作为检查项

进⾏⾃动化校验；再次，⾃动化测试的脚本，同样是团队经验的产物。

2.你⼀定希望团队专注于业务⽽⾮⼯程。

⽬前越来越多的公司或研发组织意识到，持续交付体系也如同中间件⼀样，能够从⽇常的业务研发⼯作中抽象出来，其不同只在于中间件解决架构

问题，⽽持续交付解决⼯程问题。这样研发团队能够全⼒应付业务的需求，⽽不⽤总是重复奔波于⼀些烦⼈且耗时的⼯程问题，⽐如安装测试机、

准备编译服务器等等。

3.你⼀定希望以⼀个较平稳的节奏持续⼯作。

虽然在实施持续交付的初期，团队为了适应新的流程和⼯具，会有⼀定的效率下降，但之后在⾃动化的帮助下，团队效率会有⼀个明显的提升并逐

渐稳定下来。

持续交付就是这样通过稳固的流程、⾃动化的⼯具和公开⽽真实的数据，来避免发布前⼣容易发⽣的“死亡⾏军”式开发阶段。

如果你是产品经理

1.你应该是产品真正的第⼀个⽤户。

持续交付不仅仅是可以保证每⼀个变化都能及时得到测试以及反馈，更多的是解决测试与实际发布时存在差异的问题。产品⼈员再也不会陷⼊“为

什么⽤户端运⾏的结果，和在测试环境中的不⼀致”这样的窘境，他们将真正成为第⼀个⽤户，⽽不再是最后⼀个QA。

2.你应该完全知悉当前的进度和质量。

作为产品⼈员，你是不是⼀直有这样的感觉：和研发团队之间总有⼀扇墙，程序员们似乎并不乐意告诉产品⼈员项⽬的真相；⽽最终总有这样那样

的理由造成延期，产品⼈员往往⽆话可说。那么，持续交付就能够实时地反应当前的开发情况，从⽽帮助产品⼈员决策和调整。

3.你的产品应该随时能发布。

计划永远赶不上变化，任何产品⼈员都希望⾃⼰的产品能够随时处于可发布状态。这样就能灵活地交付已完成的功能，迎合市场或业务的需要。本

质上，做到代码上线和业务上线的解耦分离，这也正是持续交付⽅法论强调的⼀个重点。

如果你是⼀个程序员

1.你可以通过对持续交付的学习，进⼀步加强⾃⼰对整个软件⼯程的认识。

持续交付涵盖了软件交付端到端的整个周期，其覆盖⾯不仅仅包括编码，还包括：设计、测试、部署、运维、运营等等。

如果你对⾃⼰的发展有更⾼的要求，那么你就应该学习⼀下持续交付的内容，它能让你看到更多与编码有关的其他东西，⽐如不同的编码⽅式等；

也能让你站在更⾼的⾓度去看待⾃⼰的⼯作：研发效率的提⾼往往不是个⼈能⼒的提⾼，⽽是集体协同效率的提⾼。

2.你可以利⽤持续交付的⼯具或最佳实践，提⾼⾃⼰的⼯作效率和质量。

随着持续交付的流⾏，其配套的实践和⼯具也层出不穷。如果你玩过ping-pong式的结对编程（A写测试，B写实现，然后B写下⼀个测试，A写

重构和实现），你⼀定会觉得编程如此轻松有趣，⽽这种TDD的⽅式也很好的保证了代码质量。

3.你可以参与到持续交付实施中去，享受为其他程序员提供效率⼯具的挑战和乐趣。

试想⼀下，如果你是⼀个出租车司机，⽽你的乘客却是舒马赫（F1世界冠军），此时你开车的压⼒会有多⼤。其实参与到持续交付的实施中也是

⼀样，因为你正在⽤程序员的⽅式改造程序员的⼯作习惯，为程序员提供⼯具。

虽然挑战和压⼒巨⼤，但这⼜是如此有趣，你将会站在另⼀个⾼度去看你曾经的⼯作，不想试试吗？

如何评估持续交付的价值

我跟你说了这么多持续交付的价值，那如何评估它呢？这是⼀个⾮常难的问题，我⾃⼰每年在绩效考评时也都会问⾃⼰这个问题：我到底应该怎么

给⽼板汇报呢？我可以量化持续交付的价值吗？

⾸先，你⼀定会说，我可以衡量产品的交付速度是否变快了。但是，实际情况下影响产品交付速度的因素实在太多，虽然我们⼀定知道持续交付有

积极作⽤，但到底占⽐是多少呢？好像⾮常模糊，难以回答。

然后，你⼜想到，我们可以衡量各个⾃动化过程的速度是否变快了，⽐如：编译速度、发布速度、回滚速度、⾃动化测试速度等等。是的，这些指

标确实很好地反应了持续交付的价值，但总觉得这些并不是全部，持续交付的标准化、推⾏的新流程、改⾰的环境治理架构，好像都没有体现出

来。

那到底应该怎么评估持续交付的价值呢？这⾥和你分享⼀下携程的⼤⽜是怎么解决这个问题的。

我除了会评估⼀些常规的KPI外，更多地会换⼀种思考⽅式。既然很难量化持续交付的价值，那么我们就具象化，来看看整个⼯程⽣命周期中有多

少被开发⼈员诟病，或者阻碍开发⼈员⾃助处理的问题点，即“不可持续点”：

开发不能按需产⽣隔离的测试环境；

⽣产代码回滚后，要⼿⼯处理代码分⽀；

预发布（Staging）流量要能⾃动分离，以便预发布测试。

在携程，他们们会将所有的“不可持续点”进⾏记录和分解，通过OKR的考评⽅式，将消灭这些点作为⽬标，拆解出来的可⾏动点，作为关键结

果，以这样的⽅式来完成绩效考评。

虽然，有些“不可持续点”已经超越了⼀般传统持续交付的概念，甚⾄有些已经超越了纯技术改进的范畴，但是持续交付仍会⼀直关注于消灭这

些“不可持续点”。

所以，我们就是要持续交付我们的价值！

总结

持续交付的价值不仅仅局限于简单地提⾼产品交付的效率，它还通过统⼀标准、规范流程、⼯具化、⾃动化等等⽅式，影响着整个研发⽣命周期。

持续交付最终的使命是打破⼀切影响研发的“阻碍墙”，为软件研发⼯作本⾝赋能。⽆论你是持续交付的⽼朋友还是新朋友，⽆论你在公司担任管

理⼯作还是普通的研发⼈员，持续交付都会对你的⼯作产⽣积极的作⽤。