335页DevOps实践指南，全面系统，零基础也能读懂

　　一提DevOps，大家都不会感到陌生。近年来DevOps 频频出现在各大技术社区和媒体的文章中，备受业内人士追捧。那么DevOps该怎么学怎么用呢？
　　今天给大家整理的这份DevOps实践指南，很好的解释了从启动到实现所必需的理论、原则， 适合新手快速入门 。 同时，它结合了 48个著名公司的实践案例，可操作性很强。
　　对于想理解、解释和实现DevOps文化、流程和工具，来达成 高性能运维 的任何人而言，这份指南都是不二之选。
　　【领取方式见文末！！】
　　【领取方式见文末！！】
　　第一部分 DevOps介绍 第 1 章 敏捷、持续交付和三步法 第 2 章 第一步：流动原则  第 3 章 第二步：反馈原则  第 4 章 第三步：持续学习与实验原则
　　（资料来源于网络，版权归原作者所有，侵删）
　　第一步：流动原则
　　通过持续加强工作内容的可视化，减小每批次大小和等待间隔，内建质量以防止缺陷向下游传递，从而增强流动性。通过加速技术价值流的流动，可以缩短满足内部客户和外部客户需求的前置时间，进一步提高工作质量，并使我们更加敏捷，能够比竞争对手更为出色。
　　第二步：反馈原则
　　通过在整个价值流和组织中建立快速、频繁、高质量的信息流，包括反馈和前馈回路，可以让系统更安全。这样，就可以在规模较小、修复成本较低的情况下发现并修复问题，在灾难发生前消除问题，并创造出组织性学习氛围。
　　第三步：持续学习与实验原则
　　技术价值流的核心是建立高度信任的文化。它强调每个人都是持续学习者，必须在日常工作中承担风险；通过科学的方式改进流程和开发产品，从成功和失败中积累经验教训，从而识别有价值的想法，摒弃无用的想法。另外，所有局部的经验都会快速转化为全局性的改进，从而帮助整个组织尝试和实践新技术。
　　第二部分 从何处开始  第 5 章 选择合适的价值流作为切入点  第 6 章 理解、可视化和运用价值流  第 7 章 参考康威定律设计组织结构  第 8 章 将运维融入日常开发工作
　　选择合适的价值流作为切入点
　　选择合适的价值流进行 DevOps 转型，这一工作值得仔细斟酌。它不仅决定了转型过程的难度，而且还决定了转型过程的参与者；它不仅影响到如何组建团队，而且还影响到如何让团队及其成员以最佳方式参与其中。
　　（资料来源于网络，版权归原作者所有，侵删）
　　理解、可视化和运用价值流
　　一旦确定要应用 DevOps 原则和模式的价值流后，就要深刻理解如何向客户交付价值：做什么工作？谁来做？该采取什么措施改善流程？
　　参考康威定律设计组织结构
　　软件的架构和软件团队的结构是一致的，说白了就是‘如果让 4 个团队开发同一个编译器，那么编译器最后会有 4个执行阶段’。
　　将运维融入日常开发工作
　　通过使开发团队拥有更强的运维能力，可以以市场为导向创造出更多的业务成果，并能最终提高效率和生产力。
　　第三部分 第一步：流动的技术实践  第 9 章 为部署流水线奠定基础  第 10 章 实现快速可靠的自动化测试  第 11 章 应用和实践持续集成  第 12 章 自动化和低风险发布  第 13 章 降低发布风险的架构
　　为部署流水线奠定基础
　　在理想情况下，应该使用脚本和存储在版本控制系统中的配置信息按需搭建，而不需要依赖运维团队进行手动操作。部署流水线的目标就是能够基于版本控制系统中的信息重复搭建整套生产环境。
　　（资料来源于网络，版权归原作者所有，侵删）
　　实现快速可靠的自动化测试
　　如果没有自动化测试，那么我们编写的代码越多，测试代码所花费的时间和金钱也会越多。在大多数情况下，这种商业模式对于任何技术组织而言都是无法扩展的。
　　应用和实践持续集成
　　集成问题会导致大量的返工，包括不得不通过手动合并解决变更冲突，以及多名开发人员共同解决导致自动化测试或手动测试失败的合并问题。
　　自动化和低风险发布
　　Faceb**k 通过采用持续集成和低风险的代码部署流程，把代码部署变成了所有人的日常工作，并且维持了开发人员的生产力。这要求代码的部署操作是自动化、可重复和可预测的。
　　降低发布风险的架构
　　＂任何成功的产品或公司，其架构都必须在生命周期里不断演进。＂Randy Shoup 在加入谷歌以前，曾在 2004～2011 年期间担任 eBay 的首席工程师和架构师。他曾说：＂eBay 和谷歌都曾自上而下地把整个架构进行了 5 次重构。＂
　　第四部分 第二步：反馈的技术实践  第 14 章 建立能发现并解决问题的遥测系统  第 15 章 分析遥测数据以更好地预测故障和实现目标  第 16 章 应用反馈实现安全部署  第 17 章 将假设驱动的开发和 A/B 测试融入日常工作  第 18 章 建立评审和协作流程以提升当前工作的质量
　　建立能发现并解决问题的遥测系统
　　为了能训练有素地解决问题，我们需要设计出能够持续遥测的系统。遥测被广泛定义为＂一个自动化的通信过程，先在远程采集点上收集度量数据，然后传输给与之对应的接收端用于监控＂。目标是在应用及其环境中建立遥测，包括生产环境、预生产环境和部署流水线。
　　（资料来源于网络，版权归原作者所有，侵删）
　　分析遥测数据以更好地预测故障和实现目标
　　通过实施服务器异常检测的流程，Netflix ＂大大地降低了识别故障服务器的成本，更重要的是还大大地缩短了修复时间，提高了服务质量。利用这些技术来保持员工的理智，保持工作和生活的平衡，以及保持服务质量，其所带来的益处再怎么强调都不为过＂。
　　应用反馈实现安全部署
　　建立了快速的端到端的反馈回路来帮助强化组织学习，鼓励主动提升客户满意度和功能表现，进而帮助我们取得成功。
　　将假设驱动的开发和 A/B 测试融入日常工作
　　一项极其强大的用户研究技术是定义客户获取渠道并执行 A/B 测试。A/B 测试技术是在直效营销中率先使用的，它是两大类营销策略之一。另一类称为大众营销或品牌营销，通常通过向公众投放尽可能多的广告来影响人们的购买决策。
　　建立评审和协作流程以提升当前工作的质量
　　按照传统的做法，当我们评审将要部署的变更时，往往主要依赖部署之前的评审、审核和审批环节。审批者通常来自外部团队，他们对实际工作不了解，所以其实无法准确评判变更是否有风险，而且为了获得全部必要的审批需要花费不少时间，这进一步延长了变更的交付时间。
　　第五部分 第三步：持续学习与实验的技术实践  第 19 章 将学习融入日常工作  第 20 章 将局部经验转化为全局改进  第 21 章 预留组织学习和改进的时间
　　将学习融入日常工作
　　学习型文化的先决条件之一是，当发生事故时（这是毫无疑问的），对待它的反应要＂公正＂。
　　（资料来源于网络，版权归原作者所有，侵删）
　　将局部经验转化为全局改进
　　在整个组织的全局范围里共享和应用局部获得的新经验和优化方法，从而大大提高组织的全局知识和改进效果。这将提升整个组织的实践状态，使每个人都在工作中从组织积累的经验里受益。
　　预留组织学习和改进的时间
　　有一种称作改善闪电战（improvement blitz 或 kaizen blitz）的实践，是丰田生产系统的重要组成部分，指的是在一个专门集中的时间段里解决特定问题，通常长达几天。
　　第六部分 集成信息安全、变更管理和合规性的技术实验  第 22 章 将信息安全融入每个人的日常工作  第 23 章 保护部署流水线
　　将信息安全融入每个人的日常工作
　　一直以来，实施 DevOps 原则和模式的最大阻碍就是＂信息安全和合规性不允许＂。然而，在技术价值流中，要将信息安全更好地集成到每个人日常工作中去，DevOps 可能是最佳的一个方式。
　　（资料来源于网络，版权归原作者所有，侵删）
　　保护部署流水线
　　如果正确构建了部署流水线来降低部署风险，那么大部分变更就不需要经过手动审批流程了，因为我们将依赖于自动化测试和主动生产环境监控等控制措施。
　　对 运维人 来说，这是一本 切合实际，实用性很强，具有指导意义 的指南，认真读完它，相信你一定会受益匪浅！
　　【领取方式见下图！】