导读：本篇文章首席CTO笔记来给大家介绍有关devops看什么书的相关内容，希望对大家有所帮助，一起来看看吧。
SRE和DevOps
DevOps 和 SRE 似乎是同一枚硬币的两个面。他们都旨在弥合开发团队和运维团队之间的鸿沟，都想要提高软件部署的效率和软件运行的可靠性。
DevOps 的定义是“一种软件工程文化和实践，旨在统一开发和运维” 。这个术语最初是由 Andrew Shafer 和 Patrick Debois 于2008年创造的，虽然花了几年时间才成为一个通用概念，但如今，几乎每个企业都在使用 DevOps。
Site Reliability Engineer(SRE) 的概念自2003年以来一直存在，比 DevOps 还要古老。它是由创建 Google 的本·特雷诺（Ben Treynor）创造的。根据 Treynor 所说，SRE 是“软件开发工程师开始承担运维人员的任务”。
DevOps 和 SRE 都倡导自动化和监视，其目标都是减少从开发到部署生产中的时间，同时又不影响代码或产品的质量。Google 指出，SRE 和 DevOps 彼此之间并没有太大区别：“在软件开发和运维方面，他们不是竞争关系，而是旨在打破组织障碍，使得更快地交付更好的软件的亲密朋友。”
DevOps 只是关心需要做什么，但 SRE 却谈到了如何可以做到。SRE 是通过使用正确的方法，工具等将理论部分扩展为有效的工作流程。这还涉及在每个人之间分担责任，并使每个人都具有相同的目标和愿景。
《DevOps实践指南》pdf下载在线阅读全文，求百度网盘云资源
《DevOps实践指南》百度网盘pdf最新全集下载:
链接:
?pwd=rgds 提取码: rgds
简介：本书共分为6个部分：靠前部分概述DevOps的历史和三个基本原则，即“三步工作法”；第二部分介绍开启DevOps转型的过程；第三到五部分深入探讨“三步工作法”的各个要素；第六部分关注如何将安全性和合规性正确集成到日常工作中。全书涵盖40余个DevOps案例，以谷歌、Facebook等优选企业和组织的实际调查结果为依据，展示如何通过现代化的运维管理提升管理效率，进而为企业赢得更大市场、创造更多利润。
《The Dev Ops Handbook》txt下载在线阅读全文,求百度网盘云资源
《The DevOps Handbook》（Gene Kim）电子书网盘下载免费在线阅读
链接:
提取码: 7jup
书名：The DevOps Handbook
作者：Gene Kim
豆瓣评分：8.3
出版社：IT Revolution Press
出版年份：2016-10-6
页数：480
内容简介：
Increase profitability, elevate work culture, and exceed productivity goals through DevOps practices.
More than ever, the effective management of technology is critical for business competitiveness. For decades, technology leaders have struggled to balance agility, reliability, and security. The consequences of failure have never been greater―whether it's the healthcare.gov debacle, cardholder data breaches, or missing the boat with Big Data in the cloud.
作者简介：
Gene Kim is a multiple award-winning entrepreneur, the founder and former CTO of Tripwire and a researcher. He is passionate about IT operations, security and compliance, and how IT organizations successfully transform from "good to great." He lives in Portland, Oregon.
Jez Humble is an award-winning author and researcher on software who has spent his career tinkering with code, infrastructure, and product development in organizations of varying sizes across three continents. He works at 18F, teaches at UC Berkeley, and is co-founder of DevOps Research and Assessment LLC.
《DevOps实践指南》pdf下载在线阅读，求百度网盘云资源
《DevOps实践指南》（[美] Gene Kim）电子书网盘下载免费在线阅读
链接：
提取码：tq8l
书名：DevOps实践指南
作者：[美] Gene Kim
译者：刘征
豆瓣评分：8.5
出版社：人民邮电出版社
出版年份：2018-4
页数：328
内容简介：
本书共分为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公司。
为什么DevOps的必然趋势是BizDevOps
编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：，下载完整版电子书，了解阿里十年DevOps实践经验。
本文作者：何勉，阿里云云效资深技术专家
谈到DevOps，就必须从敏捷和精益开发说起。DevOps在它们基础上发展而来，借鉴了其中的方法、理念，并发展和完善了它们的实践体系。
敏捷软件开发的实践最早出现在上世纪90年代。当时，一批轻量的软件工程方法和框架相继诞生，它们共同的特点是，相对传统软件工程，都遵循演进和迭代的模型，过程更加轻量灵活。其中Scrum和极限编程（ExtremeProgramming）在实践上最为成功，影响最大。它们都是迭代和增量的软件开发框架，区别是Scrum只包含管理实践，而极限编程则同时涵盖工程和管理实践。
上世纪90年代，PC软件流行和第四代编程语言的出现，面向对象和设计模式运动的兴起，让小型项目的开发蓬勃发展。同时，互联网应用和开源社区兴起，有别于传统的开发模式不断涌现，优秀个人在程序开发中的作用得到凸显。
这些因素都让非传统开发方法有了实验的土壤。其结果是，一方面质量问题层出不穷，这部分促使了源自全面质量管理体系的CMM/CMMI在这一时间的繁荣和推广；另一方面也产生了许多不同于传统方法的有效实践，让业界看到了新的可能。敏捷运动这时已经呼之欲出，它既是对传统的反叛，也是对野蛮生长的规范。
2001年2月，17位轻量级软件工程方法的代表人物，齐聚美国犹他州的雪鸟滑雪胜地，其中也包括Scrum和极限编程的几位发明人。在两天的会议之后，发布了后来产生巨大影响的敏捷宣言(参见 )，敏捷宣言陈述了他们共同认可的关于软件的开发方法的理念，同样重要的是他们找到了敏捷这个词来总领这些理念。
敏捷概念在2001年出现，可以说适逢其时。当时，一方面传统方法变得越来越臃肿笨重，却没有解决软件危机；另一方面，人类正在进入互联网时代，软件业对响应变化和创新的要求迅速升级，这是更根本的原因，毕竟需求才是行业发展的最好助推剂。
敏捷宣言发布后，敏捷成为了一场运动，被迅速地推广和应用。但是，早期的敏捷专注的还是研发交付阶段，站在业务的角度，它的目标是帮助产品和研发团队提升敏捷响应能力，也就是：“更早地交付价值，更灵活地应对变化”。然而，在企业数字化转型的背景之下，IT不仅要保证产品的开发和交付，系统部署和运行同样重要。DevOps继承了敏捷开发的理念，又补上了运维的部分，但DevOps绝不是开发和运维的简单叠加，这个我们后面还会说到。
精益思想最早源自生产制造领域，根源于丰田在产品制造中管理和工程实践。1988年《斯隆管理评论》的一篇论文《精益生产系统的胜利》比较了西方的生产方式和丰田生产方式在效率和质量上巨大差距，挑战了规模生产带来效益的神话。从此，精益开始进入西方的视野，逐渐成为现代管理学的重要组成部分。
《精益思想》一书将精益定义为：有效组织人类活动的一个新的思维方法，目标是消除浪费，以更多地交付有用的价值。书中进一步总结了精益的5个原则，同时也是精益的5个实施步骤：
在这个抽象层次上，精益思想超越了其诞生的制造业，深刻影响了各个行业，如精益政务、精益医院、精益领导力、精益服务业、精益供应链、精益教育等，这其中也包含产品开发。事实上，主流的敏捷开发方法都直接受到了精益思想的影响，遵循精益的基本原则。
与此同时，精益产品开发作为独立的实践体系也快速发展，它聚焦两个方面的目标——价值交付过程和价值本身。
精益创业认为创业是一个巨大不确定的过程，其最大的浪费是交付没用的（不能解决用户问题，或带来业务成功）的东西。为此它把价值的 探索 和发现融入产品交付过程，提出了著名的“开发-测量-学习”循环。循环从关于市场和产品的待检验概念开始。接下来，循环的第一步是开发用以验证这一概念的最小可行产品（MVP，Minimal Viable Product）；第二步：基于最小可行产品收集市场、用户的反馈，并获得测量数据；第三步：用数据验证假设，证实或证伪它们，并加以调整，产生经实证的认知。然后，进入下一循环，持续 探索 商业模式和产品功能设计。
精益创业的影响远超初创公司，事实上“精益创业”一书中把“创业”定义为在不确定的环境下，开创新的业务和产品。而“不确定性”似乎已成为今天IT领域身处环境的共性，也因此，MVP、“开发-测量-学习”循环等理念已成为IT创新领域公认的实践，并且围绕精益创业发展出一套完整的创新实践体系，如精益数据分析、精益客户开发、精益交付设计等。
探索 和发现有效的价值，并让价值顺畅流动。围绕这两个目标，并遵循精益思想，精益产品开发已经发展成为系统的实践。精益思想对DevOps的影响也非常根本，DevOps三原则就完全遵循了精益思想。
在传统的IT组织下，开发团队（Dev）和运维团队（Ops）之间诉求不同——开发团队（尤其是敏捷团队）追求变化，运维团队追求稳定。双方往往存在利益的冲突，比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于IT价值的最大化。
2009年，在美国举行的第二届Velocity大会上，来自Flickr公司的John Allspaw和Pauk Hammond发表了一个演讲《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》。在这个演讲中，Allspaw和Hammond以角色扮演的方式，生动地表现了开发与运维之间的各种冲突。演讲中出现很多金句，如“It's not my code, it's your machines!”，这深刻反映了Dev和Ops关系的现状。接着，他们又展示了如何通过消除开发团队（Dev）和运维团队（Ops）的壁垒，双方通力合作，借助工具和文化的改变让软件的发布和运维变得持续和高效。
这次演讲是DevOps发展历程中的标志性事件。它提出了正确的问题——为了更快交付和实现价值，必须弥合开发和运维之间的鸿沟，并给出了解决方案——为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革。
同一年，比利时独立IT咨询师Patrick Debois看到这个演讲，受到启发，组织了第一届DevOpsDays，DevOps正式登上舞台，DevOps的理念开始流行，其相关的工具和实践也快速发展。期间以容器化和自动编排调度为代表的云原生技术的出现也极大加速了这一进程。今天，DevOps已成为企业数字化的核心能力之一，是对IT交付和运行的基本要求。
其后，在《凤凰项目》和《DevOps实践指南》两本书中，Gene Kim等人总结了DevOps实施的三步工作法，它们分别是:
流动原则：聚焦IT系统的整体价值流，全局优化，保证价值从左（上游）到右（下游）的快速流动。
反馈原则：创建从左到右的反馈循环，并缩短反馈周期和放大反馈效果。这样，就可以更快的响应和理解内外部客户，并即时获取改进所需要的知识。
持续的实验和学习原则：创建承担风险、持续实验并从错误中学习的文化，在不断的尝试中精进能力，并提高系统的韧性。
Kim等人认为，这三步工作法是其他一切DevOps流程、实践的价值和哲学根基，所有DevOps模式都可以从这三个原则派生而来。
稍作探究，就能够觉察，DevOps三步工作法是精益原则的翻版。更确切的讲，是精益原则在IT开发和运行上下文中的具体实例。事实上，DevOps的基础部分，体现了精益原则的影响和应用。
回顾敏捷、精益和DevOps的发展，我们可以得出如下两个结论。
第一，DevOps 是敏捷开发实践的自然发展。敏捷开发的目标是“更早地交付价值，更灵活地应对变化”。敏捷运动始于开发侧，但运维侧如果不做改变，就一定会成为瓶颈，最终敏捷的目标还是无法达成。为了让敏捷实践发挥真正的价值，开发运维的联动就势在必行了。
第二，DevOps是精益思想应用在IT领域的必然结果。精益产品开发的目标是：“顺畅的交付有效价值”，精益思想则要求端到端的系统优化和持续的改进。而开发和运维是系统的两个重要组成部分，缺一不可。DevOps三原则，正是精益思想在IT开发运维领域的具体实例。
最后，从精益思想出发，我们可以看到DevOps的必然发展方向，那就是向业务侧延伸。业务是产品开发和运维的源头，完整的价值流必须从源头开始。这不是预测，而是正在发生的事实，大部分DevOps的实施都已经将业务侧包含在内，成为BizDevOps，只不过DevOps的称谓已经深入人心，我们也将延续DevOps的说法，但缺省情况下，它包含了业务在内。
DevOps发展的同时，数字化转型也成为了企业界的共识，大部分企业数字化框架都把DevOps作为最核心的能力之一，DevOps的影响范围也不断扩大，成为力求提升数字化能力的企业必然选择。下一节我们将在数字化转型这一背景下，分析DevOps要解决的根本问题。
「链接」
大型企业实施 DevOps 的三个阶段
DevOps时代 发表于 DevOps时代的专栏
估计阅读时间12分钟
《DevOps 实施手册》介绍
现在开始我的分享，大家有这样一个感觉，现在技术发展的太快了，技术还没有普及就被淘汰了。在这样一个浮躁的时代我为什么翻译《DevOps 实施手册》这本书呢？因为在《DevOps实施手册》里研究的都是长久以来一直有效的理论，比如像福特汽车的生产流水线，像丰田的精益生产，还有敏捷开发思想。这些思想并不是近期出现的。
2009年，在这些思想的基础之上 DevOps 应运而生，让开发与运维甚至是运营之间的协作更加高效，希望这本书能够帮助到正在做 DevOps 转型的企业，解决数字化转型过程中遇到的实际问题。本书独家介绍了自上而下的 DevOps 实践（企业级），如何让领导者和参与到 DevOps 变革中，后面会进行详细的介绍。
另外一类是自下而上的 DevOps 的实践（团队级），还包含了如何让组织自发产生新实践的组织模型。
消费改变需求实现方式
我们开始今天的主题，首先，按照以往的经验，实施 DevOps 一定会提高生产效率，降低产品成本。如果成本足够低，就应该占领大部分市场，这个假设是正确的吗？下面有一个例子：
福特汽车在1914年引进了流水线技术，将一台汽车的成本做到 7000 块钱（一台IPhone），和手机一样的价钱，市面上有90%的汽车都是由福特生产的。如果事情按照这个逻辑发展下去，几年后福特将会统一汽车市场。
六年之后，流水线优化，每十秒钟就能生产一辆汽车，成本降到了2000元（一台小米手机）花一台小米手机的钱就能买一辆汽车。当时创始人老福特的有一个笑话，他说：“我的客户可以选择任意一种颜色的汽车，只要它是黑色的。”
实际情况是客户只能选择黑色的T型车。为了每10秒生产一辆汽车，只有黑色的油漆干燥的速度才能达到要求，所以生产的汽车都是黑色的。在随后的六年时间里，效率提升和成本降低做到了极值，但结果是订单远远低于了产量，生产出来的汽车只能积压在仓库里。
当汽车变成代步工具，同质化的T行车无法满足用户定制化的需求，因此通用汽车用不同颜色和配置的汽车和更高的售价，占领了个性化汽车市场，从而打败了福特汽车。这个案例证明只提高效率降低成本并不能统一市场，只有满足用户需求的产品才能生存。
当我们选择汽车的时候，如果我已经拥有了廉价T型车，下一个辆要买什么样的车呢？不再是 2000 元的同质化的代步工具，而是根据自己的喜好选择不同颜色和配置的汽车，哪怕是价格稍微高一些。通用汽车适时的推出了个性化汽车占领了汽车市场。
大部分的汽车点评网站都会把汽车按照价格分为以下几种，有5万元的汽车，有10万元的汽车，还有30万以上的汽车，这些不同的汽车为什么定这个价格，人们购买的是什么？
比如说5万的的汽车，做到了基本代步工具应有的功能（有座椅，可以遮风挡雨，重点是可以开），如果满足更高的需求，比如更强的动力，更大的空间，一边开车一边听听音乐，这一类是期望的需求，这样需求得到满足用户的满意度会直线上升。
还有另外一种就是兴奋型需求，比如我想买有自动泊车功能的，还有如果我手里拿着刚买的一堆东西，想放到后备箱里，只要脚在后备箱下面一滑，后备厢门就自动打开了，这就满足是特殊场景的需求。
再或者有自动驾驶的功能，车辆会把孩子按照导航制定位置送到幼儿园（在美国法律下的特斯拉可以做到）。简单的来说兴奋型需求就是黑科技。
用户的需求分为基本需求，期望需求和兴奋需求，因为不同的需求而购买产品的客户表现出很大的差异，而为了满足不同需求，对企业能力的也是不一样的，接下来看一下为了满足不同需求，要做哪些方面的设计和考虑。
为了满足期望型需求（定制化需求），厂商需要进行客户调研，使用组件方式批量生产，高效地满足定制化需求，达到快速高效的推出新产品的目的。 对于定制化软件产品使用将产品拆分为组件，通过对部分组件定制化开发高效满足定制化软件的需求。
为了满足基本需求（固定需求），厂商需要严格控制风险，减少新产品失败的可能性，通过流程固化部门协作，提高部门内部的效率，来降低成本。对于满足基本类型需求的软件产品，需求主要是短期内不会变化的协议和标准。提升竞争力的方法类似于T型车，不断优化流水线提高效率降低成本。
为了满足兴奋性需求（黑科技），厂商需要了解用户使用产品的场景和情绪，比如说像用脚在后备箱下面滑一下就能打开后备厢门，对于黑科技的软件产品，需要了解用户使用产品时的行为和情绪变化。
就像现在的电商网站，在用户浏览和购买产品时，记录用户行为（经常浏览商品种类，购物车内产品等等），从而判断用户喜好。在了解用户购买偏好后，提高推荐商品的购买成功率。
对于基本需求，就像买水买电和石油都一样，产品没有本质差别，只要便宜就好了，不断提高效率，降低成本，就像T型车不断优化流水线一样。
对于满足期望需求的软件企业，我亲身经历过这样一个案例，在十多前，我在一个通讯公司里，研发部门的产品是支持内部业务的IT系统，同时也对运营商销售企业内部使用的IT系统。这样的研发的模式中有一个业务分析（BA）的角色，定期去拜访客户了解客户业务和对软件的需求，然后对部分组件进行定制化开发。
这样的组织有两种研发模式：通用组件的研发和定制组件的研发。研发团队工作模式和对工程师的能力要求是完全不一样的。通用组件的团队注重软件执行效率和通用性，而定制化团队专注于实现业务需求。
从总体上说提高组件复用率，减少定制开发工作量降低总体成本是优化的方向。
谈到兴奋型需求，需要感知用户的行为和情绪，传统企业不直接面对个人消费者很难感知到客户情绪，但是对于有大量用户行为数据和互联网公司却可以做到。在用户使人某个功能不顺畅，导致用户不再使用，这种用户行为就表现出客户情绪的不满。了解用户用使用产品或服务的场景，感知使用过程用户情绪的变化，才有可能作出让客户惊喜的功能，甚至是黑科技。
最近我和一位BAT工作的前同事聊到短视频应用产品，他把内部产品和抖音做对比，过程是观看30条短视频，对某一类型的视频反复观看。结果是抖音可以识别出用户对这类视频的偏好，反复推荐类似的内容，而内部的产品却没有任何改变。通过算法和大量用户使用数据对产品或服务进行优化，明显提升了产品的竞争力。
满足三类不同的需求，需要具有不同的企业能力。从满足定制化需求的企业（通过用户调研，生产出相对便宜的定制化产品），跨越到与用户的协作，实时感知用户情绪的企业，推出令用户兴奋的黑科技。这个变化是数字化转型中企业所面临的挑战。需要打通从需求、研发到业务运营整个的协作过程，建立新角色，落地新能力。下面是我的一点总结：分工会提升个体效能（产出output），系统性全局优化才能提高业务价值（价值outcome），对最终价值交付的优化才是关键。
企业核心竞争力来自于协作效率
我们现在看一下用户对企业竞争力的影响，这个是一个如何提升企业竞争力的例子，IBM（国际商业机器）成功的关键是生产满足商业公司所需要的计算机设备（IOE的I就是指IBM的小型机），早期的计算机是用来为政府和科研机构服务的。IBM与UNIVAC不同之处在于IBM服务于企业的财务人员和银行业。
IBM在企业计算机领域使用相同的技术战胜了科研领域的UNIVAC，而当时UNIVAC的服务对象是政府机构和科学家，不削于给企业的财务人员做计算机，但是我们现在知道，企业的计算机市场规模是非常大。
IBM在这个市场里面获得了成功，我们所说的企业竞争力体现在服务的对象足够多，服务的市场是否足够大，这是第一位的前提。
第二点是企业的核心竞争力在于它有能力构建新的价值网络，价值网络源自于传统的供应链。企业给供应商下单的规格和数量变化不频繁。
价值网络的不同之处在于，在美国的苹果公司对中国深圳的企业提出变更需求，两个小时以后流水线改变已经完成，24小时之后就可以生产出来新的手机了，中国的柔性制造能力世界第一。价值网络的难点在于，协同价值网络中分工足够细的，大规模生产企业，快速重新组合的能力。
下面的这幅图是2007年的时候诺基亚推出的经典手机，也许在座的听众也用过其中的某个型号的手机。
放这张图的意思是说明诺基亚当年通过推出大量定制化外观的手机，很好的满足了我们对手机外观多样化的需求。但是被只有一种外观，而且每年只出一款手机的公司打败了，这是为什么呢？他就是IPhone手机。苹果把更加广大的开发者加入到了协作网络里面去，让手机从只能打电话的通信工具，变成个人的效率提升的工具，可能我们现在真的一分钟离不开手机，但在十年前是不可想象的。
下面的图是基于云计算的平台三家公司，每个公司都有自己的布局，从电子商务、社交领域和搜索入口建立生态。这些平台上的应用的图标可能大家很熟悉，在不同的维度收集用户行为的数据，感知用户使用产品时的情绪变化，从而把服务越做越好。数据在组织内部可访问，在一个云生态内部，共享用户行为数据的成本非常低。
第二个就是自动化的基础设施，在云平台上快速调度计算资源应对用户流量是很容易的事情。最后在集中化和分布式平台，本身有利也有弊，集中化会建立统一标准提高协作效率，在较大的生态中一定会有协议和标准，而在小团队里面对于自己的业务作出有针对性的工具提升用户满意度，有不同才有比较，有比较才有不断的创新，这也是集中和分布式的一些思考。
企业竞争力在于与外部价值网络高效协作，我们都认为企业做的好是企业内部管理做得好，企业的效率高，所以企业才有竞争力，其实不是这样的，企业的竞争力是来自于企业对外部协作网络提供的价值。
企业的竞争力来自于服务的客户和市场的规模，企业的竞争力来自于创建更大的协作网络，企业竞争力来自于促进生态合作，增加服务市场规模。这才是企业竞争力的三个表现。
最后有一点值得讨论，在云计算平台上构建生态，满足了不同规模的需求，甚至是某个用户某一次特殊的需求都能得到满足。在传统企业模式下是无法想象的，因为市场规模不够大，不能形成规模效应降低成本，所以只能对具有一定规模的需求推出产品和服务。
云平台也将引入需求众包模式，比如重筹的平台，会满足大量的小规模的需求，这个云计算具降低了信息发布的成本，对服务市场带来了新的增量。
大型企业实施 DevOps 三个阶段
下面进入正题了，首先 DevOps 是一次系统性的变革，下面是提升研发效率的3D原则。我们类比集装箱运输的体系，在集装箱运输发展的早期阶段中，用户的按照传统的方式使用集装箱，集装箱内的货物不一样，从汽车运到轮船转运过程中不断的开箱拆包，大大降低了转运效率。
在二战时期，美国军方需要把大量的物资运往前线，从而总结出了在装箱，分拣和送货过程中的高效原则，基于这些原则我提出了研发体系的3D原则，一键式部署，一次构建打包，一次配置分发，在构建、测试和发布环节减少再次打包和人工过程。在遵循这三个原则之后，发布软件的时间可以控制在10-30分钟以内。
其次，DevOps 不是一次性的工程，可以一劳永逸，下面是一个软件研发过程当中的价值流图。
下面是我非常喜欢的一句话：“比日常工作更重要的，是对日常工作的持续改进。”
其实我们每个人都在做很多工作，可能每一天都会比前一天做更多，李智桦老师给出了企业效能的公式，企业效能等于实际产生价值的工时除以是总工时。在这张图里算出来的企业效能仅为16%，原因就是很多的工作都有等待，有的工作有返工。粗略的算一下从目前的效能水平，优化到总体效能提升两倍、三倍是绝对有可能的。而在某些环节内部按照 DevOps 实践完全有可能做到5倍，十倍或者二十倍效能提升。
随着业务在不断变化，技术在不断进步，在工作流中的每一个环节的情况就像左边一样混乱。DevOps 变革是一次大爆炸式的变革，就向扔一把扑克牌，落地之后就是整整齐齐在那里，而且牌面都是朝上的。这就是实施 DevOps 变革的兴奋性需求，如果谁的 DevOps 能实施到这个程度那真是赞了。
这个过程是如何做到的？首先我们要考虑两种力量，第一种力量是敏捷，敏捷的目的是什么呢？就是把我们每次交付的时间缩，做对用户有价值的事情。第二种力量是精益，我减少价值流图中的浪费。只要持续的改进，最后的结果一定是把我们软件研发的过程，到最后的生产，甚至是运维的环节做到统一和高效。
我们说在 DevOps 发展的初级阶段立足于促进研发和运维的协作。但是在我们来看只有 DevOps 帮助业务达成业务目标，才是可以持续的模式。也就是说做了流水线，也做了很多改进工作（产出 output），但是业务并没有因此而获益（价值outcome）。
自上而下的实践要求的是统一性和确定性， DevOps转型需要投入非常大的成本，使用业务线思维的DevOps与业务沟通，把 DevOps 实践作为一个有利可图的实施项目。
决策层投资了 DevOps 实践就期望从中获得收益，我们要把DevOps 提升的结果翻译成业务人员能懂的语言，比如说我们可以缩短产品上市时间获得先机，可以让我们的生产更加稳定，减少以外带来的损失。
下面说如何产生新实践，工程师都喜欢去研究一些新技术，有很多团队在做这种尝试和创新的话，其中有各种比较，逐步找到创新的方向，所以说自上而下的 DevOps 实践带来业务价值，自下而上的 DevOps 实践获得新实践。使用企业级的实践提升业务价值，使用团队级别实践不断产生新实践。这样形成正向循环。
在我们推广 DevOps 的时候，大家感觉都是求着研发人员改进一样，为什么要求人呢？因为人家的工作内容里本来就没有实施 DevOps。还是上文说过的一句话：“比工作更重要的是工作的改进。” 如果改进不是每个人的工作内容，不作为考核的内容，实施DevOps实践就只是一时的事情，无法落地。
右边的图是稳定的学习型组织模型，比如说在一个公司的两个部门里，成立一个协会，会定期分享案例，或者是组织实践评选，在一个部门内部会有相同角色的人组成分会不定期分享工作中经验，让小团队中的实践在全公司范围内都是可见的，减少重复造实践的成本，同时也会把做相同的事情的人的经验整合起来。
最后还是说对领导的培训，做个广告，有的读者真的把《DevOps实施手册》的截图发到朋友圈里给老板看，用这种方式和领导沟通。因为有些话不能直接给领导说，所以就用我的书里的实践来影响领导。
最后总结一下，首先要有一个清晰的路线图，明确投资回报率，然后在试点团队验证新实践的交付有效性，最后，建立改进的考核目标和组织模型，鼓励分享经验的团队，吸引对变革有观望和怀疑心态的人加入到变更中来。
DevOps 五个能力能级
下面是我的一个思考，公司根据核心竞争力划分为三个等级，产品、平台、生态。
对于公司面临的商业环境来说分为五类，最复杂的一款是无序，最复杂的情况下即使可以复制之前的实践，也无法得到相同的结果。
同样的，对工程师取得的成就也为五类，很巧也是五类，最高等级是开创一个产业（爱迪生、福特、贝尔），比如说像开创一个产业的人，二级工程师是作出先前没有的东西，而改变世界（谷歌的云计算发明人迪恩Jeff Dean），三级工程师必须是一个非常好的产品经理，可以作出被市场认可的好产品。
在公司内作出有影响力的工作，就达到了四级工程师的要求。最后，一个人可以独立解决问题，完成工作即为五级工程师。
最后，从我们的环境和我们能取得的成就来看，DevOps服务能达到的极限就是服务所有云上的开发者和生态合作伙伴，将价值和信息传递给最终用户。第二个等级，是组织内部的业务平台，对价值网络其他组织提供价值。
从平台和生态角度看，引入更多外部协作，就是公司竞争力的体现。第三级，在一个组织内部协调各部门的资源，达成系统性优化，显著提升组织效率。第四级，通过可见性建立信任文化，提高团队协作效率。第五级，支持个人完成任务，并具备持续改进能力。
小节一下，当基本需求得到满足的时候消费者会提出最高的需求，如何满足更高层次的需求？就要不断的扩大协作范围，这对组织结构和能力是非常大的挑战，数字化转型就可以理解为一个组织从满足期望需求，向满足兴奋型需求转型的过程。
第二个就是说技术和业务的变化带来的组织模式的变化，打破仓筒结构形成全局优化，就是前面提到的， 4000名开发人员工按照相同的规则做研发。
大型企业通过三个阶段实施DevOps，首先要有路线图，要有商业化的试点案例明确投资回报率，在组织模型和考核方面鼓励创新。
最后是我对DevOps的服务发展的一些思考，通过引入更大规模的协作提升组织竞争力。
原文发布于微信公众号 - DevOps时代（DevOpsTimes）
原文发表时间：2018-12-26
阅读原文
结语：以上就是首席CTO笔记为大家整理的关于devops看什么书的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～