作者简介

奥列格•斯克伦尼科(Oleg Skrynnik)

EXIN DevOps Master，GamingWorks认证培训师，ITIL专家。从事IT工作超过25年，担任领导职务超过15年。自2003年以来，一直从事培训课程和商业游戏的开发与实施，同时也为组织提供IT管理咨询服务，Dev和Ops都有涉及。他在俄罗斯和荷兰出版的《面向IT经理的DevOps》一书，是EXIN DevOps Foundation考试的基础教材。

译者简介

林伟丹

敏捷转型专家和领导力教练。中国DevOpsDays及中国DevOps社区核心组织者之一，EXIN DevOps授权讲师，凤凰项目、火星着陆器、挑战埃及三大版权沙盘引导师。ICAgile认证敏捷教练，埃里克森专业教练，ACT（敏捷教练工具箱）联合创始人。专注于支持企业敏捷与DevOps转型及内部教练培养，多年为互联网、金融、电信、政府、医疗、教育等各行业客户提供专业服务。曾任世界500强企业研发管理总监，负责企业级研发体系、重大项目办公室、敏捷教练专家团队与DevOps工具链研发，多年主导8000+人规模的组织级精益敏捷转型，成效斐然。

姚冬

知名DevOps与精益/敏捷专家，软件工程专家；中国DevOps社区核心组织者，中国DevOpsDays大会核心组织者。曾任IBM DevOps产品线大中华区技术总监，现任华为云应用平台部首席技术布道师。《敏捷无敌之DevOps时代》合著者，他的公众号AgileRunner专注于精益/敏捷/DevOps技术分享。

《DevOps 精要：业务视角》从基本面出发，通过结构化的方式，提纲挈领地阐述了 DevOps 的全貌，实事求是地阐述了如何以有效的方式将 DevOps 引入管理领域。书中讨论了 DevOps 的起源，DevOps 涌现和兴起的必然性，关键的先决条件及其在实践中的反映，实践本身及其背后所遵循的原则。

《DevOps 精要：业务视角》适合 IT 专业人士、IT 经理和 IT 管理层阅读，可以帮助他们从一开始就认清 DevOps 的来龙去脉、它的优势与不足以及如何才能高效地用好DevOps。

IT管理方法不是一成不变的。如今，信息系统开发和运维所使用的方法明显区别于几十年前的。这些方法一直在演进，明天可能又会出现下一代基于新的知识、经验和技术的方法。大多数时候，管理方法会基于某些基本的原理和假定，打磨之前已有的模型并使之体系化，逐渐地演进。但是，时不时也会出现一些非连续的情况，个别领先组织在信息技术的有效与高效应用上，已经大步向前迈出了重要的步伐。

IT管理从聚焦于IT系统，转变为聚焦于IT服务的管理，就是一个很好的例子。如图1.1所示，从2000年左右开始，对于管理的认识变化，使得领先者赢得了重要的竞争优势。这些涌现出来的管理实践，被先行者成功采纳之后，成为了所谓的最佳实践.有些最佳实践进一步演进为被业界广泛接受的做法，甚至对行业标准产生了影响。当然，也有些组织并没有在工作中应用这些最佳实践或标准，因为在那个时候，并非所有的经济领域都显著依赖于IT。

图1.1  新实践的涌现与使用

我们以IT服务管理为例来看一看。在20世纪80年代，这样的想法开始出现：信息技术以服务的形式提供价值，并以流程的形式组织IT活动。有些欧洲公司成为先行者，他们发展出组织工作的新实践及解决管理问题的新方法。其中有些实践，例如服务台的引入、事件和问题的区分、IT基础设施变更的受控过程等，在2000～2001年的ITIL等重要出版物（那时ITIL代表IT基础设施库） 中清晰地阐述出来，使得这些实践得以进入最佳实践之列，开始引入它们的不光是领先者组织，也包括追随者。最终，在2002年，BS 15000-1:2002 即IT服务管理的首个标准发布，这为那些寻求构建一个连贯的IT服务管理系统的组织而言，建立了一个可以遵循的具体标准。也就是说，实践、出版物和标准，都未曾停止过发展的脚步，如图1.2所示。

图1.2  实践的发展

从敏捷软件开发中，也可以观察到类似的发展动态。然而，这次酝酿的革命所影响的范围，已经超出了软件开发本身，带来的影响面不亚于当年的ITSM。

如今，新涌现出来的实践，被打上DevOps（开发+运维）的标签。实际上，DevOps的内涵，如同ITIL超出“库”的概念以及COBIT超出受控对象的含义一样，已经大大超出其原始的含义。 

这么说来，DevOps的现象值得研究。要想理解DevOps的完整要义，需要结合相关的背景来了解其思想连同与之关联的运动。

1.1  起源

一般认为，DevOps的出现源于两个因素：敏捷软件方法的广泛采用以及IT基础设施即程序代码的管理方式。我们分别来看一看。

1.1.1  敏捷软件开发方法

在20世纪末期，主流的软件开发方法是图1.3所示的所谓“瀑布模型”：顺序式执行预定义的阶段，每个阶段花很长时间，并以达成先前协商好的结果作为结束；很多时候，只有在前一个阶段已经完整且正式完工时，才能转移到下一个阶段。这个模型的另一个显著特征是，每个阶段所涉及的人员职能有专业化的分工：分析师、架构师、开发人员和测试人员等。

当开发的是功能可预先定义、对快速产品交付没有或很少有要求的大型信息系统时，这个模型能够确保我们创建高质量产品并进行有效与精细的成本控制。

然而，在20世纪90年代末期，随着互联网技术与Web编程的快速发展，瀑布模型的消极作用开始显现，影响到信息系统客户（内部或外部业务）与提供者（内部或外部软件开发者）之间的交互和理解。事实上，对业务客户的市场机会不断涌现，这要求团队能够快速发布（最多在几个月之内）新产品到市场上。然而，从项目启动到第一个可运行原型的典型开发闭环，可能要花6到18个月时间；而在大型企业中，甚至需要2到3年。此外，随着很多在之前并不为人知晓但有潜在前景的市场机会涌现，客户的需求在开发过程中很可能会发生变化，这样一来，要有效应对市场机会而不延误截止日期，且同时还不降低产品质量，就变得极为困难，如图1.4所示。

目    录

01 什么是DevOps 1

1.1  起源 3

1.1.1  敏捷软件开发方法 3

1.1.2  管理基础设施即代码 7

1.1.3  这是必然的 11

1.2  定义 11

1.3  为什么要实施DevOps？ 14

1.3.1  缩短市场响应时间 14

1.3.2  减少技术债务 19

1.3.3  消除脆弱性 20

1.4  历史起源 23

1.5  常见误解 25

1.5.1  DevOps是敏捷的一部分 25

1.5.2  DevOps是工具和自动化 28

1.5.3  DevOps是一个新的职业 29

1.6  小结 29

02 基础 31

2.1  精益生产 31

2.1.1  关键事实 31

2.1.2  挑战 34

2.2  敏捷 37

2.2.1  关键事实 37

2.2.2  挑战 38

03 原则 41

3.1  价值流 41

3.2  部署流水线 45

3.3  一切都应存储在版本控制系统中 49

3.4  自动化配置管理 50

3.5  完成的定义 51

3.6  小结 52

04 关键实践 53

4.1  和传统实践的关键区别 53

4.1.1  发布是日常活动 53

4.1.2  发布是业务决定 55

4.1.3  一切都是自动化的 56

4.1.4  事件要立即解决 57

4.1.5  缺陷是立即被修复的 58

4.1.6  流程是持续更新的 59

4.1.7  像初创公司一样行动 60

4.2  非同寻常的团队 61

4.3  工作可视化 64

4.4  限制在制品（WIP） 68

4.5  减小批次大小 72

4.6  留意运维需求 74

4.7  尽早检测并修正缺陷 76

4.8  管理的而不是受控的改善和创新 77

4.9  为创新提供资金 80

4.10  任务优先级 83

4.11  持续识别、发掘并评估约束 85

4.12  小结 86

05 应用实践 87

5.1  DevOps适用性及限制 87

5.2  COTS 93

5.3  架构演进 95

5.4  DevOps与ITSM 99

5.5  货物崇拜 103

5.6  从当前所处位置启航，迭代推进 104

5.7  以价值流为核心 107

5.8  小结 108

06 结语 111

附录 113

附赠资源 119