具体描述
本书共分为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公司。
译者简介：
刘征
Nutanix路坦力资深架构师，EXIN首批国内DevOps Master和DevOps Professional认证讲师，持有红帽RHCA认证和AWS高级架构师认证，谙熟企业数据中心的IT服务管理。目前致力于推广DevOps相关的理念和实践，在DevOps社区中积极地参与培训和研讨会等活动，是DevOpsDays大会社区在中国的核心组织者和志愿工作者。
王磊
前ThoughtWorks咨询师，EXIN首批国内DevOps Master认证讲师。拥有10多年软件行业经验，以及服务化架构、持续交付和DevOps转型等方面的丰富实践经验。国内较早倡导和实践微服务的先行者，著有国内首本微服务架构相关图书《微服务架构与实践》，是西安DevOps Meetup活动的联合发起人。
马博文
前ThoughtWorks咨询师，AWS认证助理架构师、开发者。拥有多年Web开发和DevOps经验，熟悉持续交付、微服务。曾参与翻译《Scala编程实战》《DevOps实践》等书，是西安DevOps Meetup活动的发起人。
曾朝京
Micro Focus资深解决方案顾问，曾参加EXIN首批国内Devops Master讲师认证培训。长期从事IT运维管理领域咨询工作，曾为能源、金融、航空运输、政府行业中的多个大型企业提供IT运维管理规划。目前致力于探索DevOps理念在企业IT部门的实践。
目录信息
第1章 敏捷、持续交付和三步法 4
1.1 制造业价值流 4
1.2 技术价值流 4
1.2.1 聚焦于部署前置时间 5
1.2.2 关注返工指标——%C/A 7
1.3 三步工作法：DevOps的基础原则 7
1.4 小结 8
第2章 第一步：流动原则 9
2.1 使工作可见 9
2.2 限制在制品数 10
2.3 减小批量大小 11
2.4 减少交接次数 13
2.5 持续识别和改善约束点 14
2.6 消除价值流中的困境和浪费 15
2.7 小结 16
第3章 第二步：反馈原则 17
3.1 在复杂系统中安全地工作 17
3.2 及时发现问题 18
3.3 群策群力，战胜问题获取新知 19
3.4 在源头保障质量 21
3.5 为下游工作中心而优化 22
3.6 小结 22
第4章 第三步：持续学习与实验原则 23
4.1 建立学习型组织和安全文化 23
4.2 将日常工作的改进制度化 25
4.3 把局部发现转化为全局优化 26
4.4 在日常工作中注入弹性模式 27
4.5 领导层强化学习文化 27
4.6 小结 29
4.7 第一部分总结 29
第二部分 从何处开始
第5章 选择合适的价值流作为切入点 32
5.1 绿地项目与棕地项目 34
5.2 兼顾记录型系统和交互型系统 35
5.3 从最乐于创新的团队开始 36
5.4 扩大DevOps的范围 37
5.5 小结 38
第6章 理解、可视化和运用价值流 39
6.1 确定创造客户价值所需的团队 40
6.2 针对团队工作绘制价值流图 40
6.3 组建专门的转型团队 42
6.3.1 拥有共同的目标 43
6.3.2 保持小跨度的改进计划 44
6.3.3 为非功能性需求预留20%的
开发时间，减少技术债务 44
6.3.4 提高工作的可视化程度 47
6.4 用工具强化预期行为 47
6.5 小结 48
第7章 参考康威定律设计组织结构 49
7.1 组织原型 51
7.2 过度职能导向的危害（“成本优化”） 51
7.3 组建以市场为导向的团队（“速度优化”） 52
7.4 使职能导向有效 53
7.5 将测试、运维和信息安全融入日常工作 54
7.6 使团队成员都成为通才 54
7.7 投资于服务和产品，而非项目 56
7.8 根据康威定律设定团队边界 56
7.9 创建松耦合架构，提高生产力和安全性 57
7.10 小结 60
第8章 将运维融入日常开发工作 61
8.1 创建共享服务，提高开发生产力 62
8.2 将运维工程师融入服务团队 63
8.3 为每个服务团队分派运维联络人 64
8.4 邀请运维工程师参加开发团队的会议 65
8.4.1 邀请运维工程师参加每日站会 65
8.4.2 邀请运维工程师参加回顾会议 66
8.4.3 使用看板图展示运维工作 66
8.5 小结 67
8.6 第二部分总结 67
第三部分 第一步：流动的技术实践
第9章 为部署流水线奠定基础 70
9.1 按需搭建开发环境、测试环境和生产环境 71
9.2 应用统一的代码仓库 72
9.3 使基础设施的重建更容易 74
9.4 运行在类生产环境里才算“完成” 75
9.5 小结 76
第10章 实现快速可靠的自动化测试 77
10.1 对代码和环境做持续构建、测试和集成 79
10.2 构建快速可靠的自动化测试套件 81
10.2.1 在自动化测试中尽早发现
错误 83
10.2.2 尽可能并行地快速执行测试 84
10.2.3 先编写自动化测试 84
10.2.4 尽量将手动测试自动化 85
10.2.5 在测试套件中集成性能测试 86
10.2.6 在测试套件中集成非功能性需求测试 86
10.3 在部署流水线失败时拉下安灯绳 87
10.4 小结 89
第11章 应用和实践持续集成 90
11.1 小批量开发与大批量合并 92
11.2 应用基于主干的开发实践 93
11.3 小结 95
第12章 自动化和低风险发布 96
12.1 自动化部署流程 97
12.1.1 应用自动化的自助式部署 100
12.1.2 在部署流水线中集成代码部署 101
12.2 将部署与发布解耦 104
12.2.1 基于环境的发布模式 105
12.2.2 基于应用的发布模式更安全 109
12.3 持续交付和持续部署实践的调查 112
12.4 小结 113
第13章 降低发布风险的架构 114
13.1 能提高生产力、可测试性和安全性的架构 115
13.2 架构原型：单体架构与微服务 116
13.3 安全地演进企业架构 118
13.4 小结 121
13.5 第三部分总结 121
第四部分 第二步：反馈的技术实践
第14章 建立能发现并解决问题的遥测系统 125
14.1 建设集中式监控架构 127
14.2 建立生产环境的应用程序日志遥测 129
14.3 使用遥测指导问题的解决 131
14.4 将建立生产遥测融入日常工作 132
14.5 建立自助访问的遥测和信息辐射器 133
14.6 发现和填补遥测的盲区 135
14.6.1 应用程序和业务度量指标 136
14.6.2 基础架构度量指标 137
14.6.3 显示叠加的指标组合 138
14.7 小结 139
第15章 分析遥测数据以更好地预测故障和实现目标 140
15.1 用均值和标准差识别潜在问题 141
15.2 异常状态的处理和告警 142
15.3 非高斯分布遥测数据的问题 143
15.4 应用异常检测技术 146
15.5 小结 149
第16章 应用反馈实现安全部署 150
16.1 通过遥测使部署更安全 151
16.2 开发和运维共同承担值班工作 153
16.3 让开发人员跟踪工作对下游的影响 153
16.4 让开发人员自行管理生产服务 155
16.5 小结 159
第17章 将假设驱动的开发和A/B测试融入日常工作 160
17.1 A/B测试简史 161
17.2 在功能测试中集成A/B测试 162
17.3 在发布中集成A/B测试 162
17.4 在功能规划中集成A/B测试 163
17.5 小结 165
第18章 建立评审和协作流程以提升当前工作的质量 166
18.1 变更审批流程的危险 168
18.2 “过度控制变更”的潜在危险 168
18.3 变更的协调和排程 170
18.4 变更的同行评审 170
18.5 人工测试和变更冻结的潜在危害 173
18.6 利用结对编程改进代码变更 173
18.7 消除官僚流程 176
18.8 小结 177
18.9 第四部分总结 178
第五部分 第三步：持续学习与实验的技术实践
第19章 将学习融入日常工作 180
19.1 建立公正和学习的文化 181
19.2 举行不指责的事后分析会议 182
19.3 尽可能广泛地公开事后分析会议结果 184
19.4 降低事故容忍度，寻找更弱的故障信号 185
19.5 重新定义失败，鼓励评估风险 186
19.6 在生产环境注入故障来恢复和学习 186
19.7 创建故障演练日 187
19.8 小结 189
第20章 将局部经验转化为全局改进 190
20.1 使用聊天室和聊天机器人自动积累组织知识 190
20.2 软件中便于重用的自动化、标准化流程 192
20.3 创建全组织共享的单一源代码库 192
20.4 运用自动化测试记录和交流实践来传播知识 194
20.5 通过确定非功能性需求来设计运维 194
20.6 把可重用的运维用户故事纳入开发 195
20.7 确保技术选型有助于实现组织目标 195
20.8 小结 197
第21章 预留组织学习和改进的时间 198
21.1 偿还技术债务的制度化惯例 199
21.2 让所有人教学相长 200
21.3 在DevOps会议中分享经验 201
21.4 传播实践的内部顾问和教练 203
21.5 小结 204
21.6 第五部分总结 204
第六部分 集成信息安全、变更管理和合规性的技术实践
第22章 将信息安全融入每个人的日常工作 207
22.1 将安全集成到开发迭代的演示中 207
22.2 将安全集成到缺陷跟踪和事后分析会议中 208
22.3 将预防性安全控制集成到共享源代码库及共享服务中 208
22.4 将安全集成到部署流水线中 209
22.5 保证应用程序的安全性 210
22.6 确保软件供应链的安全 214
22.7 确保环境的安全 215
22.8 将信息安全集成到生产环境遥测中 216
22.9 在应用程序中建立安全遥测系统 217
22.10 在环境中建立安全遥测系统 217
22.11 保护部署流水线 219
22.12 小结 219
第23章 保护部署流水线 220
23.1 将安全和合规性集成到变更批准流程中 220
23.2 将大量低风险变更重新归类为标准变更 221
23.3 如何处理常规变更 222
23.4 减少对职责分离的依赖 224
23.5 确保为审计人员和合规人员留存文档和证据 226
23.6 小结 228
23.7 第六部分总结 228行动起来——本书总结 229
附加材料
附 录 232
附录1 DevOps的大融合 232
附录2 约束理论和核心的长期
冲突 234
附录3 恶性循环列表 235
附录4 交接和队列的危害 235
附录5 工业安全神话 236
附录6 丰田安灯绳 237
附录7 软件包产品 238
附录8 事后分析会议 238
附录9 猿猴军团 239
附录10 上线时间透明化 240
参考资源 241
致 谢 243
EXIN DevOps Professional认证备考
指南 & 模拟题① 245
· · · · · · (收起)
读后感
本文为个人的读书笔记。 DevOps三步工作法 * 从左到右的工作流 * 从右到左的反馈流 * 持续学习与实验 康威定律：系统设计受限于组织自身的沟通结构。组织规模越大，灵活性越差。 20%的时间应该用于重构代码,改进架构，用于偿还技术债务。 将运维融入开发团队中。 将开发和运维...
本文为个人的读书笔记。 DevOps三步工作法 * 从左到右的工作流 * 从右到左的反馈流 * 持续学习与实验 康威定律：系统设计受限于组织自身的沟通结构。组织规模越大，灵活性越差。 20%的时间应该用于重构代码,改进架构，用于偿还技术债务。 将运维融入开发团队中。 将开发和运维...
本文为个人的读书笔记。 DevOps三步工作法 * 从左到右的工作流 * 从右到左的反馈流 * 持续学习与实验 康威定律：系统设计受限于组织自身的沟通结构。组织规模越大，灵活性越差。 20%的时间应该用于重构代码,改进架构，用于偿还技术债务。 将运维融入开发团队中。 将开发和运维...
本文为个人的读书笔记。 DevOps三步工作法 * 从左到右的工作流 * 从右到左的反馈流 * 持续学习与实验 康威定律：系统设计受限于组织自身的沟通结构。组织规模越大，灵活性越差。 20%的时间应该用于重构代码,改进架构，用于偿还技术债务。 将运维融入开发团队中。 将开发和运维...
本文为个人的读书笔记。 DevOps三步工作法 * 从左到右的工作流 * 从右到左的反馈流 * 持续学习与实验 康威定律：系统设计受限于组织自身的沟通结构。组织规模越大，灵活性越差。 20%的时间应该用于重构代码,改进架构，用于偿还技术债务。 将运维融入开发团队中。 将开发和运维...
用户评价
当我翻阅这本书的时候，首先吸引我的是它清晰的目录结构和逻辑严谨的章节安排。作者似乎深谙读者的心理，循序渐进地引导我们进入DevOps的世界。它从“为什么我们需要DevOps”开始，解释了传统软件开发模式的痛点，以及DevOps是如何应对这些挑战的。这一点非常重要，因为它帮助我理解了DevOps的根本出发点。书中对“版本控制系统”（Version Control Systems）的讲解，虽然看似基础，但作者却深入挖掘了它在DevOps流程中的关键作用，比如如何利用分支策略和合并请求来促进团队协作。这一点让我对Git等工具有了更深的认识。我尤其喜欢关于“持续集成”（Continuous Integration）的章节，它详细阐述了如何通过自动化构建和测试，以及频繁的代码合并，来尽早发现和解决集成问题。这对于减少“集成地狱”非常有帮助。而且，作者在讲解“持续部署”（Continuous Deployment）时，也强调了部署策略的重要性，比如蓝绿部署、金丝雀发布等，以及如何通过自动化回滚来降低风险。这本书让我感觉到，DevOps不是一蹴而就的，而是一个不断迭代和优化的过程。
这本书的内容非常充实，而且作者的讲解深入浅出，即使是对于DevOps新手来说，也能够轻松理解。我最喜欢的一点是，书中并没有直接推销某一种特定的工具，而是注重讲解DevOps背后的原理和原则，以及如何根据实际情况选择和应用合适的工具。这一点让我觉得这本书非常有价值，因为它能够帮助我们建立起一套通用的DevOps能力，而不是仅仅停留在某个工具的学习上。书中关于“监控与告警”（Monitoring and Alerting）的章节，尤其让我印象深刻。它详细讲解了如何选择合适的监控工具，以及如何设置有效的告警规则，以便及时发现和处理系统故障。这对于保障系统的稳定性和可用性至关重要。而且，作者在讲解“自动化部署”时，也强调了“可观测性”（Observability）的重要性，即不仅要能部署，更要能理解系统的运行状态。这一点让我对DevOps的理解又上了一个台阶。这本书让我觉得，DevOps的实践是一个持续学习和改进的过程，而这本书就是我们学习路上的重要指引。
这是一本让我受益匪浅的书籍。它不仅仅是一本技术手册，更是一本关于如何构建高效、敏捷、可靠的软件交付流程的指南。作者的写作风格非常流畅，而且逻辑清晰，让人读起来津津有味。我尤其欣赏书中关于“数据库变更管理”（Database Change Management）的讨论。在很多DevOps实践中，数据库的变更往往是容易被忽视的环节，而这本书却对此进行了深入的探讨，并提供了相应的自动化解决方案。这对于解决数据库部署和维护的难题非常有帮助。而且，作者在讲解“混沌工程”（Chaos Engineering）时，也让我眼前一亮。它通过有目的地引入故障来测试系统的韧性，从而提前发现潜在的风险。这是一种非常积极主动的安全和稳定性的提升方式。书中关于“微服务架构”（Microservices Architecture）在DevOps中的应用，也为我提供了新的思路。它解释了如何利用DevOps的实践来支持微服务的独立开发、部署和扩展。总而言之，这本书的知识广度和深度都令人称赞，它能够帮助我们建立起一套更全面的DevOps体系。
作为一名长期从事软件开发工作的工程师，我深知敏捷开发和持续集成的重要性。这本书在DevOps的框架下，将这些概念进行了更深层次的阐释。它不仅仅是将它们视为孤立的实践，而是将其融入到整个软件生命周期的管理中。我特别喜欢书中关于“代码质量保证”（Code Quality Assurance）的章节。它不仅强调了静态代码分析和代码审查的重要性，还介绍了如何将这些实践自动化，并集成到CI/CD流程中。这一点对于提升代码的健壮性和可维护性非常有帮助。而且，作者在讲解“基础设施自动化”（Infrastructure Automation）时，也提供了一些非常实用的技巧和方法，比如如何利用Terraform和CloudFormation来管理云基础设施。这对于需要处理多云环境的团队来说，尤其具有参考价值。书中关于“安全左移”（Shift-Left Security）的理念，也让我深受启发。它将安全检查提前到开发过程的早期阶段，从而降低了安全风险。总而言之，这本书的实践指导性非常强，它能够帮助我们更好地理解和应用DevOps。
读完这本书，我最大的感受是，DevOps不仅仅是技术，更是一种思维方式和协作模式。它打破了开发和运维之间的信息孤岛，让大家能够朝着共同的目标努力。书中关于“沟通与协作”的部分，虽然没有直接涉及技术细节，但却是我认为最核心的内容之一。作者通过生动的案例，说明了清晰的沟通、开放的心态以及跨职能团队合作的重要性。这一点对于很多习惯于各自为政的团队来说，可能需要一个较大的转变。我特别赞赏书中关于“服务虚拟化”（Service Virtualization）的探讨，它能够帮助开发团队在不依赖于真实生产环境的情况下进行测试，从而加速开发周期。这对于我们这种需要频繁发布新功能的企业来说，非常有价值。而且，书中对“配置管理”（Configuration Management）的讲解，也让我受益匪浅。作者详细介绍了Ansible、Chef、Puppet等工具的原理和应用，以及如何通过自动化配置来确保环境的一致性。这一点对于减少“环境不一致”导致的部署问题非常有帮助。这本书的价值在于，它能够帮助我们建立起一套完整的DevOps理念和实践框架。
我是一名资深的技术经理，阅览过不少关于软件开发和运维的书籍，但这本书却给我留下了深刻的印象。它所探讨的DevOps实践，并非仅仅停留在表面的工具使用，而是深入到了组织架构、团队协作以及企业文化层面。我尤其欣赏书中关于“衡量与监控”的章节，它清晰地阐述了哪些关键指标（KPIs）对于衡量DevOps的成效至关重要，并且提供了具体的量化方法。这对于我们这些需要向管理层汇报工作并证明ROI的领导者来说，是非常宝贵的参考。作者在分析“自动化测试”时，也并非简单地列举测试框架，而是强调了测试的策略性，以及如何将测试集成到整个CI/CD流程中，以确保发布的质量和稳定性。这种深度分析，让我看到了DevOps不仅仅是一种技术实践，更是一种战略性的选择。书中对“安全性”（Security）在DevOps中的融合（DevSecOps）的探讨，也是我非常看重的一部分。它将安全视为贯穿整个软件生命周期的要素，而非事后弥补，这与我一直倡导的理念不谋而合。通过这本书，我不仅巩固了对DevOps的理解，更从中汲取了许多可操作的经验，可以指导我的团队在实际工作中进行更有效的实践。它是一本值得反复品读、并与团队成员一起学习和讨论的优秀著作。
这本书的语言风格非常务实，没有那些过于高深的理论，而是直接切入到实际问题的解决。作者通过大量真实的案例，生动地展示了DevOps的价值和潜力。我尤其欣赏书中关于“事件响应与恢复”（Incident Response and Recovery）的讨论。它详细阐述了在发生故障时，如何快速有效地进行事件响应，以及如何从中吸取教训，改进系统和流程。这一点对于保障业务的连续性至关重要。而且，作者在讲解“性能优化”（Performance Optimization）时，也提供了许多实用的建议和方法，比如如何利用监控数据来识别性能瓶颈，以及如何进行代码和基础设施的优化。这对于提升用户体验和降低运营成本非常有帮助。书中对“持续学习与改进”（Continuous Learning and Improvement）的强调，也让我觉得这本书不仅仅是关于技术，更是关于一种不断进步的精神。它鼓励我们在实践中不断反思和学习，从而持续提升DevOps的水平。总而言之，这本书是一本非常优秀的DevOps实践指南，它能够帮助我们构建一个更高效、更稳定、更具竞争力的软件交付体系。
这本书的文字风格非常朴实，没有那些华而不实的辞藻，但字里行间却透露出作者深厚的实践经验。它不像一些理论书籍那样空泛，而是充满了干货。我特别喜欢书中对“容器化技术”（Containerization）及其在DevOps中的应用的阐述。作者详细解释了Docker和Kubernetes等技术是如何简化部署和管理过程的，以及它们如何支持DevOps的持续集成和持续交付。这对于我们这些需要处理复杂部署环境的团队来说，简直是雪中送炭。书中对“日志管理与分析”的讲解，也让我受益匪浅。它不仅介绍了如何收集日志，更重要的是如何对日志进行有效的分析，从而发现潜在的问题和优化点。这对于提升系统的稳定性和性能至关重要。而且，作者在讲解自动化工具时，并没有局限于某一种特定的技术栈，而是强调了通用性的原则和方法，这使得这本书具有更广泛的适用性。我甚至在书上看到了很多关于“故障排查”的技巧，这些都是在日常运维工作中非常实用的知识。总而言之，这本书给我最大的感受就是“接地气”，它能够真正帮助开发者和运维人员解决实际工作中遇到的问题。
这是一本让我眼前一亮的书，虽然我拿到它的时候，还对DevOps的很多概念模糊不清，但读完之后，感觉就像在黑暗中摸索了许久，突然被一束光照亮了前方的道路。作者并没有一开始就抛出那些令人望而生畏的技术术语，而是循序渐进地解释了DevOps的核心理念，比如打破开发和运维之间的壁垒，强调协作、自动化和持续改进。我特别喜欢它在解释“文化”转变时所使用的比喻，生动形象地说明了为什么技术工具的引入并不能自动解决所有问题，真正重要的是思维模式的改变。书中关于“反馈循环”的章节，更是让我受益匪浅，它详细阐述了如何通过持续的监控、测试和部署，快速获取用户反馈，并将其融入到产品迭代中。这不仅仅是技术层面的操作，更是对整个产品生命周期的重塑。而且，作者在提到自动化时，并没有一味地鼓吹各种工具，而是强调了“自动化是为了解决特定问题而服务的”，这让我避免了陷入“为了自动化而自动化”的误区。对于我这样的初学者来说，这本书就像一位经验丰富的引路人，不仅指明了方向，还提供了清晰的路线图，让我能够更有信心地踏上DevOps的学习之旅。我甚至在读完这本书后，开始在团队内部推动一些小范围的DevOps实践，虽然还处于摸索阶段，但已经感受到了协作效率的提升，这让我对这本书的价值有了更深切的体会。它不是那种读完就丢的书，更像是一本需要反复翻阅、随时参考的工具书，每次重读都会有新的收获。
老实说，一开始抱着试一试的心态翻开这本书，毕竟市面上关于DevOps的书籍琳琅满目，但真正能做到既有深度又不失易读性的却不多。这本书在这一点上做得相当出色。它不仅仅是罗列了一堆技术名词和实现方法，而是从更宏观的角度，深入剖析了DevOps的“为什么”和“如何做”。我尤其欣赏其中关于“流程优化”的章节，作者通过实际案例，生动地展示了如何识别现有流程中的瓶颈，以及如何利用DevOps的原则来打破这些瓶颈。这种分析问题的思路，对于理解DevOps在企业中的实际应用价值至关重要。书中关于“基础设施即代码”（Infrastructure as Code）的论述，也让我对自动化运维有了全新的认识。它不仅仅是编写脚本，更是将基础设施的管理纳入到版本控制和持续集成/持续部署的流程中，这极大地提高了基础设施的可管理性和可重复性。作者在讲解这些概念时，并没有回避其中的复杂性，而是通过清晰的逻辑和图示，帮助读者逐步理解。我印象最深的是，书中在介绍“持续交付”时，强调了“小步快跑”的理念，以及如何通过自动化测试和回滚机制来降低发布风险。这一点对于很多传统企业来说，可能是颠覆性的认知，但也正是DevOps能够带来的巨大价值所在。这本书的内容组织非常合理，从基础概念到高级实践，层层递进，让读者能够建立起完整的知识体系。
不错的入门读物，覆盖面挺广，最有用的是讲了好多案例
不错的入门读物，覆盖面挺广，最有用的是讲了好多案例
【2020 读书】33: 第二本devops快速的翻过，CI的部分都体验过了，CD的部分所以做desktop产品的我还没机会体验。其中有两点印象深刻：20%的时间应该用来做看不到business value的东西（tech debt，就像胶水一样吗！哈哈哈）另外一点就是pair programming产出比single dev自己做会低15%产出，但是代码“无错率”从70%提升到85%，很重要的一点是debug太花时间，尤其是十几年的老项目，有时候看懂那些老古董就要一整天！所以综合来看pair programming一定是个很棒的方式。
重新读了遍，里面的三步工作法和具体的实践有一定的参考学习价值。对于实际的转型，还是要因地制宜，在团队中深入调查后再制定阶段性目标。 剩下的事情就看执行力了。
