DevOps实施手册 在多级IT企业中使用DevOps_《devops实施手册》
赞
踩
第1 章 DevOps 概述············· 1
1.1 DevOps：起源·············2
1.2 DevOps：本源·············4
1.3 DevOps：实践···········10
1.3.1 持续集成············· 11
1.3.2 持续交付·············15
1.3.3 支持实践·············19
1.3.4 前移·····················27
1.3.5 架构与降低风险···30
1.3.6 持续改进·············31
1.3.7 衡量标准·············31
1.3.8 业务驱动·············32
1.4 DevOps：文化···········33
1.5 总结···························35
第2 章 DevOps 实施··········· 37
2.1 撰写指导手册············39
2.1.1 识别目标状态(业
务目标及驱动) ····40
2.1.2 评估现状·············43
2.1.3 选择变革方案······56
2.1.4 实施变革方案······57
2.2 总结···························61
第3 章 开发DevOps 变革的
商业案例··················63
3.1 开发商业案例··········· 64
3.2 完成商业模式画布··· 67
3.3 客户细分··················· 68
3.3.1 业务线················ 68
3.3.2 IT 组织················ 69
3.4 价值主张··················· 70
3.4.1 业务线················ 70
3.4.2 IT 组织················ 72
3.5 渠道通路··················· 74
3.5.1 业务线················ 74
3.5.2 IT 组织················ 75
3.6 客户关系··················· 75
3.6.1 业务线················ 75
3.6.2 IT 组织················ 75
3.7 收入来源··················· 75
3.7.1 业务线················ 76
3.7.2 IT 组织················ 76
3.8 核心资源··················· 76
3.8.1 业务线················ 76
3.8.2 IT 组织················ 77
DevOps 实施手册 在多级IT 企业中使用DevOps
XXIV
3.9 关键业务···················77
3.9.1 业务线·················77
3.9.2 IT 组织················77
3.10 战略伙伴·················78
3.10.1 业务线···············78
3.10.2 IT 组织··············79
3.11 成本结构··················79
3.11.1 业务线···············79
3.11.2 IT 组织···············79
3.12 总结·························80
第4 章 DevOps 方案之优化
持续交付流水线······· 81
4.1 DevOps 作为优化
运动···························82
4.2 核心主题···················88
4.2.1 缩短周期时间······89
4.2.2 缩小批次规模······91
4.2.3 建设正确文化
理念·····················95
4.3 DevOps 实施方案······99
4.3.1 方案：建设衡量
标准与关键绩效
指标·····················99
4.3.2 方案：敏捷
实施···················107
4.3.3 方案：集成的交付
流水线···············110
4.3.4 方案：持续
集成···················116
4.3.5 方案：持续
交付·················· 120
4.3.6 方案：测试
前移·················· 133
4.3.7 方案：运维参与
前移·················· 139
4.3.8 方案：持续监控
与反馈·············· 145
4.3.9 方案：发布
管理·················· 151
4.4 专注核心方案········· 154
4.4.1 方案：移动设备
DevOps ············· 154
4.4.2 方案：大型机
的DevOps········· 161
4.4.3 方案：物联网
DevOps ············· 165
4.4.4 方案：DevOps
用于大数据及
分析·················· 168
4.5 总结························ 173
第5 章 DevOps 驱动创新
方案·······················175
5.1 优化创新················· 176
5.2 Uber 综合症············ 178
5.3 创新与技术的
角色························ 178
5.3.1 商业模式创新··· 179
5.3.2 商业模式实验··· 180
目 录
XXV
5.3.3 用户参与模式
创新···················181
5.4 核心主题·················183
5.4.1 实现多级IT·······184
5.4.2 构建正确的
事物···················187
5.4.3 进行实验···········190
5.4.4 提供反脆弱的
系统···················192
5.4.5 IT 系统与反脆
弱性···················195
5.5 方案：构建DevOps
平台························199
5.5.1 应用交付与反脆
弱性···················202
5.5.2 环境抽象层·······203
5.5.3 云托管的DevOps
平台···················204
5.5.4 基础设施即
服务···················209
5.5.5 OpenStack Heat
作为抽象层·······214
5.5.6 平台即服务·······215
5.5.7 容器···················219
5.6 方案：交付微服务
架构·························223
5.6.1 微服务架构·······224
5.6.2 应用的12 要素···226
5.6.3 云原生应用·······228
5.6.4 微服务和容器····230
5.6.5 微服务化改造··· 230
5.7 方案：API 经济······ 233
5.7.1 部署自动化和
API···················· 236
5.7.2 DevOps 平台和
API···················· 236
5.8 方案：组织创新····· 238
5.9 总结························ 240
第6 章 DevOps 的企业级
推广·······················243
6.1 核心主题················· 244
6.1.1 组织文化··········· 245
6.1.2 工具与实践
标准化·············· 246
6.1.3 有组织的实施··· 247
6.1.4 打破组织仓筒··· 248
6.2 方案：DevOps 能力
中心························ 248
6.2.1 DevOps 能力中心
的功能与目标··· 250
6.2.2 能力中心的核心
角色·················· 251
6.2.3 DevOps 教练····· 251
6.2.4 建立能力中心··· 253
6.3 方案：发展规模创
新文化····················· 254
6.4 方案：发展持续改进
文化······················· 259
6.4.1 开发实施路
线图·················· 261
DevOps 实施手册 在多级IT 企业中使用DevOps
XXVI
6.4.2 持续开发与价值
流图···················262
6.5 方案：DevOps 团队
模型·························264
6.6 方案：工具与流程
标准化····················267
6.7 方案：DevOps 的
安全性考虑··············271
6.7.1 管理安全相关
风险···················273
6.7.2 解决DevOps 流程
与平台的安全
问题···················275
6.7.3 API 经济与
安全···················279
6.8 方案：DevOps 与
外包·························280
6.8.1 战略外包···········281
6.8.2 IT 供应链··········282
6.8.3 利用外包实现
DevOps ··············283
6.9 总结·························283
第7 章 引领企业的DevOps
实施······················· 285
7.1 方案：DevOps 作为
变革运动················287
7.1.1 令人信服的行动
理由···················289
7.1.2 DevOps 变革的
反模式·············· 290
7.2 方案：发展协作信
任的文化················· 293
7.2.1 可见性促进
信任·················· 294
7.2.2 一切都关乎人··· 295
7.3 方案：业务线的
DevOps 思维··········· 296
7.3.1 业务线与IT 的
接触·················· 297
7.3.2 参与DevOps
变革·················· 298
7.3.3 让影子IT 走出
阴影·················· 298
7.4 方案：利用试点
项目启动················ 299
7.4.1 试点项目选择··· 301
7.4.2 高层管理者
支持·················· 302
7.5 方案：在航空母舰
上培养独角兽········· 302
7.6 总结························ 306
附录A 案例研究·················307
A.1 组织背景················ 307
A.2 路线图组成············ 308
A.2.1 DevOps 的优化与
创新工作坊······· 309
A.2.2 背景和上下文··· 310
目 录
XXVII
A.3 实施路线图·············312
A.3.1 业务驱动
因素···················312
A.3.2 现有的IT
举措···················313
A.3.3 瓶颈··················314
A.3.4 根因分析·········· 316
A.3.5 DevOps 实践···· 316
A.3.6 实施路线图······ 321
参考文献······························323
第1 章
DevOps 概述
开发经理的咆哮
事情是这样的，开发人员在周一下午完成了新服务的编码工作。她构建代码、运行单元测试，并将代码提交到集成流中以便进行持续集成(CI)构建。为了测试其服务，开发人员在下班前给测试(QA)团队开了一个任务单。
星期二早上，QA 团队进来看到了这个分配给他们的任务单。一个测试人员拿到了任务单并给开发人员发邮件请求部署说明。由于没有自动化部署，开发人员回应说她将亲自部署服务到QA 环境中。星期二下午，他们参加电话会议进行代码部署。开发人员发现测试环境与其代码不兼容。他们需要一个新环境。星期二晚上，测试人员开了一个任务单给运维(Ops)团队申请一个不同规格的新环境。
星期三早上，运维团队把工作单分配给处理规格和处理防火墙端口变更的工程师。当他去吃午餐的时候，他开出一个任务单给安全团队以批准端口变更。星期三下午，安全团队给安全工程师开出任务单，安全工程师批准了变更。星期三晚上，运维工程师收到批准，并开始构建新环境 。他需要手动构建虚拟机(VM)，其中包括操作系统(OS)、应用服务器、数据库以及Web服务器。
星期四早晨，服务器构建完成，任务单关闭。测试人员再次发邮件DevOps实施手册 在多级IT企业中使用DevOps。
2
给开发人员部署新服务。开发人员部署了新服务，并且测试人员开始准备可用的测试脚本。他需要运行回归测试，但是他需要额外的数据进行重新测试。星期四下午，他给生产支持团队开出一个申请新测试数据任务单。
星期五早晨，生产支持团队指派了一名数据库分析师(DBA)从生产环境收集数据。但此时已经是星期五下午了。每个人都知道DBA 们在星期五的下午是不工作的。星期一的早晨，测试人员从DBA 手中得到了测试数据。他用了20 分钟时间运行回归测试，并且发现一个缺陷。
他把任务单退回给开发人员，在代码编写构建完成整整一周之后。在这份代码之上整整一周的编码工作等待处理，不知道是否存在缺陷。我们现在又落后一周了。
这个故事的可怕之处在于，当我把它讲给其他公司的同行听时，他们并不感同身受，只是惊讶：相比他们，我们竟然如此高效！——又一个沮丧的开发经理。
DevOps 运动始于约翰·阿尔斯帕瓦和保罗·哈蒙德(当时他们都服务于Flickr/Yahoo)在2009 O’Reilly 敏捷大会上的一次具有开创性意义的演讲。演讲的题目是《每天10+部署：开发与运维在Flickr 的协作》①。每天10 次部署被认为是史无前例的。同年，帕特里克·德布瓦在比利时根特组织第一次DevOpsDays 活动时，最终将他们的方法称为DevOps。
这个名称开始流行起来并引发极大关注，但最初仅限于初创公司，更具体地说，是那些提供Web 应用的组织。这些应用由开发人员(Dev)创建，他们通常以非常迅速的方式向其Web 应用提交变更。他们所面临的主要障碍来自于运维(Ops)团队，由于变更管理流程僵化而且苛刻，以致运维团队在部署变更时速度非常缓慢。
① http://conferences.oreilly.com/velocity/velocity2009/public/schedule/detail/7641。
3
DevOps 运动的目标就是要解决开发与运维团队之间的阻抗失衡；弥合彼此之间的鸿沟；促进更多沟通、合作与信任。从本质上讲，这是一次文化运动，致力于改变开发与运维团队之间的文化差异，通过自动化使应用交付更快速、更高效并最终做到持续交付。2010 年，当时在
ThoughtWorks 公司工作的杰兹·汉姆，在他的著作《持续交付》中编写了一些DevOps 的核心实践，使得DevOps 的实施变得切实可行，由此，将DevOps 介绍给全行业的从业人员。
不过，DevOps 被看作是那些独角兽公司才做的事情，也就是那些处在创新前沿的，没有大型的、复杂的遗留系统需要维护的初创型组织，还没有成为大型企业的主流。然而，这些大型企业看到了初创公司运用DevOps 所取得的成功，并且试图实施DevOps 以满足其自身需求。像IBM 这样的组织开始涉足自动化部署以及虚拟化环境架构，甚至将两种能力相融合。与此同时，像UrbanCode 这样在自动化构建领域信誉卓著的公司，随着uDeploy 的发布，也开始转向DevOps, 由此创建了一类新的持续交付工具。自动化领域的其他公司，比如Nolio 也加入行列之中并提供自己的竞争产品。同时，运维和基础设施即代码(infrastructure ascode)方面的公司，如Opscode(现在称为Chef)和Puppet Labs 也受到关注(Opscode 的Chef 和Puppet Labs 的Puppet)。
2012 年，IBM 利用SmartCloud Continuous Delivery 开始了其第一项短暂的持续交付实验，自此，DevOps 开始真正走进了大型企业。一些咨询公司，比如Thoughtworks 和IBM，也开始为组织，尤其是想要实施DevOps 的大型组织提供咨询服务，协助其将独角兽公司的成功经验转换成企业适用模式。通过分别收购(巧合的是在2013 年4 月的同一天)UrbanCode 与Nolio，IBM 和CA Technologies 宣布正式进军DevOps领域。然而，DevOps 运动有史以来最重要的转折点是发生在2013 年基恩·金(Gene Kim)的著作《凤凰项目》(Phoenix Project)出版的时候。这本书的灵感来源于艾利·高德拉特(Eliyahu M. Goldratt)的著作《目标》，正如高德拉特的著作曾领先制造业几十年的时间，《凤凰项目》现已成为现代IT 界贯彻执行精益实践以及高德拉特约束理论的必读书籍。DevOps 实施手册 在多级IT 企业中使用DevOps用这本书，还有后来每年与杰兹·汉姆和帕比特·莱博斯联合发布的《DevOps 现状调查报告》，基恩·金使DevOps 真正成为主流。
1.2 DevOps：本源
DevOps 从哪里来？虽然我已经大概讲述了其起源的故事，但DevOps真正的起源要早于Allspaw、Debois、Humble 和Kim 将近一个世纪的时间。这需要追溯到发源于20 世纪10 年代的精益运动。随着亨利·福特在T 型车生产线中应用了精益流程管理，精益运动开始在制造业兴起。自20 世纪30 年代起，丰田的丰田喜一郞(KiichiroToyoda)与大野耐一(Taiichi Ohno)将这项工作进一步扩展、细化及整理，二战后得以真正迅速发展起来。20 世纪50 年代，这项工作受到戴明博士(Dr. William E. Deming)提出的计划-执行-检查-处理(Plan–Do–Check–Act，PDCA)循环理论的影响不断改进，以持续提高生产质量。基于其最为核心的方法，精益生产运动旨在持续改进产品质量的同时减少生产过程当中的浪费。在詹姆斯·P. 沃麦克(James P. Womack)和丹尼尔·T. 琼斯(Daniel T. Jones)1990 年出版的《改变世界的机器》(必读)以及1996 年出版的《精益思想》(Lean.org，2016)这两本著作中，精益得到进一步的诠释。
戴明的精益思想与持续改进
戴明博士教导说，通过采取适当的管理原则，组织可以在提高质量的同时降低成本(通过减少浪费、返工、员工流失及客户投诉，同时提高客户的忠诚度)。关键是要实施持续改进，并且视生产为一个完整系统，而非零零碎碎的 。——戴明博士的管理培训(戴明，1998)
2001 年，敏捷出现了。包括库克伯恩和马丁·福勒在内的17个思想领袖发表了敏捷宣言②。宣言的核心是摆脱僵化、瀑布式的、文档化的软件开发世界，这是大多少数软件开发项目延期、超预算或是惨痛失败的原因。他们的目标是找到一种迭代的方法，实现与客户、终端用户或代理人的持续互动。他们不想再通过诸如需求文档之类的主要硬性指标来衡量进度，因为这类指标不会提升代码的交付速度。另一目标是利用实际运行的代码(运行的软件)作为衡量进度的真正标准；审视计划与实际进展的匹配；创建不需要预先编写，但会随着应用的开发而改进与完善的需求。
随着极限编程(Extreme Programming，XP)、敏捷软件开发(Scrum)以及近期出现的规模化敏捷框架或是SAFe 这些方法论的发展，敏捷得到进一步提升。今天，不论大型还是小型的组织都在利用敏捷方法交付各种规模与技术的项目。敏捷是DevOps 需求的前驱，并已成为核心的驱动力。随着开发人员加快代码交付速度，代码需要更快速地测试；还需要更加频繁地部署到开发及测试服务器，并最终部署到生产环境。但是运维团队并没为此做好准备，这导致了开发到测试的交接过程中出现了瓶颈，因为测试无法根据需要按时创建适当的测试环境，更为重要的是发布时的生产环境。产品发布仍然是一个重大的任务，“发布周末”通常都会持续到周末以后发布。
记得90 年代早期我在一家金融机构从事开发工作(当时称为银行后台)，在周末发布时，令我非常懊恼的是，我们被要求在周五的早上带着睡袋去工作。我们预计整个周末都要待在那了。开放了多间设有电话会议桥的会议室，让每一个团队彼此沟通。一个会议室就如同一个作战室，项目负责人通过一个大型的电子表格协调所有利益相关者。管理层尽最大努力想要营造一种聚会的气氛，但最初的几小时过后就烟消云散了。我们第一次和运维人员进行交流。我们把代码交给了此前从未见过这些代码的人。他们使用我们所不熟悉的脚本与工具，将代码部署到我们无法访问的环境中。整个周末都一团糟。大量的食品和变味的咖啡，似乎一切都没有按计划进行。我们支持的商人都是很聪明的。他们总是在接下来的周一安排一次郊游或野餐。他们知道一切都会停摆，而且他们是对的。幸运的是，我们一年只有两次这样的情况。对我个人而言更为幸运的是，我在那里工作期间只赶上两次发布。
代码的短迭代快速开发，增强了开发与运维团队之间更好沟通与协作的需求。生产环境发布频频失败，揭示出开发人员对类生产环境的访问需求。仅仅提高流程中的一个部分，即开发代码的效率，使整个流程的低效暴露无遗，这就导致测试与运维成为主要瓶颈。如果把应用开发及交付流程比作工厂里的生产线，在下游的工序仍然低效工作的情况下，仅仅加快其中某一道工序的工作速度来增加零部件的数量，对提高整条生产线的交付速度没有任何帮助，只会制造更多的积压而已 (如图1-1 所示) 。这不仅是运维的挑战，也是交付生命周期中所有利益相关者的挑战。
如今的焦点转向周期时间最小化。周期时间指的是从需求或者用户故事开始到把功能交付到客户手中，或者至少是完成集成、测试并已为部署到客户机做好准备的时间。这导致DevOps 两项核心能力的发展：持续集成(已经是敏捷的核心竞争力)与持续交付。稍后将详细讨论这两项能力。将运维团队纳入交付生命周期中，作为流程的一个部分，而非在代码发布前都不参与进来的独立筒仓，这种超越开发-测试周期的敏捷扩展已成为DevOps 的核心原则。
节选自《DevOps实施手册 在多级IT企业中使用DevOps》第一章
《DevOps实施手册 在多级IT企业中使用DevOps》试读电子书，免费提供，有需要的留下邮箱，一有空即发送给大家。邮箱留到微信回复更快（邮箱地址+试读书名），别忘啦顶哦！
微信：qinghuashuyou
更多最新图书请点击查看哦（即日起-5月31日：关注@qinghuashuyou 发送：关注技术方向，即有机会参与图书抽奖，每周抽取十个幸运读者）
