del

极客时间专栏/geek/持续交付36讲/基本概念/01 | 持续交付到底有什么价值？.md

@@ -0,0 +1,175 @@
+<audio id="audio" title="01 | 持续交付到底有什么价值？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/59/c9/5974df97246bec4865b6b2529c654cc9.mp3"></audio>
+
+随着云计算、容器等新兴技术的发展，“持续交付”这个老生常谈的问题，忽如一夜春风来，仿佛找到了从理想通向现实的大门。各类相关工具、产品、服务，也是纷纷出现：如Jenkins 2.0，Jenkins X，阿里云效，Netflix Spinnaker，Jfrog Artifactory等等。
+
+到底是什么魔力使得各大公司和厂商对“持续交付”如此趋之若鹜？那么，作为本专栏的第一篇文章，我就先来为你揭示“持续交付”真正的价值。
+
+## 你了解持续交付吗？
+
+持续交付，到底是什么意思，它的定义是什么？《持续交付：发布可靠软件的系统方法》一书中把“持续交付”定义为：
+
+> 
+持续交付是软件研发人员，如何将一个好点子，以最快的速度交付给用户的方法。
+
+
+是不是听起来有点抽象呢？其实这就好像你去问100个哲学家，“哲学”的定义是什么，你会获得101个答案一样。与马丁 · 福勒（Martin Fowler）老爷子在2006年，提出“持续集成”概念时一样，我们可以**把 “持续交付”定义为“一套软件工程方法论和许许多多的最佳实践的集合”。**
+
+但即使熟知了定义和方法论，其实也还是如海市蜃楼一般，无法落地，因为大家所贡献的最佳实践才是持续交付理论的核心。只有真正在工作中贯彻和使用这些实践工具，才能体会持续交付的真正含义和作用。
+
+## 持续集成、持续交付和持续部署的关系
+
+了解了持续交付，你可能会说“持续集成”、“持续部署”又是什么意思， 它们和“持续交付”有什么关系呢。那我就给你简单解释一下。
+
+我们通常会把软件研发工作拆解，拆分成不同模块或不同团队后进行编码，编码完成后，进行集成构建和测试。**这个从编码到构建再到测试的反复持续过程，就叫作“持续集成”。**
+
+“持续集成”一旦完成，则代表产品处在一个可交付状态，但并不代表这是最优状态，还需要根据外部使用者的反馈逐步优化。当然这里的使用者并不一定是真正的用户，还可能是测试人员、产品人员、用户体验工程师、安全工程师、企业领导等等。
+
+**这个在“持续集成”之后，获取外部对软件的反馈再通过“持续集成”进行优化的过程就叫作“持续交付”，它是“持续集成”的自然延续。**
+
+那“持续部署”又是什么呢？软件的发布和部署通常是最艰难的一个步骤。
+
+传统安装型软件，要现场调试，要用户购买等等，其难度可想而知。即使是可达度最高的互联网应用，由于生产环境的多样性（各种软件安装，配置等）、架构的复杂性（分布式，微服务）、影响的广泛性（需要灰度发布）等等，就算产品已是待交付的状态，要真正达到用户可用的标准，还有大量的问题需要解决。
+
+**而“持续部署”就是将可交付产品，快速且安全地交付用户使用的一套方法和系统，它是“持续交付”的最后“一公里”。**
+
+可见，“持续交付”是一个承上启下的过程，它使“持续集成”有了实际业务价值，形成了闭环，而又为将来达到“持续部署”的高级目标做好了铺垫。
+
+虽然从概念上你可以这样理解，但从实践和我个人多年的经验来说，往往是从“持续部署”（自动化发布）开始推进“持续交付”，这才是一条优选的路径。这部分内容我会在后续文章中详细介绍。
+
+## 持续交付的显性价值
+
+持续交付也通常以“发布流水线”的方式来解释，即研发团队从开发，到测试，再到部署，最终将产品交付给最终用户使用的过程。如下图：
+
+<img src="https://static001.geekbang.org/resource/image/e6/b1/e60e815959ff7a1593f572ed463c86b1.jpg" alt="" />
+
+虽然持续交付着重打造的是发布流水线的部分，但它所要达到的目标是在“最终用户”和“研发团队”之间建立紧密的反馈环：通过持续交付新的软件版本，以验证新想法和软件改动的正确性，并衡量这些改动对软件价值的影响。
+
+这里说的“软件价值”，说白了就是收入、日活、GMV等KPI指标了。
+
+通常我们在实施持续交付后，都能够做到在保证交付质量的前提下，加快交付速度，从而更快地得到市场反馈，引领产品的方向，最终达到扩大收益的目的。
+
+在互联网应用盛行、速度为王的今天，持续交付的价值更是被突显出来。持续交付的能力，正成为评定一家互联网公司研发能力的重要指标。
+
+## 持续交付的隐性价值
+
+除了上面这些你一眼就能看出来的价值外，如果作为不同的角色、站在不同的角度去看持续交付之后的变化，你还会发现其他一些隐性价值，而其中有一些影响甚至远远超过你的预期。
+
+或者可以这么说，通过介绍持续交付的隐性价值，我希望你能够了解到，无论是什么企业，无论你的职位高低，都可以或者应该去尝试持续交付，它一定会让你觉得物超所值。
+
+**如果你是CTO或者是一个较大规模研发团队的管理者**
+
+<li>
+<p>你是不是时常困扰于技术选型的问题？<br />
+技术选型最大的难点在于影响大，又难以验证（或者验证效率低下）。而造成这些困境的绝大多数原因是没有合适的测试环境，比如环境差异造成测试数据缺乏说服力，又比如缺少隔离环境造成服务冲突等等。而这正是持续交付的用武之地。<br />
+持续交付的实施，将全面改善企业对测试环境的管理方法，使得环境管理更合理、更自由。我也将在后续章节里介绍如何做好环境管理。</p>
+</li>
+<li>
+<p>你是不是经常头痛于已制定的标准难以落地？<br />
+标准、规范、流程的落地，都需要载体，而最好的载体就是平台工具。而持续交付是一整套平台工具的落地，几乎涵盖了研发的整个生命周期，是天然的、最佳的载体。<br />
+另外，持续交付的落地本身就伴随着各类标准、规范、流程的制定和实施，可以说两者相互依存，是非常好的管理思想落地方案。</p>
+</li>
+<li>
+<p>你是不是时常考虑如何提高跨部门协作的效率？<br />
+我看到的每一个持续交付实施团队，都可以说是最厉害的“拆墙大队”，拆的就是各个研发协作部门间的“隔离墙”。<br />
+持续交付能够向各个协作部门输出统一的标准、流程和工具，提升沟通效率；并且通过大量的自动化，进一步提升各部门工作效率；还可以快速集成，把各个分散的团队，无论是横向的业务研发团队，还是纵向的技术框架团队，紧紧地联系在一起，共同进退。</p>
+</li>
+<li>
+<p>你是不是担心“黑天鹅”的降临？<br />
+既然叫“黑天鹅”，那就是说明它的产生有一定的必然性。正应了一句老话“是福不是祸，是祸躲不过”，既然躲不过，那就解决它呗。其实任何故障都有一个天敌，叫作：快速恢复。<br />
+假设，所有的故障都可以在3分钟内恢复，你是不是觉得天下无敌了。那恢复故障最快、最有效的手段又是什么呢？当然就是回滚（或重新部署）了，而这正是持续交付所包含和着力打造的能力之一。</p>
+</li>
+
+**如果你是Team Leader**
+
+<li>
+<p>你一定希望团队的知识能够传承。<br />
+互联网公司的人才流动之频繁已经远远超过了你我的想象。人来人往，如何将知识传承下来呢？其实在这方面，持续交付也能为团队提供很多帮助。<br />
+首先，持续交付将团队赖以生存的工作流程进行了固化；其次，利用代码静态检查等工具，能够很好地传承团队多年来的代码规范，并作为检查项进行自动化校验；再次，自动化测试的脚本，同样是团队经验的产物。</p>
+</li>
+<li>
+<p>你一定希望团队专注于业务而非工程。<br />
+目前越来越多的公司或研发组织意识到，持续交付体系也如同中间件一样，能够从日常的业务研发工作中抽象出来，其不同只在于中间件解决架构问题，而持续交付解决工程问题。<br />
+这样研发团队能够全力应付业务的需求，而不用总是重复奔波于一些烦人且耗时的工程问题，比如安装测试机、准备编译服务器等等。</p>
+</li>
+<li>
+<p>你一定希望以一个较平稳的节奏持续工作。<br />
+虽然在实施持续交付的初期，团队为了适应新的流程和工具，会有一定的效率下降，但之后在自动化的帮助下，团队效率会有一个明显的提升并逐渐稳定下来。<br />
+持续交付就是这样通过稳固的流程、自动化的工具和公开而真实的数据，来避免发布前夕容易发生的“死亡行军”式开发阶段。</p>
+</li>
+
+**如果你是产品经理**
+
+<li>
+<p>你应该是产品真正的第一个用户。<br />
+持续交付不仅仅是可以保证每一个变化都能及时得到测试以及反馈，更多的是解决测试与实际发布时存在差异的问题。<br />
+产品人员再也不会陷入“为什么用户端运行的结果，和在测试环境中的不一致”这样的窘境，他们将真正成为第一个用户，而不再是最后一个QA。</p>
+</li>
+<li>
+<p>你应该完全知悉当前的进度和质量。<br />
+作为产品人员，你是不是一直有这样的感觉：和研发团队之间总有一扇墙，程序员们似乎并不乐意告诉产品人员项目的真相；而最终总有这样那样的理由造成延期，产品人员往往无话可说。<br />
+那么，持续交付就能够实时地反应当前的开发情况，从而帮助产品人员决策和调整。</p>
+</li>
+<li>
+<p>你的产品应该随时能发布。<br />
+计划永远赶不上变化，任何产品人员都希望自己的产品能够随时处于可发布状态。这样就能灵活地交付已完成的功能，迎合市场或业务的需要。<br />
+本质上，做到代码上线和业务上线的解耦分离，这也正是持续交付方法论强调的一个重点。</p>
+</li>
+
+**如果你是一个程序员**
+
+<li>
+<p>你可以通过对持续交付的学习，进一步加强自己对整个软件工程的认识。<br />
+持续交付涵盖了软件交付端到端的整个周期，其覆盖面不仅仅包括编码，还包括：设计、测试、部署、运维、运营等等。<br />
+如果你对自己的发展有更高的要求，那么你就应该学习一下持续交付的内容，它能让你看到更多与编码有关的其他东西，比如不同的编码方式等；也能让你站在更高的角度去看待自己的工作：研发效率的提高往往不是个人能力的提高，而是集体协同效率的提高。</p>
+</li>
+<li>
+<p>你可以利用持续交付的工具或最佳实践，提高自己的工作效率和质量。<br />
+随着持续交付的流行，其配套的实践和工具也层出不穷。如果你玩过ping-pong式的结对编程（A写测试，B写实现，然后B写下一个测试，A写重构和实现），你一定会觉得编程如此轻松有趣，而这种TDD的方式也很好的保证了代码质量。</p>
+</li>
+<li>
+<p>你可以参与到持续交付实施中去，享受为其他程序员提供效率工具的挑战和乐趣。<br />
+试想一下，如果你是一个出租车司机，而你的乘客却是舒马赫（F1世界冠军），此时你开车的压力会有多大。其实参与到持续交付的实施中也是一样，因为你正在用程序员的方式改造程序员的工作习惯，为程序员提供工具。<br />
+虽然挑战和压力巨大，但这又是如此有趣，你将会站在另一个高度去看你曾经的工作，不想试试吗？</p>
+</li>
+
+## 如何评估持续交付的价值
+
+我跟你说了这么多持续交付的价值，那如何评估它呢？这是一个非常难的问题，我自己每年在绩效考评时也都会问自己这个问题：我到底应该怎么给老板汇报呢？我可以量化持续交付的价值吗？
+
+首先，你一定会说，我可以衡量产品的交付速度是否变快了。但是，实际情况下影响产品交付速度的因素实在太多，虽然我们一定知道持续交付有积极作用，但到底占比是多少呢？好像非常模糊，难以回答。
+
+然后，你又想到，我们可以衡量各个自动化过程的速度是否变快了，比如：编译速度、发布速度、回滚速度、自动化测试速度等等。
+
+是的，这些指标确实很好地反应了持续交付的价值，但总觉得这些并不是全部，持续交付的标准化、推行的新流程、改革的环境治理架构，好像都没有体现出来。
+
+那到底应该怎么评估持续交付的价值呢？这里和你分享一下我在携程是怎么解决这个问题的。
+
+我除了会评估一些常规的KPI外，更多地会换一种思考方式。**既然很难量化持续交付的价值，那么我们就具象化，来看看整个工程生命周期中有多少被开发人员诟病，或者阻碍开发人员自助处理的问题点** ，即“不可持续点”：
+
+> 
+<p>开发不能按需产生隔离的测试环境；<br />
+生产代码回滚后，要手工处理代码分支；<br />
+预发布（Staging）流量要能自动分离，以便预发布测试。</p>
+
+
+在携程，我们会将所有的“不可持续点”进行记录和分解，通过OKR的考评方式，将消灭这些点作为目标，拆解出来的可行动点，作为关键结果，以这样的方式来完成绩效考评。
+
+虽然，有些“不可持续点”已经超越了一般传统持续交付的概念，甚至有些已经超越了纯技术改进的范畴，但是持续交付仍会一直关注于消灭这些“不可持续点”。
+
+So what，我们就是要持续交付我们的价值！
+
+## 总结
+
+接下来，我给你提炼一下今天内容的要点。
+
+持续交付的价值不仅仅局限于简单地提高产品交付的效率，它还通过统一标准、规范流程、工具化、自动化等等方式，影响着整个研发生命周期。
+
+持续交付最终的使命是打破一切影响研发的“阻碍墙”，为软件研发工作本身赋能。无论你是持续交付的老朋友还是新朋友，无论你在公司担任管理工作还是普通的研发人员，持续交付都会对你的工作产生积极的作用。
+
+## 思考题
+
+你的团队最希望借助持续交付解决什么现实问题？
+
+好了，今天就聊到这里，欢迎你给我留言，下期见！
+
+

极客时间专栏/geek/持续交付36讲/基本概念/02 | 影响持续交付的因素有哪些？.md

@@ -0,0 +1,184 @@
+<audio id="audio" title="02 | 影响持续交付的因素有哪些？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8a/e5/8aad20e0a509bd9f285d2675fbf02fe5.mp3"></audio>
+
+在上一篇文章中，我和你聊了聊“持续交付”的价值。现在，你是不是感觉热血澎湃，似乎找到了解决一些问题的良方？你是不是跃跃欲试，想在团队立刻实施看看效果如何？
+
+但别急，就像我在开篇词里说的一样，“持续交付”可真不是一件简单的事情。你一定会在实施过程中碰到各种各样的问题和困难，但也不要气馁，我现在就和你说说：影响持续交付的各种因素。知己知彼，方可百战不殆。
+
+与绝大多数理论分析一样，影响持续交付的因素也可归结为：人（组织和文化），事（流程），物（架构）。
+
+## 组织和文化因素
+
+谈到组织，你是不是一下就想到了部门划分，跨部门合作等？的确，这就是我要和你讲的第一个影响因素。因为“持续交付“一定是整个组织层面的事情，是跨部门合作的产物，所以组织和文化因素，是要首先考虑的问题。
+
+什么样的组织文化，才是“持续交付”成长的沃土（当然这也是定义好的组织的标准），我把它分成了三个层次：
+
+**第一个层次：紧密配合，这是组织发展，部门合作的基础。**
+
+一般企业都会按照职能划分部门。不同的职能产生不同的角色；不同的角色拥有不同的资源；不同的资源又产生不同的工作方式。这些不同的部门紧密配合，协同工作于共同的目标，就能达到成效。
+
+**第二个层次：集思广益，这就需要组织内各个不同部门，或不同职能的角色，跳出自身的“舒适区”。**
+
+除思考和解决本身职能的问题外，各部门还要为达到组织的共同目标，通盘考虑和解决所遇到问题和困难。这个层次需要增加组织的透明度，需要接受互相批评和帮助。
+
+**第三个层次：自我驱动，是理想中的完美组织形式。**
+
+如果第二个层次能够持续地运转，就会形成自我学习、自我驱动的飞轮效应，并且越转越快，它甚至能自发式的预见困难，并自驱动解决问题。
+
+这三个层次看起是不是有点眼熟，和我在上一篇文章中讲到的持续集成的三个层次：
+
+1. 分模块编码；
+1. 整体集成；
+1. 实现以上两个过程的自动化，并形成闭环；
+
+好像是一样的。真是有趣，持续交付其实也是帮企业建立更好的组织形式的一种方法。
+
+那么，在形成理想组织的实际执行中会遇到哪些问题呢？
+
+**一般软件企业与交付有关的研发部门包括四个：产品、开发、测试和运维。而这四个部门天然地形成了一个生产流水线，所以形成理想组织的第一层次紧密配合，基本没什么问题。**
+
+但是，要达到第二层次集思广益的难度，往往就很大。因为，每个部门有自身的利益，以及自己的工作方式和目标。
+
+- 比如，产品人员和测试人员就是一对矛盾体：产品人员希望产品尽快上线，而测试人员则希望多留时间进行更完整的测试。
+- 又比如，开发人员和运维人员也经常矛盾：开发人员希望能有完全权限，而运维人员却控制着生产的root。
+
+从各自的小目标的角度看，这些矛盾是正常的。但是，产品、开发、测试和运维这些部门的小目标往往就是实施持续交付的阻碍，只有它们把眼光放到更高地持续交付可用的产品上，有了共同的目标，问题才会迎刃而解。
+
+那么，靠各个部门自己能解决这个问题吗，其实很难。组织的问题，还是需要通过组织变革来解决。通常我们会采用以下三种方案：
+
+- 成立项目管理办公室（Project Manage Office，简称PMO）这样的监督型组织，帮助持续交付落地；
+- 独立建立工程效能部门，全面负责包括持续交付在内的研发效率提升工作；
+- 使用敏捷形式，如Scrum，打破职能部门间的“隔离墙”，以产品的形式组织团队，各团队自行推进持续交付 。
+
+当然，这三种方案各有利弊。比如：
+
+- 成立项目管理办公室，虽然会带来非常强大的项目推进力，但它往往需要通过流程把控进行监督，这样就很有可能把流程变得更加复杂；
+- 而独立的工程效能部门，虽然能最大化地去做好持续交付工作，但其研发成本的投入也是需要考虑的，小团队的话，就不太适用了；
+- 敏捷形式是比较适合中小团队的一种组织变革方式，但对个人能力的要求也会比较高，而且往往需要一个很长时间的磨合才能见效。
+
+所以，你需要根据当前组织的情况来选择。**总而言之，持续交付必须有与其相适应的组织和文化，否则将很难实施。**
+
+## 流程因素
+
+要说持续交付对企业和组织改变最多的是什么，那么一定是流程。
+
+持续交付一定会打破的这三类流程是：
+
+<li>
+**耗时较长的流程**。比如，一个功能的研发迭代周期为5天，而其中有一个上线审核流程，需要花费3天时间，那这个流程就严重影响了持续交付，必须被打破。
+</li>
+<li>
+**完全人工类的流程。** 完全人工操作的流程，一般效率低下，且质量难以保证，持续交付的逐步深入会通过自动化替代这些人工流程的存在。
+</li>
+<li>
+**信息报备类的流程。** 持续交付过程中同样会产生各种信息流，这些信息有些需要广播，有些需要定点传递。实施持续交付后，这些信息报备类的流程一定会通过异步消息等方式进行改造。
+</li>
+
+其中，如何对待审批流程是重点。
+
+在持续交付过程中，其实最让你头痛的应该是一些审批流程。这些流程既然叫做审批，那就代表着授权与责任，代表着严谨与严肃，因此也一定有其存在的价值和意义，不能轻易被去除或打破。
+
+但是，你我都知道，审批往往指的是由人进行审核和批准，既是一个全人工流程，又是一个信息流转类流程。那么如何打破它呢？同样，也有几种思路：
+
+<li>
+该审批流程是否确实需要，如果能够通过系统来保证，则可以去除；
+</li>
+<li>
+该审批流程是否可以从事前审批转化为事后审核；
+</li>
+<li>
+该审批流程是否可以被简化。
+</li>
+
+但是，每家公司的流程都不太一样，所以我的这几个思路并不一定是放诸四海而皆准，但我希望你可以借鉴，或者从中学习到一些新的思路，并结合你自己的情况进行合理调整。
+
+相对于组织文化和流程因素，架构是真正和技术相关的因素，也是我要和你重点分享的内容。
+
+## 架构因素
+
+技术架构对于持续交付来说，是万分重要的。如果遇到混乱的架构，那持续交付会处处受制，痛苦不堪。但与之前讨论的组织、文化和流程因素相比，架构的问题解决起来也会相对容易，因为凡是技术上的东西，都比较愿意接受优化，并且可以随着持续交付一起慢慢重构。
+
+影响持续交付的架构因素，主要有两大部分：系统架构和部署架构，接下来我会给你详细展开。
+
+**第一，系统架构**
+
+系统架构指系统的组成结构，它决定了系统的运行模式，层次结构，调用关系等。我们通常会遇到的系统架构包括：
+
+<li>
+单体架构，一个部署包，包含了应用所有功能；
+</li>
+<li>
+SOA架构，面向服务，通过服务间的接口和契约联系；
+</li>
+<li>
+微服务架构，按业务领域划分为独立的服务单元，可独立部署，松耦合。
+</li>
+
+那么，这些架构对持续交付又有什么影响和挑战呢？
+
+**对单体架构来说：**
+
+<li>
+整个应用使用一个代码仓库，在系统简单的情况下，因为管理简单，可以快速简单地做到持续集成；但是一旦系统复杂起来，仓库就会越变越大，开发团队也会越来越大，多团队维护一个代码仓库简直就是噩梦，会产生大量的冲突；而且持续集成的编译时间也会随着仓库变大而变长，团队再也承受不起一次编译几十分钟，结果最终失败的痛苦。
+</li>
+<li>
+应用变复杂后，测试需要全回归，因为不管多么小的功能变更，都会引起整个应用的重新编译和打包。即使在有高覆盖率的自动化测试的帮助下，测试所要花费的时间成本仍旧巨大，且错误成本昂贵。
+</li>
+<li>
+在应用比较小的情况下，可以做到单机部署，简单直接，这有利于持续交付；但是一旦应用复杂起来，每次部署的代价也变得越来越高，这和之前说的构建越来越慢是一个道理。而且部署代价高会直接影响生产稳定性。这显然不是持续交付想要的结果。
+</li>
+
+总而言之，一个你可以完全驾驭的单体架构应用，是最有容易做到持续交付的，但一旦它变得复杂起来，一切就都会失控。
+
+**对SOA架构来说：**
+
+<li>
+由于服务的拆分，使得应用的代码管理、构建、测试都变得更轻量，这有利于持续集成的实施。
+</li>
+<li>
+因为分布式的部署，使得测试环境的治理，测试部署变得非常复杂，这里就需要持续交付过程中考虑服务与服务间的依赖，环境的隔离等等。
+</li>
+<li>
+一些新技术和组件的引入，比如服务发现、配置中心、路由、网关等，使得持续交付过程中不得不去考虑这些中间件的适配。
+</li>
+
+总体来说，SOA架构要做到持续交付比单体架构要难得多。但也正因架构解耦造成的分散化开发问题，持续集成、持续交付能够在这样的架构下发挥更大的威力。
+
+**对微服务架构来说：**
+
+其实，微服务架构是一种SOA架构的演化，它给持续交付带来的影响和挑战也基本与SOA架构一致。
+
+当然，如果你采用容器技术来承载你的微服务架构，就另当别论了，这完全是一个持续交付全新的领域，这部分内容我将在后续文章中跟你分享。
+
+**第二，部署架构**
+
+**部署架构指的是，系统在各种环境下的部署方法，验收标准，编排次序等的集合。它将直接影响你持续交付的“最后一公里”。**
+
+**首先，你需要考虑，是否有统一的部署标准和方式。** 在各个环境，不同的设备上，应用的部署方式和标准应该都是一样的，可复用的；除了单个应用以外，最好能做到组织内所有应用的部署方式都是一样的。否则可以想象，每个应用在每个环境上都有不同的部署方式，都要进行持续交付的适配，成本是巨大的。
+
+**其次，需要考虑发布的编排次序。** 特别是在大集群、多机房的情况下。我们通常会采用金丝雀发布（之后讲到灰度发布时，我会详解这部分内容），或者滚动发布等灰度发布策略。那么就需要持续交付系统或平台能够支持这样的功能了。
+
+**再次，是markdown与markup机制。** 为了应用在部署时做到业务无损，我们需要有完善的服务拉入拉出机制来保证。否则每次持续交付都伴随着异常产生，肯定不是大家愿意见到的。
+
+**最后，是预热与自检。** 持续交付的目的是交付有效的软件。而有些软件在启动后需要处理加载缓存等预热过程，这些也是持续交付所要考虑的关键点，并不能粗暴启动后就认为交付完成了。同理，如何为应用建立统一的自检体系，也就自然成为持续交付的一项内容了。
+
+关于部署的问题，我也会在之后的篇章中和你详细的讨论。
+
+## 总结
+
+今天，我和你分享的主题是影响持续交付的因素，为了便于你理解，我将其划分为人（组织和文化），事（流程），物（架构）三个方面：
+
+<li>
+组织和文化，是最重要的因素，是持续交付推进的基础；
+</li>
+<li>
+流程因素，实施持续交付也是一次流程改造之旅；
+</li>
+<li>
+系统架构，与持续交付相互影响，但技术可以解决一切问题；部署架构，千万不要失败在“最后一公里”，这部分你也需要重点关注。
+</li>
+
+最后，也请你思考一下，如果你的组织实施持续交付，最大的影响因素会是什么？如果是系统架构方面的因素，你将如何应对？
+
+欢迎你给我留言。
+
+

极客时间专栏/geek/持续交付36讲/基本概念/03 | 持续交付和DevOps是一对好基友.md

@@ -0,0 +1,123 @@
+<audio id="audio" title="03 | 持续交付和DevOps是一对好基友" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/60/dc/608fe73f6a9d1844676412c4009079dc.mp3"></audio>
+
+现在很多人都在困惑持续交付和DevOps到底是什么关系，有什么区别，或许你也感觉傻傻分不清楚。那么今天，我就来和你聊聊持续交付和DevOps，以及它们到底是什么关系。
+
+## 持续交付是什么？
+
+我在专栏的第一篇文章中，已经跟你很详细地分享了持续交付是什么，为了加深你的印象，并与DevOps形成对比，我在这里再从另外一个角度给你总结一下：
+
+> 
+持续交付是，提升软件交付速率的一套工程方法和一系列最佳实践的集合。
+
+
+它的关注点可以概括为：持续集成构建、测试自动化和部署流水线。
+
+那么，DevOps又是什么呢？其实一直以来，学术界、工业界都对DevOps没有明确的定义，所以造成了大家对它的看法也是众说纷纭，也难免片面。
+
+在我给出我个人的认识之前，我先给你讲讲DevOps是怎么被发明的吧。
+
+## DevOps的诞生
+
+DevOps的故事，要从一个叫帕特里克 · 德博伊斯（Patrick Debois）的IT咨询师讲起。2007年，帕特里克参与了一个政府下属部门的大型数据中心迁移的项目。
+
+在这个项目中，帕特里克发现开发团队（Dev）和运维团队（Ops）的工作方式和思维方式有巨大的差异：
+
+- Dev的工作是，为软件增加新功能和修复缺陷，这要通过频繁的变更来达到；
+- Ops的工作是，保证系统的高稳定性和高性能，这代表着变更越少越不容易出错。
+
+因此，Dev和Ops长久以来，都处于对立和矛盾的状态。
+
+2009年6月23日，Flickr公司的运维部门经理约翰 · 阿斯帕尔瓦（John Allspaw）和工程师保罗 · 哈蒙德在Velocity 大会上做了一个轰动世界的演讲：《每天部署10次以上：Flickr公司的Dev与Ops的合作》（10+ Deploys Per Day: Dev and Ops Cooperation at Flickr）。
+
+这个演讲中提出了DevOps的核心观点：Dev和Ops的矛盾可以通过技术升级和文化构建来解决，这标志着DevOps的诞生。
+
+帕特里克也在网上看到了这个演讲，并且十分兴奋，因为这就是长久以来他所想解决的问题。于是，他开始筹备自己的 Velocity 大会。
+
+2009年10月，帕特里克的Velocity大会在比利时顺利召开，他把会议命名为DevOpsDays。他本来想用 DOD作为 DevOpsDays 的缩写，以提醒自己“死在交付上”（Dead On Delivery），但不知什么原因，他最后没有这么做。
+
+这届大会出人意料的成功，许多开发工程师和运维工程师参加了这次大会，甚至还有各种IT管理人员参加。人们开始在 Twitter上大量讨论DevOpsDays的内容。
+
+由于Twitter对内容长度的限制是140个字符，所以大家在Twitter上讨论时去掉了“Days”，只保留了 “DevOps”。**于是， DevOps这个名称正式诞生。**
+
+## 持续交付的姗姗来迟
+
+在DevOps的这段编年史里，持续交付又在哪里呢？
+
+2006 年，杰斯 · 亨布尔（Jez Humble），克里斯 · 里德（Chris Read）和丹 · 诺斯（Dan North）在 Agile 大会上发表了一篇名为《部署生产线》（Deployment Production Line）的文章，这也是第一篇描述持续部署核心内容的会议文章。
+
+在后面的三年里，又有一系列“持续部署”的文章被发表。2009年，这一些系列的文章被编成为了一本叫作《持续交付：发布可靠软件的系统方法》的书，这一年也正是帕特里克举办DevOpsDays的那一年。
+
+2010 年，《持续交付：发布可靠软件的系统方法》的作者之一杰斯参加了第二届的 DevOpsDays，并做了 关于“持续交付”的演讲，在这一年“DevOps”与“持续交付”终于有了交集。
+
+从本质上说，帕特里克最初遇到的问题，在《持续交付：发布可靠软件的系统方法》一书中找到了最佳实践。如果这本书可以早两年问世，或许今天就不会有DevOps了。
+
+然而，**DevOps 的概念一直在向外延伸，包括了：运营和用户，以及快速、良好、及时的反馈机制等内容，已经超出了“持续交付”本身所涵盖的范畴。而持续交付则一直被视作DevOps的核心实践之一被广泛谈及。**
+
+这么看来，持续交付真是打了一个大盹儿。
+
+## 认识 DevOps
+
+DevOps这几年一直在不断地演化，那么它到底是什么呢？
+
+**目前，人们对DevOps的看法，可以大致概括为DevOps是一组技术，一个职能、一种文化，和一种组织架构四种。**
+
+**第一，DevOps是一组技术，包括：自动化运维、持续交付、高频部署、Docker等内容。**
+
+但是，如果你仅仅将DevOps认为是一组技术的集合的话，就有一些片面。任何技术都是为了解决某些问题而被创造出来的。比如Docker，就是为了解决 DevOps 所提倡的“基础设施即代码”这个问题，而被创造出来的。
+
+从这个角度来看的话，DevOps的范畴应该远远大于一组技术了。
+
+其实，DevOps是一组技术这个观点，还是只站在了工程师角度去思考问题而得出的结论。虽然“DevOps”中“Dev”和“Ops”这两个角色都是工程师，但是其本质还是希望跳出工程师的惯性思维来看待问题。
+
+**第二，DevOps是一个职能，这也是我在各个场合最常听到的观点。**
+
+你的公司有没有或者正准备成立一个叫作DevOps的部门，并将这个部门的工程师命名为DevOps工程师？至少在各大招聘网站上，是随处可见这样的职位，而招聘要求往往就是：会Ops技能的Dev，或者会Dev技能的Ops；或者干脆叫全栈工程师。
+
+“DevOps是一个职能”这个观点，源于设施的日趋完善，云服务的流行，以及各类开源工具的广泛使用，使传统Ops的工作重心发生了变化，使企业产生了不再需要Ops的错觉。
+
+但这个观点也是错误的，原因就是忽略了Dev与Ops本质上是不同的，也就是他们掌握的技能是不同。
+
+虽然在DevOps看来，Dev和Ops的最终目标是一致的，都是为了快速向客户提供高质量的产品，但其达到目标的手段和方法是不一样的。比如，Ops 往往需要更多的在线处理问题的经验，而这未必是Dev所具备的。
+
+所以，简单地把DevOps看做是一个职能，是一个彻底错误的观点。
+
+**第三，DevOps是一种文化，推倒Dev与Ops之间的阻碍墙。**
+
+DevOps是通过充分的合作解决责任模糊、相互推诿的问题和矛盾。在著名的演讲《每天部署10次以上：Flickr公司的Dev与Ops的合作》 中，就明确的指出工具和文化是他们成功的原因。
+
+其实，DevOps通常想要告诉我们的是：什么行为是值得被鼓励的，而什么行为需要被惩罚。通过这样的方法，DevOps可以促使我们形成良好的做事习惯，也就是DevOps文化。
+
+所以，我们可以发现引入DevOps的组织，其实都是希望塑造这样的一种：信任、合作、沟通、学习、分享、共担等鼓励协作的文化。
+
+**第四，DevOps是一种组织架构，将Dev和Ops置于一个团队内，一同工作，同化目标，以达到 DevOps文化地彻底贯彻。**
+
+这看起来确实没有什么问题，而且敏捷团队往往都是这么去做的。但是，从另一方面来看，Ops作为公司的公共研发资源，往往与Dev的配比是不成比例。所以，虽然我们希望每一个敏捷团队都有Ops，但这可能是一种奢求。
+
+但是，敏捷团队也说了，不一定是要有一个专职Ops人员，只要有负担这个角色职责的成员存在即可。这当然也讲得通，但可能真正的执行效果就没有DevOps所设想的那么好了。
+
+所以，DevOps是一种组织架构，这种说法，也对也不对，主要视组织的具体情况而定。
+
+## 总结
+
+今天，我和你一起回顾了DevOps产生的历程。同时，也顺便带你回顾了一下爱打盹儿的持续交付。我希望通过这篇文章，你可以理清持续交付和DevOps的关系：
+
+<li>
+DevOps的本质其实是一种鼓励协作的研发文化；
+</li>
+<li>
+持续交付与 DevOps 所追求的最终目标是一致的，即快速向用户交付高质量的软件产品；
+</li>
+<li>
+DevOps的概念比持续交付更宽泛，是持续交付的继续延伸；
+</li>
+<li>
+持续交付更专注于技术与实践，是 DevOps 的工具及技术实现。
+</li>
+
+## 思考题
+
+DevOps大潮袭来，企业是不是真的就不需要Ops这个岗位了呢？
+
+欢迎你给我留言。
+
+