导言：
展望DevOps新世界

想象有这样的一个世界：产品经理、开发人员、QA人员、IT运维人员和信息安全人员互相帮助，齐心协力，整个公司的业绩蒸蒸日上。他们朝着一个共同的目标努力奋斗，建立出从产品计划直至功能上线的端到端的快速服务交付流水线（例如每天执行几十次、数百次甚至上千次代码部署），在系统稳定性、可靠性、可用性和安全性方面均达到了世界一流的水平。

在那里，跨职能团队严谨地验证他们的假设：哪些功能最能取悦用户并能促进企业目标的实现。他们不仅关心用户特性的实现，而且还积极地保障交付能够顺畅、频繁地通过整个交付价值链，同时，IT运维部门、其他内部或者外部客户的系统都不会出现任何混乱及中断。

在那里，QA人员、IT运维人员和信息安全人员也会共同投身于团队文化建设，致力于创造能使开发人员效率更高、产能更大的工作环境。通过将QA、IT运维和信息安全等方面的专业人员共同融入交付团队，来构建自动化的自助工具和平台，所有团队在日常工作中就能够随时利用他人的专业技能，而不用再依赖或等待其他团队。

在那里，小团队能够快速独立地开发、测试和部署代码，并且可以快速、安全、可靠地向客户交付价值。同时，公司能够有效地提高开发人员的生产力，建立学习型公司，提高员工满意度，并在市场竞争中取胜。

这就是DevOps产生的效果。但是，对于我们大多数人来说，这并不是我们所处的现实世界。在现实中，系统经常被破坏，服务和产品总是不尽如人意，团队的潜力无法得到正常发挥；在现实中，开发和IT运维是对立的，测试和信息安全活动总是在项目晚期才进行，这导致即使发现了问题也来不及修复；在现实中，产品和服务交付中的关键活动往往全都需要手动操作和互相交接，我们总是要等待其他人的工作完成才能进行自己的工作；在现实中，特性交付的周期一次次被拖延，质量也频频出现问题，特别是与生产环境部署相关的部分，进而对客户和业务造成了负面影响。

结果，不仅是我们的工作无法按预期完成，整个公司也对IT部门的业绩不满意，甚至导致预算被削减，IT员工没有成就感，感觉无力改变流程及其结果 。怎么办？我们需要改变工作方式，没错，DevOps能够给我们指引方向。

为了更好地理解DevOps革命的潜力，首先让我们来回顾一下20世纪80年代的制造业革命。通过采用精益原则和实践，很多制造厂不但大幅提高了生产效率，缩短了交货周期，而且还提高了产品质量及客户满意度，并在市场竞争中立于不败之地。

在制造业革命前，制造厂的平均交货周期为6周，能按时交货的订单不到总量的70%。随着精益实践的广泛实施，到2005年，产品的平均交货周期缩短到3周以下，按时交货的订单超过总量的95%。而那些没有实施精益实践的厂商，不但渐渐失去了市场，有的甚至破产了。

另一方面，技术产品和服务的交付标准也在不断提高——几十年前优秀的交付标准如今已然过时。过去的40年中，开发和部署战略型业务功能所需的成本和时间每十年就下降几个数量级。在20世纪七八十年代，新功能大都需要1～5年的开发和部署周期，动辄花费数千万美元。

到21世纪初，由于技术的快速发展以及敏捷原则和实践的应用，新功能开发所需的时间已经从几年缩短至几个月，但是部署到生产环境仍然需要几周甚至数月，而且部署过程中还总是伴随着大量不可预知的状况。

到2010年，随着DevOps的出现，以及硬件、软件和公有云的不断商品化，任何特性（甚至整个公司的创建）都可以在几个星期内完成，并在几小时或几分钟内部署到生产环境中——对于这些公司而言，部署最终进化成了日常的、低风险的工作（见表0-1）。通过运用DevOps，这些公司能够通过测试商业理念发现对客户和整个公司而言最有价值的想法，然后实施开发，并快速且安全地将其部署到生产环境中。

现在，大部分采用了DevOps原则和实践的公司，每天都能完成几百甚至上千次代码部署的变更。在这个竞争优势需要被快速验证和持续实验的时代，那些还不能应用DevOps实践的公司注定会在市场上败给敏捷的竞争对手，并可能会倒闭，和当年那些没有采取精益原则和实践的制造厂的下场类似。

今天，不管我们身处什么行业，想要获取客户并向客户交付价值的方式都要依赖于技术价值流。正如通用电气公司首席执行官伊梅尔特所说：“没有将软件作为核心业务的每一个行业或公司都会受到影响。”微软技术院士Jeffrey Snover也曾说过：“在过去的经济时代，企业通过移动原子创造价值。而现在，他们必须通过数字创造价值。”

这个问题的严重性毋庸置疑——当今的技术影响着所有的企业，不论其行业、规模和盈利性质如何。与以往相比，技术工作的管理和有效执行，预示着企业能否在市场上取得优势，甚至能否生存下去。因此，尝试和采取一些新的原则和方法势在必行，虽然有些方法可能和过去几十年里曾指导我们成功的做法截然不同（见附录1）。

我们现在已经明确了DevOps解决问题的重要性和紧迫性。接下来要花一些时间来详细探索问题的本质：这些问题为什么会发生？若不采取措施干预的话，随着时间的推移，这些问题为什么会更加严重？

问题：在你的公司中有些事情必须改进（否则你不会来翻这本书）

大多数公司都不能在几分钟或几小时内完成变更需要的所有部署，往往需要几周甚至几个月的时间。他们更不可能每天在生产环境中做到成百上千次的部署，而是在以月甚至以季度为单位进行部署。对他们而言，生产环境的部署并不是日常工作，因此服务中断和各种事故总是与部署如影随形，“填坑侠”们总是前赴后继。

目前，快速地切入市场、提供优质的服务以及持续的创新就是一种竞争实力，而上述公司显然会在这样的竞争中处于劣势。这很大程度上要归咎于技术团队无法解决根本的、长期的冲突。

根本的、长期的冲突

在几乎所有的IT公司中，开发部门和IT运维部门之间都存在一种固有冲突，这会让公司业绩下滑，进而导致新产品和新功能的上市时间拉长、质量下降、服务中断时间增加，甚至导致技术债务量与日俱增。

“技术债务”这个术语是Ward Cunningham首次提出的。类似于金融债务，技术债务是指我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。即使我们审慎地承担技术债务，也依然会产生利息。

开发部门和IT运维部门的目标是对立的，这通常是产生技术债务的一个因素。IT公司需要负责的事情很多，其中包括下面两个必须实现的目标：

对变化莫测的市场做出反应；

为客户提供稳定、可靠和安全的服务。

开发部门通常负责对市场变化做出响应，以最快的速度将新功能或者变更上线。而IT运维部门则要以为客户提供稳定、可靠和安全的IT服务为已任，让任何人都很难甚至无法引入可能会危害生产环境的变更。这种配置方式让开发部门和IT运维部门的目标和动因之间存在巨大的冲突。

制造业管理运动的发起者之一Eliyahu M. Goldratt博士称这种配置为“根本的、长期的冲突”——公司对不同部门的考核和激励不同，阻碍了公司全局目标的实现。

这种冲突造成了一种恶性循环，阻碍了业务目标的实现，不但波及IT公司的内部，而且还会影响外部。这些长期冲突常常导致技术工作者交付出质量低劣的软件和服务，打造出糟糕的客户体验，每天都要采用临时解决方案、应对紧急情况。以上情景在产品管理、产品开发、QA、IT运维和信息安全管理中不断上演（见附录2）。

恶性循环三部曲

大多数的IT从业者可能都对恶性循环三部曲很熟悉。

第一部曲开始于IT运维，我们的目标是让应用程序和基础设施持续运行，以便公司向客户交付价值。我们日常工作中的很多问题源于应用程序和基础设施过于复杂、异常脆弱、文档不完备。这就是我们背负的技术债务，这就是我们每天所处的工作环境。我们总是承诺，一有时间，我们一定会处理这个烂摊子，但是这个时刻永远都不会到来。

更令人担忧的是，我们最脆弱的组件正支撑着最重要的业务系统或者最关键的项目。换句话说，那个最容易发生故障的系统就是我们最重要的系统，也是所有紧急变更的中心。当这些变更失败的时候，那些最重要的公司承诺，例如客户服务可用性、营收目标、客户数据的安全性和财务报告的精确性等，就会直接受到危害。

第二部曲始于有人必须去弥补最近未兑现的承诺——这可能是某个产品经理承诺了一个更大规模、更大胆的吸引客户的功能，或者是业务主管设置了一个更高的收益目标。然而，他们无视技术能实现什么不能实现什么，以及到底为何没能兑现之前的承诺，而是让技术组织按照新的承诺交付成果。

结果，开发团队被指派去做另一个紧急项目，这个项目必然需要解决新的技术难题，需要利用各种捷径以赶上承诺的发布日期，而这又导致了技术债务的增加——此时我们又承诺一有时间就处理这次产生的所有问题。

在这样的背景下，我们进入了第三部曲，也就是最后一部曲。在这里，所有事情都变得更加困难——所有人都越来越忙，工作所消耗的时间越来越多，沟通变得更加缓慢，工作积压得越来越多。我们的工作耦合得更加紧密，即使是很小的行动也会导致较大的事故，我们更加害怕和拒

绝做出变更。工作需要更多的沟通、协调和审批；团队必须等待更长的时间，等待相关的工作完成；我们的工作质量持续恶化。车轮开始嘎嘎作响地缓慢移动，要想使之继续转动，就需要付出更多的努力（见附录3）。

尽管当我们身处其中时很难察觉到，但是当你退后一步，就会发现这个恶性循环是显而易见的。你会注意到产品代码部署消耗的时间更长了，从几分钟到几个小时，再到几天或者几周。更糟的是，部署的效果越来越差，这导致客户服务中断的次数越来越多，需要运维部门来救急，而他们也因此无法偿还技术债务。

结果，我们的产品交付周期越来越长，做的项目越来越少，项目目标也越来越小。而且，对所有人工作（尤其是对来自客户的反馈信号）的反馈越来越慢，且越来越弱。不管我们做出怎样的尝试，事情似乎总是变得越来越糟糕——面对日新月异的市场竞争，我们不再能够快速响应，也无法为客户提供稳定、可靠的服务。我们最终因此失去了市场。

我们反复地看到，一个IT做得失败的公司，整个公司也都是失败的。正如Steven J. Spear在 The High-Velocity Edge 一书中指出的，无论破坏“像消耗性疾病一样慢慢地发展”还是迅速得“像大火焚毁般……其毁灭性都是一样彻底”。

为什么恶性循环无处不在

十多年以来，本书作者发现这种破坏性的恶性循环发生在各种类型、各种规模的公司里。这让我们更好地理解了发生这种恶性循环的原因，以及为什么需要用DevOps的原则去缓解这种状况。首先，如前所述，每个IT公司都有两个对立的目标；其次，每家公司都是一个科技公司，不论他们自己是否意识到。

正如软件开发高管和早期的DevOps记录者之一Christopher Little所说：“每个公司都是科技公司，无论他们认为自己处在哪个行业。银行也只是拥有银行执照的IT公司而已。”

要说服自己这是事实，考虑一下，绝大多数投资项目都在某种程度上依赖于信息技术。俗话说：“想要做出一个不会带来任何IT变更的商业决策几乎不可能。”

在业务和财务方面，项目都是至关重要的，因为它们是企业内变革的主要机制。项目通常都需要管理层来审批、做预算和负责，因此，它们是实现企业目标和愿景的机制，无论是成长还是萎缩。

项目通常是通过资本投入（即厂房、设备和重大项目，当预计要数年以后才有回报时，支出就资本化了）来供给资金的，其中50%是和技术相关的。即便是技术支出最低的“低科技”行业，

诸如能源、冶金、资源开采、汽车和建筑行业也是如此。换句话说，企业领导者想要实现业务目标，对有效IT管理的依赖程度远远超出了他们的预想。

成本：人和经济

困于这种恶性循环中多年，特别是那些处于开发下游的人，经常感觉被困在一个注定失败的系统中，无力改变结果。伴随这种无力感的是倦怠感，还有疲劳、愤世嫉俗，甚至是无助和绝望。

许多心理学家认为，创建一个让人感觉无能为力的系统，是我们能对人类同胞做的最具破坏性的一件事——我们剥夺了他人控制自己成果的能力，甚至营造了一种文化，让人们因为害怕遭受惩罚、失败或危及生存而不敢做正确的事。这创造了“习得性无助”的环境，人们变得不愿或无法采取行动来避免未来遇到同样的问题。

对于我们的员工而言，这意味着长时间工作、周末加班、生活质量下降，而且影响的不仅仅是员工，还有所有依赖他们的人，包括他们的家人和朋友。当这种情况发生时，我们失去最好的员工（除了那些因为责任感和义务而觉得不能离开的人）也就不足为奇了。

除了人们在当前这种工作方式中受煎熬之外，我们能创造的价值的机会成本更令人震惊——作者认为，我们每年错失创造约2.6万亿美元价值的机会，在撰写本书时，那相当于世界上第六大经济体法国的年经济总产值。

考虑下面的估算——IDC和高德纳公司都估计，2011年，约5%的全球GDP（即3.1万亿美元）用于IT（含硬件、服务和电信）。如果我们估计这3.1万亿美元中的50%用于运营成本和维护现有系统，而且这50%的三分之一用于紧急和计划外工作或返工，也就是说大约5200亿美元被浪费了。

如果采用DevOps能使我们用更好的管理和卓越的运营减少一半的浪费，并且可以重新部署员工，让他们去做能产生5倍价值的事（不算很高），我们每年就能够创造2.6万亿美元的价值。

DevOps的准则：总有更好的方法

前面描述了根本的、长期的冲突带来的问题和负面影响，从无法实现公司目标，到对人类同胞造成的损害。通过解决这些问题，DevOps能够提高公司业绩，实现开发、QA、IT运维、信息安全等各职能技术角色的目标，同时改善人们的境遇。

这个令人振奋的罕见组合可以解释为什么DevOps在这么短的时间内激发出了这么大的兴奋和热情，包括技术领导、工程师，以及我们所处的软件生态系统的大部分。

用DevOps打破恶性循环

理想情况下，小团队的开发人员独立地实现自己的功能，在类生产环境中验证其正确性，再把代码快速、安全、可靠地部署到生产环境里。代码部署是日常的且可预测的工作。部署工作不是选在周五的午夜开始、鏖战整个周末才完成，而是在每个人都在办公室的工作日进行，大多数时候甚至不会引起客户的注意（客户兴奋地看到出现了新功能或者旧缺陷被修复了的情况除外）。由于代码部署是在工作时间段内进行的，几十年来，IT运维人员第一次可以像其他人一样在正常工作时间段工作了。

通过在流程中的每一个步骤创建快速反馈回路，每个人都可以立即看到工作效果。只要代码变更提交到了版本控制系统，就会在类生产环境中运行快速的自动测试，这持续地保证了代码和环境符合设计预期，并且总是处在安全的可部署状态。

自动化测试可以帮助开发人员快速发现错误（通常在几分钟之内），实现更快速的修复以及真正的学习。如果错误是在6个月后的集成测试中发现的，那时相关的记忆和因果关系早已消退，想从中学习是不可能的。自动化测试使技术债务不再积累，问题在发现之后就立即被修复了。如果需要，这还可以调动整个公司参与问题的处理，因为总体目标高于局部目标。

在我们的代码和生产环境中无处不在的遥测技术，保证了问题能被迅速地发现并纠正，确保一切都能按照预定的方式进行，并且客户能从我们创造的软件中获得价值。

在这样的场景下，每个人都感觉富有成效——这种架构使得小团队能够安全地工作，同时在架构上和其他团队的工作解耦，这些团队使用了集运维和信息安全最佳实践于一体的自服务平台。团队独立、高效地处理小批量工作，快速且频繁地为客户提供新的价值，而不是每个人都在等待，面对大量迟来和紧急的返工。

通过黑启动（dark launch）技术，即便是复杂的产品和功能发布，也变得稀松平常了。早在发布日期以前，我们就已经将所有功能的代码部署到了生产环境中，它只对内部员工和部分真实用户可见。这使得我们能够测试和改进其功能，直到达到预期的业务目标。

想要让新功能生效，我们只需要改变一个功能开关或者配置项即可，而不再需要经历数天或者数周的辛苦工作。这个小变更使新功能对更大规模的客户群可见，一旦出现错误，就会自动地回滚。因此，发布新功能变得可控、可预测、可逆，且压力也小了。

除了新功能的发布变得更加顺利外，各种问题都能在其规模小、修复容易且成本低的时候发现并修复。通过每次的问题修复，我们也让公司得到了经验和教训，能够防止问题复发，并且能在未来更快地定位和修复相似的问题。

此外，每个人都在不断地学习，从而营造出了一种假设驱动的文化，用科学的方法保证一切都得到了充分的验证——在对产品开发和流程改进进行有目的的衡量和实验之前不做任何工作。

因为我们珍惜大家的时间，所以不会花几年的时间去打造客户不想要的功能，不会部署根本就不能用的代码，也不会修复非问题根源的缺陷。

由于我们关心目标的实现，所以建立了长期的团队责任制，负责目标的实现。在一般的项目团队中，每次软件发布以后开发人员就被打散并重新分配了，他们没有机会得到自己工作的反馈；我们则保持团队的完整性，这样团队可以进行迭代和改进，用团队各成员所学到的经验来更好地实现目标。对于给外部客户解决问题的产品团队，以及帮助其他团队提高生产力、可靠性和安全性的内部平台团队来说，这一点同样重要。

我们的团队文化体现了高度的信任与合作，而不是指责，人们会因为冒险而获得回报。他们可以无所畏惧地讨论问题，而不是把问题隐藏起来或者往后拖延——毕竟，我们只有先认识到了问题，才能解决问题。

而且，因为所有人都需要对自己的工作质量负完全的责任，所以每个人在日常的工作中都创建自动化测试，并且使用同行评审的方式来保证在问题影响到客户之前就解决它。与从管理层向下授权审批的方式相反，上述过程降低了风险，让我们能快速、可靠、安全地交付价值，甚至可以在挑剔的评审人员面前证明我们拥有一个高效的内部控制系统。

在出现问题时，我们进行 不指责的事后分析 ，这并不是要惩罚某人，而是为了更好地理解导致事故的原因，以及如何防止事故再次发生。这个方法强化了我们的学习文化。我们还通过举办内部技术研讨会来提高技能，保证所有人不是在教就是在学。

因为注重质量，所以我们甚至会故意在生产环境中注入故障，从而了解系统是怎样以预期方式发生故障的。我们按照计划做大规模的故障演练，随机结束生产环境中的进程，中断正在运行的服务器，同时还注入网络延迟以及其他恶意因素，以此来确保系统的可靠性。这样的方式为我们的系统带来了更高的可靠性，同时为整个公司提供了更好的学习和提高机会。

在这个世界里，不论处于科技公司的哪个岗位，每个人都是自己工作的主人。他们坚信自己的工作很重要，并为公司的目标出了一份力，低压力的工作环境以及公司在市场上的成功足以证明这一切。公司在市场上取得的业绩就是最好的证据。

DevOps的业务价值

对于DevOps的业务价值，我们有确凿的证据。从2013年到2016年，在Puppet Labs的年度DevOps现状报告中（本书作者Jez Humble和Gene Kim为报告做出了贡献），我们对25 000多名技术专家进行了数据收集，目的是更好地了解企业应用DevOps不同阶段的运维状况和习惯。

这份数据第一个让人震惊的地方就是，应用了DevOps的高绩效公司在以下方面的表现远超低绩效同行：

吞吐量指标；

代码和变更部署次数（频繁30倍）；

代码和变更部署前置时间（快200倍）；

可靠性指标；

生产环境部署（变更成功率高60倍）；

平均服务恢复时间（快168倍）；

组织性能指标；

生产力、市场份额以及营业目标（大约2倍以上）；

市值增长（3年内高出50%）。

换句话说，高绩效者要更加敏捷和可靠，这证明DevOps能够打破根本的、长期的冲突。高绩效者部署代码的频率要高出30多倍，从“代码提交”到“在生产环境中顺利运行”的速度要快200倍——高绩效者的交付周期是以分钟或小时来计量的，而低绩效者的交付周期则以周、月甚至季度来计量。

此外，高绩效者有两倍的利润率、市场份额、生产率目标。而且，对于那些已经上市的企业，我们发现高绩效者在3年内的股票市值增长率高出50%。他们的员工满意度高，员工倦怠程度低，把公司推荐给朋友的可能性要高出2.2倍。 高绩效者信息安全成果也更好。通过将安全目标集成到开发和运维流程的所有阶段，他们用在安全问题修复上的时间减少了50%。

DevOps有助于提高开发人员的生产力

当我们增加开发人员的数量时，由于沟通、集成以及测试开销，单个开发人员的生产力通常会显著下降。Frederick Brooks在其著名的《人月神话》一书中强调过这一点。他解释说，当项目延迟时，增加更多的开发人员不仅降低了单个开发人员的生产力，而且也降低了整体的生产力。

另一方面，DevOps证明了在拥有正确的架构、技术实践和文化规范的情况下，小型开发团队能够快速、安全、独立地开发、集成、测试和部署变更到生产环境。前谷歌工程总监Randy Shoup发现，使用DevOps的大型企业“拥有数千名开发人员，但小团队依然能受益于他们的组织架构和实践，具有像创业公司一般惊人的生产力”。

《2015年DevOps现状报告》不仅调查了“每天的部署次数”，还调查了“每天每个开发人员的部署次数”。我们假设高绩效公司可以随着团队人员数量的增长而增加部署次数。

这就是我们的发现。图0-1展示了在团队人数增加时，低绩效公司每个开发人员每天的部署次数在降低，中等绩效公司维持不变，而高绩效公司则线性增加。

换句话说，在应用了DevOps的企业中，在开发人员数量增加时，每天的部署次数呈线性增加趋势；谷歌、亚马逊以及Netflix已经做到了。

解决方案的通用性

精益制造运动中最有影响力的图书之一是1984年由Eliyahu M. Goldratt博士写的《目标：简单而有效的常识管理》。它影响了世界各地整整一代的专业的工厂经理。这是一本关于工厂经理的小说，书中的主人公必须在90天内解决成本和产品交货时间的问题，否则他的工厂将被关闭。

在他的职业生涯后期，Goldratt博士提到了《目标》的读者反馈信件。这些信件通常写道：“显然你曾经在我们工厂待过，因为你准确地描述了我作为工厂经理的生活……”最重要的是，这些信件表明，人们能够在自己的工作环境中重现书中描述的业绩突破。

Gene Kim、Kevin Behr以及George Spafford在2013年所著的《凤凰项目：一个IT运维的传奇故事》在很大程度上借鉴了《目标》的写法。这本小说的主人公是一位IT部门经理，他面对IT公司所特有的全部典型问题：项目预算超支，进度一再拖延，为了公司的存亡不得不上线。他经历了灾难般的部署，也面对过可用性、安全性、合规性等方面的问题。最终，他和他的团队采

用DevOps的原则和实践战胜了以上困难，帮助公司赢得了市场。此外，该小说展示了DevOps实践如何改善团队工作环境，让员工参与整个过程，进而减轻了压力并提高了满意度。

和《目标》相同，《凤凰项目》所描述的问题和解决方案很普遍。看看亚马逊上对该书的部分评价：“我发现自己与《凤凰项目》的人物有共鸣……我在职业生涯中可能遇到过其中的大部分人。”“如果你曾从事IT、DevOps或信息安全等方面的工作，一定感同身受。”“我能将《凤凰项目》中的所有人物与自己或者现实生活中所认识的人对应起来……更不要说那些人物面临和克服的问题了。”

在本书的余下部分里，我们将介绍如何复制《凤凰项目》中所描述的转型，并提供丰富的案例研究，展示其他公司是如何应用DevOps原则和实践来取得这些成果的。

阅读指南

本书的目标是向你提供从启动DevOps转型到实现目标成果所必需的理论、原则和实践。这本指南基于几十年优秀的管理理论、对高绩效科技组织的研究、我们帮助企业实现DevOps转型所做的工作、验证本书中DevOps实践的有效性的研究、对相关领域专家的访谈，以及对“DevOps企业峰会”所分享的近100个案例的分析。

本书分为6个部分，使用“三步工作法”涵盖了DevOps理论及原则。“三步工作法”是《凤凰项目》一书中提出的，是看待基础理论的一种视角。本书不仅适用于从事或影响技术价值流（通常包括产品管理、开发、QA、IT运维和信息安全）中工作的所有人，而且也适用于业务和市场领导者，大部分技术计划都源自他们。

读者并不需要具备这些领域的丰富知识，也不需要对DevOps、敏捷、ITIL、精益或流程优化有全面的认识，因为这些主题会在书中需要的地方予以介绍。

我们的目的是建立起各个领域中核心概念的应用知识，并以此为基础来引入其他必要的内容，从而帮助实践者与所有同事在整个IT价值流中一起工作，并建立共享的目标。

本书对业务领导者和越来越依赖技术组织去实现目标的利益相关者而言将很有价值。

此外，本书也适合所在公司不存在本书中描述的所有问题（例如，部署周期长或部署过程痛苦）的人。这些幸运的读者也将因理解DevOps的原则而受益，特别是那些关于共同目标、反馈和持续学习的原则。

在第一部分中，我们将简要介绍DevOps的历史，并介绍几十年来相关知识体系的理论基础和关键主题，然后概要地介绍“三步工作法”的原则：流动、反馈和持续学习与实验。

第二部分将描述怎样开始以及从哪里开始，并介绍各种概念，如价值流、组织设计原则与模式、组织导入模式和案例研究。

第三部分将介绍如何通过构建部署流水线的基础来加速流动：实现快速有效的自动化测试、持续集成、持续交付和为低风险发布做架构。

第四部分将讨论如何通过建立有效的生产环境遥测来发现和解决问题，从而加速和增强反馈，更好地预测问题和实现目标，获得反馈以便开发人员和运维人员可以安全地部署变更，将A/B测试集成到日常工作中，以及创建审查和协调流程来提高我们的工作质量。

第五部分将描述如何通过建立公正的文化，将本地发现转化为全局性改进，预留出一定的时间来进行组织学习和提高，从而加速持续学习。

最后，第六部分将介绍如何通过把预防性安全控制集成到共享源代码库和服务中，将安全性集成到部署流程中，增强遥测以实现更好的检测和恢复，保护部署流水线，以及实现变更管理目标，从而将安全性和合规性正确集成到日常工作中。

通过整理这些实践，我们希望加速DevOps实践的导入和应用，提高DevOps计划的成功率，并降低激活DevOps转型所需的能量。 0ANeOtXlxHD37EnVKvfeAi6gE08XkH4ZuKKb8Wgcwk8bBGA0qiNF5D65zQHqO72A