盐析白兔

这个屌丝很懒，什么也没留下！

热门标签

DevOps 实践指南

作者：盐析白兔 | 2024-02-25 03:40:54

踩

devops is the human factor

内容简介

技术的有效管理对于商业竞争力而言空前重要。数十年来，技术领导者一直在努力平衡敏捷性、可靠性和安全性。在此背景下，本书旨在提供从启动 DevOps 转型到实现目标所需的理论、原则和实践，帮助企业提高生产力、盈利能力并且赢得市场。本书不仅适用于从事或影响技术价值流中工作的所有人，通常包括产品管理、开发、QA、IT 运维和信息安全，而且适用于业务和市场领导者。

本书共分为6个部分：第一部分概述 DevOps 的历史和三个基本原则，即“三步工作法”；第二部分介绍开启 DevOps 转型的过程；第三到五部分深入探讨“三步工作法”的各个要素；第六部分关注如何将安全性和合规性正确集成到日常工作中。全书涵盖40余个 DevOps 案例，以谷歌、亚马逊、Facebook 等全球知名企业和组织的实际调查结果为依据，展示如何通过现代化的运维管理提升管理效率，进而为企业赢得更大市场、创造更多利润。

作者简介

Gene Kim，Tripwire 创始人、前 CTO，IT Revolution 创始人，DevOps 企业峰会主办人，畅销书《凤凰项目》合著者。

Jez Humble，DevOps Research and Assessment 公司 CTO，加州大学伯克利分校信息学院讲师；曾任 ThoughtWorks 首席顾问。《精益企业》和 Jolt 大奖图书《持续交付》的合著者。

Patrick Debois，DevOps 之父，致力于通过在开发、项目管理和系统管理之中应用敏捷技术来填补项目和运维之间的鸿沟。

John Willis，Chain Bridge System 创始人，曾任 Docker 公司布道师，现就职于 SJ Technologies 公司。

本书内容

译者序

在十几年的工作经历中，我见证了国内企业数据中心建设和发展的过程。大型企业的数据中心拥有几千台服务器和网络设备，拥有全套的监管控平台。当踱步于轰鸣的机架丛林里时，当与夜间奋战的变更团队一起凝视着命令执行出错的屏幕时，我们可以清晰地感受到 IT 运维组织里那种特有的恐惧感和紧张感。

这一切是不是都应该去埋怨墙另一侧的开发团队呢？在平日里，应用系统是被圈养的宠物；而在发生事故的那一刹那，它就变身为一头难以驯服的猛兽。从 IT 组织整体来看，当前运维人员的痛是深刻而明显的！而开发人员同样是深受夜班出租车司机喜爱的人群。相对于运维团队而言，他们的精神世界和现实世界要更加美好一些。开发团队实施了很多年的敏捷软件开发，有着自己的关于完成的定义。即使你现在去翻阅一本最新出版的 Scrum 敏捷开发指南，翻到关于完成的定义的章节时，还是可以看到类似这样的定义：“冲刺的目标是要产生一个潜在可发布的产品增量，达到大家一致认可的完成程度。”我对这样的定义感到非常忧虑：它能意味着每个冲刺的开发结果可以正常地运行在类生产环境中吗？能意味着可以按照业务人员的需要马上开展小范围的真实用户实验吗？运维人员能否在系统濒临崩溃之前自行关闭这个功能？

可以肯定的是，现在开发和运维还不能在统一的、为客户交付价值的目标下工作，他们像是生活在不同的星球上。这个问题并不是我国特有的。回顾一下从2009年开始的 DevOps 运动吧！这是一次能让开发和运维感到同样兴奋的技术实践变革，其中也充满了人文变迁。

我在不停地思索，应该怎样破解以上困境。在研究 DevOps 相关技术实践一段时间之后，各种答案终于陆续浮现。我很幸运地接受了本书的翻译工作。对我来说，这是一次深度的 DevOps 学习研究之旅，组织几个好友共同经历这个过程也非常难得。现在可以确定的是，DevOps 的理论、原则和实践就一条“更好的道路”，就是我们需要的答案；它能让开发和运维深度地融合为同一支“球队”，使他们朝着“进球”这一共同目标协同努力，而不再是彼此对抗和怀疑。它将测试和信息安全工作一同融入了这个统一的框架当中，将保障质量和安全变为每个人日常工作的一部分。本书用 DevOps“三步工作法”的形式展示了所有相关细节。它适用于 IT 组织里所有的级别和角色，值得任何拥有改进想法的人深入学习。

本书对开发和运维具有同样重要的意义，而且覆盖了传统的 QA 测试和信息安全工作；它是传统的敏捷开发、精益管理和 ITSM 管理等实践各自发展多年以后的首次 IT 管理实践大融合。本书和 DevOps 本身应该得到更广泛的应用和推广。本书的出版离不开翻译团队和图灵编辑团队的专业精神，以及双方的共同努力。在此我统一向所有合作者表示感谢。

此外，谨以此书献给我的妻子丽娜和女儿禹含，感谢她们在这13个月时光里的支持。特别让我欣慰的是，女儿不仅明白什么是图书翻译，而且在网络英语课上有很棒的表现，也感谢她能容忍我因此而减少了与她陪伴和玩耍的时间。

刘征

2018年2月14日（丁酉年腊月二十九）

2016年9月的一个周末，当时我正在参加 EXIN 举办的 DevOps Master Trainer 的培训，刘征向我推荐了这本书，并邀请我共同完成中文版的翻译工作。出于对 Gene Kim 的《凤凰项目》一书的喜爱，对能够参与本书的翻译工作，我非常期待。

一周后，当我第一次阅读本书的预览章节时，顿时被其中的内容所吸引。本书不仅将敏捷、精益和持续交付等理念的诠释上升到一个新的高度，而且剖析了在这个安全漏洞频发、交付周期不断缩短、技术大规模转型的时代，当技术领导者们面对安全性、可靠性和灵活性等诸多挑战时，为什么 DevOps 能够脱颖而出——它帮助组织缩短价值交付流程，打造高可靠性、高安全性的产品，并提高了企业竞争力和员工满意度。

本书从业务视角描述了 DevOps 的必要性，分析了为什么 DevOps 是基于精益、约束理论、丰田生产系统、学习型组织、康威定律等知识体系的集大成者。同时，它系统性地定义了 DevOps“三步工作法”：流动原则、反馈原则、持续学习与实验原则，并阐述了 DevOps 实施需遵守的原则与最佳实践。

流动原则：它加速了从开发、运维到交付给客户的正向流程。
反馈原则：它使组织构建安全、可靠的工作体系，并获得反馈。
持续学习与实验原则：它打造出一种高度信任的文化，并将改进和创新融入日常工作中。

DevOps 对技术行业带来的变化，就如同精益在20世纪80年代对制造业的变革一样。那些拥抱 DevOps 的组织将构建出充满激情、持续进步的学习型组织，并能通过创新的方式表现得比竞争对手更加出色。在本书中，作者引入了大量的业界成功案例，包括谷歌、Etsy、塔吉特、LinkedIn 等一流的互联网公司，描述了他们在 DevOps 转型过程中面临的挑战以及应对方式，指引读者站在巨人的肩膀上思考。

DevOps 使价值流里的所有参与者都受益匪浅。无论你是开发人员、运维工程师、质量保证工程师、信息安全人员还是产品经理，它都能够带来开发伟大产品而产生的快感。它能使团队共同成长并持续获益。相信读过本书之后，你一定会产生强烈的共鸣。

感谢我的妻子晓丽和儿子锦熙，翻译本书占用了我大量业余时间，没有你们的支持，我不可能完成这项工作。感谢本书的其他几位译者——刘征、马博文、曾朝京，和你们的合作让我获益良多，也感谢图灵负责本书审校工作的编辑们，你们逐字逐句的检查、校对和修改提高了译文的质量，谢谢你们！

最后，祝读者们享受 DevOps 的实践之旅！

王磊

2018年2月20日

2011～2017年，我一直在为 ThoughtWorks 的一个海外交付项目工作。我们和客户一起，从持续集成、两周一次部署，做到了持续交付、随时部署，同时应用架构微服务化，也实现了上云以及容器化部署。

在这个过程当中，我们切实地采用和执行了业界的良好技术和工程实践，如微服务、蓝绿部署、不可变部署、基础设施即代码等。我也曾经阅读和翻译过 DevOps 的相关图书，但总觉得还是和我们的实践有点差距。

在这段时间中，我的角色也从开发者变为 DevOps（我个人不太喜欢这个称呼，因为我认为 DevOps 更多的是实践而不是角色）。同时，我组织了西安 DevOpsMeetup 的活动，期望能通过社区分享更多关于 DevOps 的知识。每次活动时，总是有朋友问如何实现 DevOps，我却发现即便亲身经历了这个过程，也无法给出更高层面的回答，而且也没有在别的文章和书籍中找到答案。

很幸运，因为社区活动而结识的刘征向我发出了翻译本书的邀请。在翻译的过程当中，我找到了如何系统性实现 DevOps 的答案。通过“三步工作法”铺平流程，选择合适的切入点，根据康威定律调整组织、持续交付、自动化、运维改善等。对于尚未实现 DevOps 的 IT 组织来说，这是一本不可多得的指南。

翻译本书，收获颇多。本书的作者 Patrick、Gene、Jez 和 John 确实贡献了一本集 DevOps 大成的著作。希望读者在阅读后也会有相同的感受，能够在团队中逐渐采用本书提供的工作法或者实践，改进交付速度、质量、软件可用性以及构建高可扩展的组织结构。

翻译是一件费时费力的工作。感谢我的妻子王嘉，能包容我放弃陪她的时间来完成这一项工作。感谢一起合作的几位译者——刘征、王磊、曾朝京，和你们一起合作非常愉快。感谢 Trent、Cos 等 REA 的朋友，是你们带我走上了 DevOps 之路。最后，祝各位读者在阅读完本书后，都能找到实践 DevOps 的方法，并且行动起来，开启 DevOps 的探险之旅并持续从中受益。

马博文

2018年3月4日

2012年，我第一次在公司的年度全球会议上接触到 Dev+Ops 的概念。那时候，IT 服务管理的理念在国内 IT 运维领域已经深入人心，保障生产系统的可靠性和安全性仅仅是运维工作的基本内容，许多企业的 IT 部门越来越关注对业务部门需求的反应速度和给业务带来的实际成效，要求进一步提高 IT 服务的工作效率和工作质量。显然，要提高 IT 服务的整体绩效，不能仅仅局限于运维工作的范畴，也不是 ITIL 最佳实践就能够解决的问题。越来越多的 IT 人员都有相同的困惑，我也在一直思考：还有什么更好的方法能提高 IT 绩效？！

Dev+Ops 提出将开发和运维团队的工作紧密结合起来，建立持续交付和持续反馈闭环，这个思路让人耳目一新。但是彼时 DevOps 还在实践中探索，各种阐述 DevOps 的文章还是比较片面的，甚至有一些见解是相悖的。关于如何开展 DevOps，应该做什么、如何做，业内一直缺乏形成体系的说明。

随着 DevOps 的概念越来越受到关注，我对开展 DevOps 的困惑也越来越多。当我看到本书英文版时，虽然只有一个样章，但是它已经能让我确信，关于如何开展 DevOps 的很多问题都会在其中找到答案。于是，我欣然接受刘征的邀请，参与了本书的翻译工作。

翻译本书的过程就是学习和思考 DevOps 实践方法的过程。在这个过程中，我经常会经历作者在文中描述的“啊哈”时刻：疑惑解决了，思路豁然开朗。我相信本书的每一位读者都会经历这样的顿悟时刻。

在这本书的翻译过程中，翻译团队也实践了“三步工作法”中的第二步——反馈原则。反馈原则的核心思想是：虽然复杂的系统不可避免地存在错误，但是可以通过采取安全措施确保在质量问题出现之前，快速发现和处理错误。4个译者在分别翻译了不同的章节之后，都发现了在初稿中有诸多对原文理解的分歧和名词翻译不统一的问题。大家商议后决定，遵照“三步工作法”的反馈原则，全组集中从第一个章节开始交叉审阅、按序检查；发现问题及时在小组范围内讨论；形成一致意见后，分别回到自己负责的章节中修改。这个过程正是在 PDCA 中识别问题、群策群力解决问题、构建新知识并将局部知识应用到全局的过程。在这个过程中，每一个人也对 DevOps 实践有了更深刻的认识。

本书用大量真实的案例描述了 DevOps 实践产生的过程。他们所遇到的问题和困境，很多 IT 团队都曾经经历、正在经历，甚至在未来不可避免地即将经历。希望本书能在你感到困惑之时，对你有所启发、有所帮助。

经过13个月，本书终于出版在即了。翻译工作占用了我大量的业余时间，感谢我的父亲、母亲、丈夫和儿子，他们让我在翻译文章的那些夜晚和周末，只做一个繁忙的影子。

感谢一起翻译此书的伙伴们——刘征、王磊和马博文，以及图灵公司的编辑们。

曾朝京

2018年3月3日

特别感谢 EXIN 国际信息科学考试学会为本书提供的 DevOps Professional 认证考试样题及解析。《DevOps 实践指南》是 EXIN 国际信息科学考试学会指定的 DevOps Professional 国际认证核心教材。

序言

许多工程领域在过去都经历了长足的发展，它们不断地“提高”对本学科的认知和理解。虽然土木、机械、电气、核能等工程领域都有对应的大学课程和专业机构，但事实上，现代社会需要的是各种形态的工程学科相互交叉影响并从中受益。

想一想高性能车辆的设计工作。机械工程师的工作是在哪个环节结束的？电气工程师的工作是从哪个环节开始的？拥有空气动力学领域知识的人（对车窗的形状、大小和位置有很好的发言权）在哪儿（如何以及何时）开始和人体工程学专家协作？在车辆整个使用寿命期间，燃料混合物和汽油对发动机和变速器材料有什么化学影响？针对汽车设计，我们还能提出很多其他方面的问题，但最终的结论是一样的：要想在现代技术上取得成功，必然需要多方向和多专业领域的协作。

任何一个领域或学科想要取得进步和成熟，就需要认真反思它的起源，在反思中寻求不同的观点，并把这些不同观点的来龙去脉思考清楚，这对预见未来发展是非常有帮助的。

本书代表了这样一种承前启后的观点，它应该被视为软件工程和运维领域（在我看来，它仍在发展和快速地演变）里一个具有开创性的观点。

无论你处在哪个行业，无论你的公司提供什么产品或服务，这种思维方式对于所有业务和技术领导者都是至关重要且必不可少的，因为它关乎着企业的存亡。

John Allspaw

Etsy 首席技术官

2016年8月于纽约布鲁克林

前言

啊哈！

本书的写作由来已久。早在2011年2月，我们几位合著者就开始每周一次的 Skype 通话，准备写一本通用的 DevOps 参考指南，算作《凤凰项目：一个 IT 运维的传奇故事》[1]的姊妹篇。

前后历时5年多，耗费2000多小时，本书终于呈现在你的面前。过程相当漫长，但也是一个非常有益且难得的学习过程，最终涉及的范围比我们早期预想的更广。在整个写作过程中，所有合著者都始终坚信 DevOps 的重要性。我们在早期的职业生涯中，都曾经历过“啊哈”的顿悟时刻，相信很多读者也都会与我们产生共鸣。

Gene Kim

从1999年以来，我有幸一直在研究高绩效技术组织，最早的一个发现是：IT 运维、信息安全和开发等不同职能部门之间的良好合作是成功的关键。我依然清楚地记得第一次看到由于这些部门目标相左导致恶性循环的场景。

那是在2006年，我跟某管理团队待了整整一星期，他们当时正在为一家大的机票预订公司提供外包 IT 运维的管理服务。他们给我描述了每年要做的软件升级的后果：每次发布都会让外包商和客户的服务中断；由于客户受到了影响，公司也会根据服务等级协议（SLA）受到处罚；公司利润下滑，不得不解雇一些很有才华和经验的员工；由于有大量计划外的工作和紧急任务，剩下的员工无法处理日益增长的客户服务请求；只好投入中层管理团队一道完成合同要求；所有人都认为3年后肯定得重新招标。

这种绝望和无助的感受使我加入了这场道义上的征程。开发似乎总是被视为战略性的，而 IT 运维则被视为战术性的，因此常常被委托甚至整个外包出去，结果是5年后的情形比当初交接时更加糟糕。

多年来，我们许多人都认为一定有更好的做法。在2009年的 Velocity 会议上，我看到了这样的演讲——介绍了在架构、技术实践和文化方面并举的革新（我们现在称之为 DevOps）所产生的惊人效果。当时，我非常兴奋，因为它就是我们一直在寻找的那个更好的方法。传播 DevOps 是我合著《凤凰项目》的动机之一。你可以想象，看到更广大的社群对那本书做出的反应，说它是如何帮助他们实现自己的“啊哈”时刻的，我是多么地倍感欣慰！

Jez Humble

我的 DevOps“啊哈”时刻发生在2000年，当时我就职于一家创业公司，那是我毕业后的第一份工作。有一段时间，我是公司仅有的两名技术人员之一。我包揽了网络、编程、支持、系统管理等一切工作。我们通过 FTP 直接从工作站往生产环境部署软件。

我在2004年加入了 ThoughtWorks 咨询公司，参与的第一个项目涉及大约70人。我所在的部署团队共8名工程师，团队的主要工作就是将软件部署到类生产环境中。刚开始的时候，工作非常紧张。但几个月后，我们就从需要花两个星期的手动部署，进步到了只用一个小时的自动化部署。在正常的工作时间段里，我们也可以使用蓝绿部署模式，以毫秒为单位来发布或者回滚业务的应用。

这个项目对《持续交付：发布可靠软件的系统方法》[2]和本书的诸多想法都很有启发意义。对于我和从事该领域工作的其他人而言，动力有两个：我们知道无论是什么限制，总能做得更好；我们热切希望帮助那些正在奋斗的人们。

Patrick Debois

对我来说，DevOps 意味着一系列的回忆。2007年，我与几个敏捷团队一起，做一个数据中心迁移项目。我很嫉妒他们的高生产力——能够在很短的时间里做很多的工作。

在接下来的一个项目中，我便开始在运维工作中试验看板方法（Kanban），并看到了团队的显著变化。后来，在2008年的多伦多敏捷大会上，我基于这个实践发表了一篇 IEEE 论文，不过当时它并没有在敏捷社区里引起广泛的共鸣。我们创建了敏捷系统管理组（Google Group），但忽视了人这一因素。

在2009年的 Velocity 会议上，我听了 John Allspaw 和 Paul Hammond 所分享的“每日10次部署”的演讲以后，确信其他人与我英雄所见略同。因此我决定组织第一次 DevOpsDays 活动，误打误撞地创造了“DevOps”这个词。

DevOpsDays 活动体现了独特的魅力和感染力。当人们开始因 DevOps 改善了他们的工作而感谢我时，我才真正意识到它的影响力。从那以后，我就开始持续地推广 DevOps。

John Willis

2008年，我第一次见到 Luke Kanies（Puppet Labs 的创始人）本人，那时我刚刚出售了专注于大型系统的配置管理和监控（Tivoli）实践的咨询业务。Luke 在 O'Reilly 开源大会的配置管理分会场里介绍了 Puppet 软件。

演讲刚开始时，我在会场最后一排走来走去消磨时间，心想：“关于配置管理，这个20岁的年轻人能讲些什么呢？”毕竟，我在整个职业生涯中，基本都在帮助世界上最大的那些企业构建配置管理和其他运维管理方案。然而，他大约讲了5分钟后，我就坐到了第一排，同时意识到在过去20年里，我真是一无是处。Luke 所描述的就是现在我们所说的第二代配置管理。

在他演讲完之后，我找机会和他坐下来一起喝了杯咖啡。我完全被“基础设施即代码”（infrastructure as code）的理念所折服了。Luke 一边喝着咖啡，一边更详细地向我阐述了他的想法。他告诉我，他相信运维人员的工作模式可能会变得像开发人员一样，他们必须在源代码控制系统里维护系统的配置，并在工作中使用持续集成/持续交付（CI/CD）的模式。作为一名 IT 运维的老兵，我当时的回应大概是“运维人员不会喜欢你这个想法的”。（显然是我错了。）[3]

大约又过了一年，在2009年 O'Reilly 的 Velocity 会议上，我听了 Andrew Clay Shafer 关于敏捷基础设施的演讲。在演讲中，Andrew 展示了一幅形象的插图，图中的开发部门和运维部门之间存在一堵高墙，以此隐喻工作被两个部门踢来踢去。他将此称为“混乱之墙”（the wall of confusion）。这个想法其实和一年前 Luke 的想法如出一辙，这让我眼前一亮。那年年底，我作为唯一受邀的美国人，参加了比利时根特市的首次 DevOpsDays 活动。在活动结束时，这个所谓 DevOps 的东西已然融入了我的血液。

显然，本书的合著者都有类似的顿悟，尽管他们来自完全不同的方向。有充分的证据表明，上述这些问题几乎在所有地方都发生过，而那些 DevOps 相关的解决方案也几乎是普遍适用的。

编写本书的目的是描述如何复制我们参与过的或观察到的 DevOps 转型的成功经验，驳斥那些说 DevOps 在某些场景里行不通的谬论。以下是我们听说过的关于 DevOps 的一些最常见的误区。

误区1：DevOps 只适用于创业公司。虽然谷歌、亚马逊、Netflix 和 Etsy 等互联网“独角兽”公司是 DevOps 的先行者，但这些公司在过去都面临过巨大的风险，而且他们所遇到的问题和传统企业相比并无二致：软件的高风险代码容易导致灾难性故障，无法快速发布新功能来击败竞争对手，存在安全合规性问题，服务无法扩容，开发和运维彼此高度不信任等。

然而，这些公司都能够适时地改变它们的架构、技术实践和文化，如今他们都创造出了惊人的 DevOps 成果。正如信息安全高管 Branden Williams 博士所说：“不要管 DevOps 是适合独角兽还是马，只要跑得快就能抵达目的地。”

误区2：DevOps 将取代敏捷。DevOps 的原则和实践与敏捷方法一致，许多人认为 DevOps 是自2001年开始的敏捷之旅的合理延续。敏捷通常是 DevOps 效率的保障，因为它专注于让小团队向客户持续交付高品质的代码。

如果我们每次迭代的目标不限于“潜在可交付的代码”，而是扩展到让代码始终处于可发布状态，让开发人员每天都把代码提交到主干，并在类生产环境中做功能演示，那么许多 DevOps 相关的实践就会浮现。

误区3：DevOps 与 ITIL 不兼容。许多人认为，DevOps 与1989年发布的 ITIL（Information Technology Infrastructure Library，IT 基础架构库）或 ITSM（IT Service Management，IT 服务管理）是背道而驰的。ITIL 广泛影响了好几代运维实践者，包括本书的一位合著者，并且它依然在演进，是一个不断发展的实践体系，旨在稳定地支撑世界级的IT运维，而且横跨服务战略、设计和支持等流程和实践。

DevOps 实践可以与 ITIL 流程兼容。然而，为了支持 DevOps 所追求的更短的发布周期和更频繁的部署，ITIL 流程的许多方面需要完全自动化，以解决配置和发布管理流程相关的许多问题，例如保持配置管理数据库和最终软件库是最新的。由于 DevOps 需要在服务事件发生时进行快速的定位和恢复，因此这些其实还是和 ITIL 的服务设计、事件和问题管理方面的原则相一致。

误区4：DevOps 与信息安全及合规活动不兼容。传统控制手段（例如职责分离、变更审批流程、项目结束时的手动安全审查）的缺位，可能会令信息安全和合规审计人员感到失望。

然而，这并不意味着采用 DevOps 的公司里没有有效的控制，只是它并不一定体现在项目结束时的安全和合规性活动中，而是集成到了软件开发生命周期的每一项日常工作中，因此会得到更好的质量、安全性和合规性。

误区5：DevOps 意味着消除IT运维，即“NoOps”。许多人错误地将 DevOps 解释为完全消除 IT 运维的职能，然而，这种情况是很少见的。虽然 IT 运维工作的性质可能会发生改变，但它仍然像以前一样重要。IT 运维团队要在软件生命周期的早期就与开发团队开展合作。在代码部署到生产环境中后，开发团队也要继续与运维团队合作。

IT 运维不只是工单驱动的手动操作，而是能够通过自助服务平台和 API 来提升开发人员的生产效率，让他们能自助地创建开发环境、测试和部署代码、监控和显示业务运行的状态等。通过这种方式，IT 运维人员变得更像是开发人员（或者 QA 和信息安全人员），融入到了产品开发过程中，而该产品则是开发人员在生产中用来安全快速地测试、部署和运行 IT 服务的平台。

误区6：DevOps 只是“基础设施即代码”或自动化。尽管本书所展示的许多 DevOps 模式都需要自动化，但是 DevOps 还需要文化规范和架构，以便在 IT 价值流中实现共同的目标。而这远远超越了自动化的范畴。DevOps 最早的拥护者之一Christopher Little 也是一名技术主管，他写道：“DevOps 不仅是自动化，就像天文学不只是望远镜一样。”

误区7：DevOps 仅适用于开源软件。尽管许多 DevOps 成功案例发生在使用 LAMP 栈（Linux、Apache、MySQL、PHP）等构建软件的公司，但实现 DevOps 与所使用的技术无关。在使用 Microsoft .NET、COBOL 和大型机汇编语言以及 SAP 甚至嵌入式系统（如惠普 LaserJet 打印机固件程序）等编写应用程序的公司，DevOps 也能取得成功。

传播“啊哈”时刻

本书的每一位作者都被 DevOps 社区里发生的惊人创新及成果深深地打动和启发：他们正在创建安全的工作系统，让小型团队能够快速独立地开发和验证能够为客户安全地部署的代码。我们相信，DevOps 是创建动态、学习型且强化高度信任的文化规范的公司的一种表现形式，这些公司一定会持续地在市场上创新并在竞争中脱颖而出。

我们真诚地希望本书能以多种方式为许多人提供价值，它可以是一个 DevOps 转型计划和实践指南，也可以是一组可供研究和学习的参考案例，可以是一部 DevOps 编年史，也可以是一种联结产品经理、架构师、开发人员、QA、IT 运维和信息安全团队以实现共同目标的方法，可以是一条为 DevOps 活动获取高层领导支持的途径，也可以是一种改变技术组织管理方式的道德使命，以帮助企业提高效率，创造更快乐和更人性化的工作环境，并帮助每个人成为终身学习者。这不但能帮助每个人实现他们个人的最高目标，而且还能帮助他们的公司取得更大的成功。

[1] 关于《凤凰项目》，详见http://www.ituring.com.cn/book/1545。——编者注

[2] 关于《持续交付》，详见http://www.ituring.com.cn/book/758。——编者注

[3] 此处引用了关于 Led Zeppelin 抄袭的八卦。——译者注

第一部分　DevOps 介绍

在本书的第一部分中，我们将回顾在管理和技术领域里所发生的几个重大事件，了解它们是怎样为 DevOps 的诞生奠定了基础的。同时，我们还将介绍“价值流”这个概念，解释为什么 DevOps 是把精益原则应用到技术价值流中的结果，并探讨 DevOps 的三步工作法：流动、反馈以及持续学习与实验。

第一部分包括以下内容。

流动原则：它加速了从开发、运维到交付给客户的流程。
反馈原则：它使我们能建设出更安全可靠的工作体系。
持续学习与实验原则：它打造出一种高度信任的文化和一种科学的工作方式，并将对组织的改进和创新作为日常工作的一部分。

简史

DevOps 和它所产生的技术、架构及文化实践，体现了哲学和管理学原则的融合。虽说这些原则是由不同组织独立发现的，但 DevOps 博采众长，形成了 John Willis（本书作者之一）所说的“DevOps 的大融合”，展现了人们思想上的惊人进步和不可思议的相互关联。基于制造业实践了数十年的管理经验，它是将可靠性组织、信任度管理与 DevOps 实践相结合的产物。

DevOps 基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合地应用到 IT 价值流中，就产生出 DevOps 这样的成果。将它贯彻于整个技术价值流中，涉及产品管理、开发、QA、IT 运维和信息安全专员等不同角色，在更低的成本和努力下，保障产品的高质量、可靠性、稳定性和安全性。

虽然 DevOps 是精益原则、约束理论和丰田套路运动的衍生物，但也被许多人视为始于 2001 年的敏捷运动的延续。

精益运动

价值流映射、看板和全面生产维护这些实践起源于 20世纪80年代的丰田生产系统。1997年，精益企业协会开始研究如何将精益理念应用于服务业和医疗行业等其他价值流中。

精益的两个主要原则包括：坚信前置时间（把原材料转换为成品所需的时间）是提升质量、客户满意度和员工幸福感的最佳度量指标之一；小批量任务的交付是缩短前置时间的一个关键因素。

精益原则聚焦在如何通过系统性思考为客户创造价值，系统性思考的范围涉及建立持久目标，拥抱科学思维，创造流和拉动（而非推送）的协作模式，提倡从源头保证质量，以谦逊为导向，尊重流程中的所有个体。

敏捷宣言

敏捷宣言是在2001年由软件领域的17位顶尖大师共同提出的。他们希望用一套轻量级的价值观和原则体系，来优化那些沉重的软件开发流程（如传统的瀑布式开发模型）和方法论（如统一软件开发过程）。

在敏捷宣言中，一个重要的原则是“频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”，并强调使用小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。同时，强调建立自组织的小团队，让成员在高度信任的环境中愉悦地工作。

在很多实施了敏捷的企业里，生产效率显著提升，敏捷也因此获得了越来越广泛的支持和认可。有趣的是，在 DevOps 的发展历程中，如下所述的几个关键活动都发源于敏捷社区或者敏捷大会。

敏捷基础设施和 Velocity 大会

在2008年加拿大多伦多的敏捷大会上，Patrick Debois 和 Andrew Clay Schafer 主持了一场研讨，提倡将敏捷原则应用到基础设施而不是应用程序的代码上。尽管研讨的参与者数量并没有达到预期，但是他们还是很幸运地找到了几个志同道合者，其中包括本书作者之一 John Willis。

在2009年的 Velocity 大会上，John Allspaw 和 Paul Hammond 分享了题为“每日10次部署：Dev 和 Ops 在 Flickr 的协作”的演讲，讲述了他们如何建立 Dev 和 Ops 共享的目标，并通过运用持续集成等实践，将部署变成了日常工作的一部分。据当时在场的听众回忆道，所有的参与者都认为他们见证了这个具有深远意义的历史性时刻。

虽然 Patrick Debois 并不在现场，但他对 Allspaw 和 Hammond 的想法产生了浓厚的兴趣，并在2009年比利时的根特市（他的居住地）发起了第一次 DevOpsDays 活动。“DevOps”这个术语也应运而生。

持续交付

基于持续构建、测试和集成的开发原则，Jez Humble 和 David Farley 进行了延伸，提出了持续交付，并首次在2006年的敏捷大会上做了分享。在持续交付中，“部署流水线”确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全地部署到生产环境。2009年， Tim Fitz 在博客上发表了一篇题为“持续部署”的文章。[1]

丰田套路

Mike Rother 在2009年编写了《丰田套路：转变我们对领导力与管理的认知》一书，书中融入了他在丰田产品系统（TPS）中所积累的20年实践经验。他也曾参与了精益工具箱的制作。 Mike 在读研究生期间，曾和通用汽车公司的高层一起去日本参观丰田工厂，有一件事让他感到困惑：所有应用精益原则的公司中，没有一家能达到丰田的水平。

之后，Mike 得出了结论：精益社区中大多数企业都没有抓住精益的核心——改善套路（Kata）。他解释说，所有企业都有日常的工作流程，而这些日常工作决定了最终的产出。通过设定目标，制订每周的详细计划，并持续改善日常工作，如此循序渐进，才能达到优化和改进的目的。

以上描述了 DevOps 的发展历史和大事记。在接下来的内容里，我们将主要介绍价值流，以及如何将精益原则应用到技术价值流中；同时介绍三步工作法：流动、反馈和持续学习与实验。

[1] 另外，DevOps 还基于并拓展了“基础设施即代码”的实践，该实践由 Mark Burgess 博士、Luke Kanies 和 Adam Jacob 共同提出。在“基础设施即代码”这种实践中，运维工作被最大程度地自动化，并确保任何对基础设施的操作都通过代码来实现，从而将现代软件的开发实践应用到了整个产品交付中，其特性包括持续集成（由 Grady Booch 提出，是极限编程的12个实践之一）、持续交付（由 Jez Humble 和 David Farley 提出）和持续部署（由 Etsy、Wealthfront 和 Eric Ries 在 IMVU 的工作中提出）。

第1章　敏捷、持续交付和三步法

本章将阐释精益制造的基础理论和三步工作法原则，从后者能衍生出各种 DevOps 行为。

我们侧重于这些理论和原则，它们记录了制造业、高可靠性企业、高信任管理模型等几十年的经验，DevOps 实践正是基于这些经验衍生而来的。具体的原则和模式及其在技术价值流中的应用，会在本书的后续章节中陆续呈现。

1.1　制造业价值流

精益中的一个基本概念叫价值流。我们先在制造业的场景中定义它，再讨论如何将它应用到 DevOps 和技术价值流中。

Karen Martin 和 Mike Osterling 曾在 Value Stream Mapping 一书中把价值流定义为“一个组织基于客户的需求所执行的一系列有序的交付活动”，或者是“为了给客户设计、生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值”。

在制造业的流程中，价值流随处可见，它始于接收到客户订单并将原材料发往工厂。为了缩短和预测价值流中的前置时间，通常需要持续地关注如何建立一套流畅的工作流程，包括减小批量尺寸、减少在制品（Work in Process，WIP）数量、避免返工等，同时还需要确保不会将次品传递到下游的工作中心，并持续不断地基于全局目标来优化整个系统。

1.2　技术价值流

在制造业中加速物理产品加工流程的原则和模式，同样可以应用到技术工作（及所有知识工作）中。在 DevOps 中，我们通常将技术价值流定义为“把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程”。

流程的输入是既定的业务目标、概念、创意和假设，始于研发部门接受工作，并将它添加到待完成工作列表中。

接受了工作之后，研发团队将运用敏捷或迭代的开发流程，将那些想法转化为用户故事以及某种功能性说明，然后通过编写程序代码实现，再将代码签入到版本控制库中，接下来每次变更都将集成到软件系统并进行整体测试。

应用程序或服务只有在生产环境中按预期正常地运行，并为客户提供服务，所有的工作才产生价值。所以，我们不但要快速地交付，同时还要保证部署工作不会产生混乱和破坏，如中断客户服务、性能下降或者信息安全不合规等问题。

1.2.1　聚焦于部署前置时间

部署的前置时间是价值流的一个子集，也是本书讨论的重点。价值流始于工程师[1]（包括开发、QA、IT 运维和信息安全人员）向版本控制系统中提交了一个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息。

在第一个阶段中，工作主要包括设计和开发，它和精益产品开发有很多相似之处：都具有高度的变化性和不确定性，不仅需要创意，某些工作还可能无法重来，这导致无法确定总体处理时间。在第二个阶段中，工作主要包括测试和运维，它类似于精益制造。相比前一个阶段，它需要创造性和专业技能，力求可预见性和自动化，将可变性降到最低（如短的和可预测的前置时间，接近零缺陷），并满足业务目标。

我们并不提倡在设计、开发中串行地完成了大批量的工作后，再转入测试、运维阶段（如使用大批量、基于瀑布模型的开发流程，工作在长生命周期的特性分支上）。恰恰相反，我们的目标是采用测试和运维与设计和开发同步的模式，从而产生更快的价值流和更高的质量。只有当工作任务是小批量的，并将质量内建到价值流的每个部分时，这种同步的模式才能实现。[2]

定义前置时间和处理时间
在精益社区里，前置时间与处理时间（有时候也被称为接触时间或者任务时间）[3]是度量价值流性能的两个常用指标。
前置时间在工单创建后开始计时，到工作完成时结束；处理时间则从实际开始处理这个工作时才开始计时，它不包含这个工作在队列中排队等待的时间（见图1-1）。
图1-1　部署工作的前置时间和处理时间
因为前置时间是客户能够体验到的时间，所以我们把重点放在缩短前置时间而不是处理时间上。不过，处理时间与前置时间的比率是十分重要的效率指标，为了实现快速的流动并缩短前置时间，必须缩短工作在队列中的等待时间。
常见的场景：为期数月的部署前置时间
通常，部署前置时间动辄需要好几个月。在大型、复杂的企业里，使用着紧耦合的单体应用，少有集成测试的环境，测试和生产环境的前置时间很长，并且严重依赖于手动测试，或者需要各种审批流程，情况更是如此。这种情形下的价值流看起来如图1-2所示。
图1-2　某部署前置时间为期三个多月的技术价值流
^{（来源：2015年 Damon Edwards 的“DevOps Kaizen”)}
部署前置时间一旦变长，那么在价值流的每个阶段，几乎都需要“填坑”能手来补救。通常，很可能是在项目结束前，将开发团队的变更合并到一起后，才发现整个系统根本无法正常工作，有时甚至会出现代码都无法通过编译和测试的情况。每一个问题可能都需要几天甚至几周的时间来定位和修复，因此导致了极其糟糕的客户体验。
我们的目标：分钟级别的部署前置时间
在 DevOps 的理想情况下，开发人员能快速、持续地获得工作反馈，能快速和独立地开发、集成和验证代码，并能将代码部署到生产环境中（自己部署或者他人部署）。
我们可以通过如下方式达到这个目标：向版本控制系统中持续不断地提交小批量的代码变更，并对代码做自动化测试和探索测试，然后再将它部署到生产环境中。这样，我们就能对代码变更在生产环境中的成功运行保持高度自信，同时还能快速地发现并修复可能出现的问题。
为了更容易地实现上述目标，还需要通过模块化、高内聚、低耦合的方式优化架构设计，帮助小型团队自治地工作。这样即便失败了，也能在可控范围内，而不至于对全局产生影响。
通过上述方式，能有效地将前置时间缩短至分钟级别；即便在最坏的情况下，也不会超过小时级别。其价值流图如图1-3所示。
图1-3　前置时间为分钟级别的技术价值流

1.2.2　关注返工指标——%C/A

除了前置时间和处理时间外，技术价值流中的第三个关键指标是完成时间和精确的总花费时间的百分比（%C/A）。该指标反映了价值流中的每个步骤的输出质量。Karen Martin 和 Mike Osterling 描述道：“要获取%C/A，可以询问下游客户他们有百分之多少的时间收到了‘真正有用的工作’，即他们可以专心做有用的工作，而不必修复错误信息、补充信息，或者澄清那些本该确定的信息。”

1.3　三步工作法：DevOps 的基础原则

《凤凰项目》把三步工作法作为基础的原则，并由此衍生出了 DevOps 的行为和模式（见图1-4）。

{70%}

图1-4　三步工作法

^{（来源：Gene Kim 在 IT Revolution Press 博客上发布的“三步工作法：DevOps 的基础原则”，访问于2016年8月9日，http://itrevolution.com/the-three-ways-principles-underpinning-devops/）}

第一步，实现开发到运维的工作快速地从左向右流动。为了最大程度地优化工作流，需要将工作可视化，减小每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标。

通过加快技术价值流的流速，缩短满足内部或者外部客户需求所需的前置时间，尤其是缩短代码部署到生产环境所需的时间，可以有效地提高工作质量和产量，并使企业具有更强的外部竞争力。

相关的实践包括持续构建、集成、测试和部署，按需进行环境搭建，限制在制品数量，构建能够安全地实施变更的系统和组织。

第二步，在从右向左的每个阶段中，应用持续、快速的工作反馈机制。该方法通过放大反馈环防止问题复发，并能缩短问题检测周期，实现快速修复。通过这种方式，我们能从源头控制质量，并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统，还可以在灾难性事故发生前就检测到并解决它。

及时发现并控制这些问题，直到拥有有效的对策，可以持续地缩短反馈周期和放大反馈环，这是所有现代流程优化方法的一个核心原则，能够创造出组织学习与改进的机会。

第三步，建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验。通过主动地承担风险，不但能从成功中学习，也能从失败中学习。通过持续地缩短和放大反馈环，不仅能创造更安全的工作系统，也能承担更多的风险，并进行试验帮助自己比竞争对手改进得更快，从而在市场竞争中战胜他们。

作为第三步的一部分，我们能够让工作系统事半功倍，将局部优化转化为全局优化。另外，不管是谁参与了工作，所有经验都可以持续地积累，组织里的人都可以相互借鉴彼此的经验和智慧。

1.4　小结

本章描述了价值流的概念，同时还介绍了制造业价值流和技术价值流中的一个重要量度指标——前置时间，最后介绍了三步工作法（支撑 DevOps 的原则）的基本概念。

在后续的章节中，我们将更详细地描述三步工作法。第一步是流动原则，不管是在制造行业还是在信息技术产业，它都聚焦于在价值交付过程中建立快速的工作流。关于快速流动的更多实践，将会在本书的第三部分详细描述。

[1] 从目前开始，工程师指的是在我们的价值流中的任何工作者，而不仅仅指开发人员。

[2] 事实上，使用类似测试驱动开发的技术，测试甚至可以发生在编写第一行程序代码之前。

[3] Karen Martin 和 Mike Osterling 曾说：“为了避免混淆，我们不使用‘循环时间’这个词，因为它还有其他的同义词——处理时间、输出速率或输出频率等。”同理，本书中主要使用“处理时间”一词。

DevOps 实践指南

内容简介

作者简介

本书内容

推荐语

译者序

序言

前言

啊哈！

传播“啊哈”时刻

第一部分 DevOps 介绍

简史

精益运动

敏捷宣言

敏捷基础设施和 Velocity 大会

持续交付

丰田套路

第1章 敏捷、持续交付和三步法

1.1 制造业价值流

1.2 技术价值流

1.2.1 聚焦于部署前置时间

1.2.2 关注返工指标——%C/A

1.3 三步工作法：DevOps 的基础原则

1.4 小结