1.为什么要学《DevOps实践指南》

《Devops实践指南》(The DevOps Handbook) 这本书有多经典呢？我总结了一下这本书的主要特点供大家参考。

• 作者均是业界翘楚
  • Gene Kim

Tripwire创始人、前CTO，IT Revolution创始人，DevOps企业峰会主办人。畅销书《凤凰项目》合著者，没错就是那本我个人为的IT类最佳小说，其中的主人公遇到了我们平时遇到的所有困难和问题，建议大家可以读读。《DevOps实践指南》又称为《凤凰项目》姊妹篇。

• Jez Humble

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

• • Patrick Debois

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

• • John Willis

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

 

• 是EXIN DevOps认证体系的官方重点推荐的参考书
• 豆瓣评分8.3，其中82.5%的读者给出5星或4星的评价。
• 可读性强，很贴近实际工作，是入门DevOps的经典书籍

这本书带着如此多的光环，那它到底有何奇妙之处呢。带着满心好奇与期待让我们再一次踏上学习生涯吧… …

先送个福利，下图为DevOps实践指南的思维导图，可以一览全局，让你有一种掌控全书知识点的感(cuo)觉(jue) ????。

这是它的主要知识体系

然后这是它全部展开的样子

2.学习《DevOps实践指南》引发的思考

个人特别喜欢一句话，读一本书最重要的不是学到了多少知识，而是看它能引发你多少思考。我所有的思考点基本上都会围绕着我们在  HCC  的实际工作展开。在学习的过程中也会不断用实际的工作案例去印证书中的理论知识和实践技能，往往会有醍醐灌顶的感觉。

以下分享均来自于我个人的浅薄认知和思考，权当抛砖引玉，如有不当之处欢迎指正。

 

2.1 DevOps是什么

DevOps是什么？是传说中的持续交付与持续部署吗，是自动化测试技术吗，是开发运维一体化的工作实践吗？

特别有意思的是，《DevOps实践指南》全书都没有给出一个明确的“DevOps”的定义。几位作者很诚实，他们每个人对DevOps的认知都不太一样，所以干脆就不给定义，不让具体的文字框住大家对DevOps的认知。于是，当目前为止，虽然世界上有这么多人这么多公司在实践DevOps文化，也都没有人给出一个具体的定义。维基百科倒是给DevOps归纳了三个特点

• DevOps 是一种强调沟通与协作的软件交付过程。它包括产品管理，软件开发及运营等各个方面。
• DevOps 自动化软件集成，测试，部署以及基础设施的变更。
• 它的目标是建立一种文化和环境，使得软件的构建、测试、交付更快，更频繁，更可靠。

目前我个人对DevOps的认知为：

DevOps = Culture（文化） + Practice（实践）

文化是根本。《DevOps实践指南》中重点强调了要在组织中建立学习型组织和安全文化（4.1），强调了领导层强化学习文化（4.5），强调了建立公正和学习的文化（19.1）。学习文化不仅仅是知识的学习，更强调了在快速流动，快速反馈的环境下，不断的总结经验从而达到持续学习持续改进的目的。

实践是体现。所有高层级的思想都要落实到具体的实践、工具、技术上才能发挥它最大的作用。《DevOps实践指南》中推出了著名的工作三步法并且还难能可贵的用大量的篇幅为每一步工作法提供了大量的技术实践作为支撑，即

• 第一步 流动原则，对应全书第三部分 流动的技术实践
• 第二步 反馈原则，对应全书第四部分 反馈的技术实践
• 第三步 持续学习与试验原则，对应全书第五部分持续学习与试验的技术实践

这也是这本书的良心所在，不仅给你方法论和思想，还给你具体的解决方案。既授之以渔，又授之以鱼。

 

2.2 DevOps和Agile的关系

众所周知，我们大捷信正在轰轰烈烈地搞敏捷转型，那敏捷和DevOps之间又有什么关联呢？是不是搞敏捷就不用再搞DevOps了，或者说它俩根本就是一回事？

通过学习《DevOps实践指南》并且参考Microsoft Azure官网上的DevOps知识，总结如下：

	DevOps	Agile
理念和关注点	DevOps 文化基于稳定性、一致性和规划，旨在确定新的方法来改进和简化流程。因此，DevOps 专注于最大限度地提高效率，识别可编程流程以及提高自动化程度	敏捷的快速失败思维方式，中心是适应性以及与客户需求和期望保持同步。将功能描述为用户情景，重点关注个人用户及其需求和产生这些需求的原因。
范围	DevOps 代表开发，运营和质量保证的交叉点。跨学科团队在软件的开发和交付过程中团结协作。	敏捷开发特定于开发团队、其工作效率以及完成手头项目的进度。开发在增量冲刺 (sprint) 中完成，每个版本的软件交付、部署或持续维护由不同的团队管理。
表现形式	持续集成 持续交付 连续部署	Scrum 看板 精益开发 DSDM 极限编程 Crystal 功能驱动开发

 

总结：尽管 DevOps 和敏捷两者的侧重略有不同。但DevOps 和敏捷完全可结合使用以创建高效的软件开发环境。

其实对我们而言，无论是DevOps还是Agile，或者您可能还听过Design Thinking，Lean Startup等众多特别fashion的词汇，种种的这些无非是各自的提出者结合他们自身的认知创造出来的一套理论和相应的实践方法。对于我们来说，没必要纠结一定要用哪套思想和实践，因为他们本来就有大量的overlap，想多了也容易走火入魔。我们能做的就是多学习他们各自实践方案的优缺点和适用范围，然后结合我们自身的工作适当的选择，裁剪，优化成适应我们自己的技术方案即可。比如我们可以采用Agile当中的Scrum框架来进行团队管理，也可以用DevOps CI/CD方案来实践持续集成和持续部署。

 

2.3 DevOps该如何实践

《DevOps实践指南》通过三步工作法给出了非常具体的实践方案。结合自身的工作经验，尤其在技术领域，我们可以（并且已经）在多个方面开展DevOps具体实践。比如

质量内建：采用TDD即测试驱动开发思想，让测试左移；通过结对编程和代码审查机制，保证代码质量；提高自动化测试覆盖率，保证测试用例质量。

CI/CD：引入持续集成与持续部署，每次提交代码均可以实现自动化集成，测试与部署。

持续反馈：持续集成反馈，对代码构建质量，代码质量审查的反馈；测试反馈，对软件质量，功能性的测试，给到业务的反馈；运营数据反馈，新功能上线后对业务影响的反馈，用于指导业务人员提新的需求。

架构松耦合：对传统应用架构进行领域组件化，容器化，微服务化，提升可测试性和可部署性。

创建学习型组织：举行不指责的事后分析会议；鼓励验证性学习；成立主题化学习兴趣小组；成立专门的DevOps研发团队；重点培养人才。

 

3. 总结

一本书，可能不会解决我们实际工作中遇到各种问题，但总能给我们带来些许思考。以上是我通过学习《DevOps实践指南》一书引发的部分思考，与大家分享。希望借此和更多对DevOps感兴趣的同学组建一只DevOps兴趣小组，我们一起持续学习，持续实践，持续进步。