《DevOps实施手册 在多级IT企业中使用DevOps》一书详细介绍了DevOps实施的核心理念和方法，探讨了在多级IT企业中如何使用DevOps，提供了一系列实用的案例和工具，对于实践者和管理者都具有较高的参考价值。
DevOps实施手册 在多级IT企业中使用DevOps读后感第一篇
这本书对于初学者比较友好，也不缺乏深度。对刚接触DevOps的人来说，有着详实的介绍和实验案例。对于中级学习者，有着一些巩固基础的作用，同时也不缺乏深入的内容，可以帮助测试和运维人员比较好的了解和学习关于DevOps的内容和技术。
有很多的实际案例和教程，对于学习DevOps是不可多得的一本好书
DevOps实施手册 在多级IT企业中使用DevOps读后感第二篇
这本书对于初学者比较友好，也不缺乏深度。对刚接触DevOps的人来说，有着详实的介绍和实验案例。对于中级学习者，有着一些巩固基础的作用，同时也不缺乏深入的内容，可以帮助测试和运维人员比较好的了解和学习关于DevOps的内容和技术。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
很好！
DevOps实施手册 在多级IT企业中使用DevOps读后感第三篇
是一本好书，更容易理解如果真正把Devops实施起来，也正是我想要的，非常感谢作者了，找了好久了，网上找了很多相关的资料，，也去图书馆，但是都好像讲的我不够明白，看了那么多资料，到最后还是不能完全理解，还是有点晕晕乎乎的感觉，看完这本书的时候，给了我很大帮助，，，，，太感谢了，值得学习哦。。。。。。。。。。。。。
DevOps实施手册 在多级IT企业中使用DevOps读后感第四篇
本书深入浅出，从不同角度，列举了多个案例。详尽的描述了如果大中型企业进行devops变革时，每个岗位在变革所处的位置，应当尽到的职责，和互相之间的关系。适用于企业中高层领导阅读和查阅的书籍。
作者是IBM的Devops大神。书中分别从devops项目发起者、开发人员、测试人员、运维人员、devops推广者、公司高层等各个角度详细描述了devops变革中将会遇到或是可能遇到的问题。因为描写过于详尽，部分内容可能有重复的现象，但其余部分都是干货，是本devops方面不可多得的好书。不同于市面上的其他书籍，这本书不是在说用什么工具，而是在说怎么使用工具。其中还包含了大量案例，枚举了各种正确抑或是错误的方式方法。通读本书能少走不少弯路。
DevOps实施手册 在多级IT企业中使用DevOps读后感第五篇
1 .专业实用 本书由四位长年工作在开发一线的IT工程师编写，结合实例详细介绍在开发现场引入DevOps的具体流程， 特别适合DevOps初学者和初学者团队阅读。 2.结构清晰 首先介绍如何提高个人开发效率和自动化程度，然后过渡到在团队内开展DevOps的方法，最后介绍引入DevOps的实践。由浅入深，条理清楚，方便读者快速上手。 3.内容全面 全面介绍DevOps的概念、背景、相关工具、技术和开发思想，即使对于熟悉DevOps的开发人员，或者只对某些技术感兴趣的开发人员，本书也值得一读。 【内容简介】 本书结合大量实例，详细介绍了在开发现场引入DevOps 的具体流程。在对DevOps 出现的背景和相关概念进行说明之后，首先介绍了如何在个人环境中引入DevOps，接着介绍了在团队中开展DevOps 的方法，最后介绍了引入DevOps的实践。内容全面涵盖了DevOps 相关的工具、技术和开发思想。
DevOps实施手册 在多级IT企业中使用DevOps读后感第六篇
读了《DevOps实施手册》感觉受益颇多。这是我看到的第一本如此全面得对DevOps实施的方法和探索，并且以结构化的方式展现在我面前。
整本书中引发我思考最多的是书中每一章都会提到的文化。以往我们都是把大多数的精力和思考放在如何实施DevOps上，使用什么工具可以完整得去实施DevOps，而忽略了这样一个根本的东西。这就好像一家公司的使命、愿景和价值观一样，有些公司非常明确，并且部门和员工之间相互信任，通过充分的沟通和协作去完成每一个使命，不断靠近愿景。在我看来DevOps变革可能无关乎高能力者的多与少，而是整个团队或者组织拧成一股绳朝着目标共同进发的信念。
至于为什么要实施和怎么实施DevOps的方法书中已经按照不同的客户和业务以及企业IT的成熟度进行细分描述。其中不论从方案到技术都有非常全面的描述，我想这是这本书称得上实施手册的根本，是一本遇到具体问题，随时可以拿出来查阅的手册。让我觉得可惜的是，这本书没有Kindle版，因为可以随身携带，基于电子版的检索和批注会更方便的去查阅和记录。
书中让我印象比较深的是DevOps能力中心的几个角色，角色分工非常明确。作为IT人，遇到角色会不由自主的将自己代入考虑，评估可以胜任哪个角色。不过现在在我的工作中占用我相当一部分时间的角色似乎是一个DevOps产品经理的角色。我对这个角色的看法是：DevOps并不是一个产品的概念，但可以基于产品或者平台来更高效的达成各个阶段的目标。DevOps产品经理获得以及整理来自客户或者内部团队的反馈，对DevOps的产品或者平台提出改进建议，达到持续改进的目的。
这是一本非常精彩的书。以往的实践就好像修炼了各种不同的内功，而这本书告诉了我脉络的走向，让我可以去融合以往的经验和想法以提升一个新的阶段。
DevOps实施手册 在多级IT企业中使用DevOps读后感第七篇
原创：万金 来自《DevOps实施手册》“第2章：DevOps实施”的解读 发表与2018年6月28日 估计阅读时间8分钟
你有没有过这样的感觉？办法和道理都懂，还是过不好这一生。在年初制定的健身和学习计划，到了年底，生活还是老样子。如果改变自己都很困难，改变一群人的行为习惯则更加困难。比如在一个公司里，推动一场变革更是难上加难了。试想一下，把你投放到越南的小村庄，改善当地人的饮食习惯，前提是没有认识的朋友，也没有资源的情况下，而且要在六个月之内完成任务。这直就是天方夜谭。改变虽然很难，但改变确实在我们身边发生着，比如某人减肥后成为健身教练，像谷歌这样的公司持续创新。难道他们有过人的意志力？那些大型组织的持续改进是如何做到？他们只是顺应了改变的规律。
在《象与骑象人》中提出了一个改变行为习惯的模型。书中指出，人的理性就像是骑在大象背上的人，而感性就是那头大象。为了长期目标理性会牺牲短期利益，但是力量有限，真正的动力来自于感性，让你做感到怦然心动的事情。只有同时说服骑象人和大象才会让改变发生。
说服骑象人和大象
其实改变的规律很简单只有三个步骤：
1. 引领骑象人
2. 激励大象
3. 营造环境
首先为骑象人指明前进的方向，设置路标简化执行方法，避免原地打转；激励大象持续前进，遇到让你怦然心动的事情，快速前进；最后营造一个驱动改变的环境，让改变容易发生，避免倒退。
根据改变的规律的三个步骤，类比得出DevOps实施过程的三个阶段：
1.路线图，制定DevOps实施手册，指明变革的方向
2.商业化，发现DevOps商业案例，明确投资回报率
3.领导力，打造DevOps能力中心，确保持续的改进
如作者对本书其他章节解读，《发现落在隔壁的未来》描述开发商业案例，遇见让你怦然心动的事情；《打造军工级的DevOps保障性体系》打造DevOps能力中心和组织模型用来营造环境，解决人才匮乏和没有团队模型的问题。
改变确实可以发生，国际慈善组织的杰瑞，接到了一个去越南一个小村庄的任务，希望他在6个月内，改善当地儿童营养不良的问题。杰瑞调查了当地情况，结果是卫生条件差，没有干净的饮用水，食物不足，所以当地人不关心营养均衡的问题。这些都是正确的废话。改善卫生条件，让人们生活富足，这是总统才能做到的事情，更何况要在6月内完成任务。
杰瑞在当地进行了挨家挨户的访谈，测量各种儿童成长的数据。终于发现一家特殊的家庭。这个家庭虽然生活不富足，但是孩子比其他家庭更加健康。原因是家长喂养孩子的方式很特别：少吃多餐、鼓励多吃，并且在田里采集虾蟹和野菜作为辅食。这就是杰瑞需要的，在当地条件下，在不增加花费的情况下，提高儿童营水平的饮食习惯。
找到榜样后，杰瑞召集村民，向大家保证：“只要饭前洗手，加入虾蟹和野菜作为辅食，孩子就能健康成长。”这个简单的方法很快就被当地村民接受了。当杰瑞离开后，当地的营养水平还在持续提升，改变确实发生了。
这个例子里村民心里的大象是不需要被说服的，他们都希望自己的孩子健康成长。关键问题在于找到榜样，用简单可行的方法达成目标。避免方法过于复杂，导致骑象人原地打转。就如史蒂夫·克鲁克在《Don't Make Me Think》中描述的可用性第一定律：用户看到的内容应该是不言而喻、一目了然、自我解释的。用户无需思考就可理解：它是什么、如何使用它？
用户体验地图
无需思考，就能让用户了解DevOps是什么，如何实施，还需要做到以下三要素：
● 一个目标：关系等于信息，对客户了解越多，就越能了解客户的内心感受，使用同理心了解用户痛点和目标。
●一条路：内容不是产品，用户通过使用内容达到自己的目标，这样的内容才是产品。按照用户的目标，设计服务接触（Service Encounter）和用户体验地图（User journey），让用户跟地图指引逐步达成目标。
●三个点：崩溃点与峰终定律，首先不要超越用户的忍耐底线，根据峰终定律（Peak-EndRule），集中优势资源打造峰值体验，为用户设计一个独特的终值体验。只要关注3个点，就能在有限资源前提下，给用户留下美好的回忆。
以Keep健身app为例，打开应用就会问用户，你的健身目标是什么？减肥、增肌还是练出马甲线（健身的本身不是目标）。然后询问用户能接受多大强度的运动（崩溃点），然后给出一个健身计划，每天完成视频的动作，就能一步一步达成目标。
有了用户和用户故事后，服务宣传方式也随之改变了。从宣传内容变成了，有什么样的用户，用户故事是什么。对于新用户，只需要参考与他们类似的用户故事，选择适合自己的使用方式。
对于迪士尼，这个世界上最擅长制造快乐的地方，体验的峰值一定是某个刺激的游戏。体验的终值是累了一天，晚上坐在地上，看花车游行和园区上空的烟火秀。每个用户都会不禁感叹到：“好美啊”。所有的体验过程都会有各种小问题，但是峰值和终值决定你的记忆中的印象好坏。
大多数浪费发生在交接过程中，特别是跨职能部门的利益相关者进行交接的期间，还有就是操作人员等待他人做出行动的时候。当构建物发出去，接收方却无法直接使用时，也会产生相应的浪费。也就是说，构建物需要接收方进行修正或改良才能使用或者需要退回返工。
价值流图案例
本书提出使用价值流图工具，评估现状，并识别低效与浪费，从而设计未来可达到的状态。书中描述常见的浪费如下：
1. 不必要的流程步骤、功能与返工
2. 转换他人创建的构建物结构
3. 等待审批或他人执行任务或平台环境就绪
4. 为手动任务与手动更新数据和状态报告
作者曾经供职于Thoughtworks，咨询项目的第一阶段通常是通过组织价值流图工作坊，识别当前状态与远期目标，分析在可见的将来能够达到的目标。不断执行迭代和反馈学习逐步达成长期目标。
本书描述了通过组织价值流图工作坊，编写DevOps实施手册的过程：
(1) 对“目标状态”(业务目标及驱动)的明确定义。
(2) 对“现状”(现时的能力及成熟度)的充分理解。
(3) 对最佳“路径”或最优“方案”(风险-价值-投资平衡)的选择决策。
在收获成果之前一定会经历生产率的下降。这是引入变化的自然结果，不管变化发生在流程、工具还是团队架构方面。好的变革推行方案会提前做好预案并采取行动将下降幅度控制在最小范围。最终，在生产率实现正增长后，如果流失的生产率(见图 2-3)相比于提升的生产率而言是微不足道的，那么就可称之为成功变革。
实施变革过程中生产率变化曲线
最后，即使已经完成所有的流程改进与自动化工作，如果无法克服组织内根深蒂固的文化惰性，DevOps 的实施改革也不会取得成功。大多数组织都有一种惰性，那就是对变化的本能抵触。改变很难，尤其是那些大型组织，这些组织中的文化经过多年的沉淀积累并潜移默化地影响着成百上千的操作人员。这些人员，作为独立个体，他们或许认可DevOps 实施的价值，但作为一个群体，他们就会抗拒变化，进而形成惰性。克服这种惰性是关键所在。
要克服文化惰性，需要审查导致瓶颈问题及浪费的根本原因。要想解决这些瓶颈问题，需要改变的不仅仅是传统的 DevOps 实践，还需要有改变文化的强烈意愿，上至负责并引领变革的高管，下至执行变革的普通员工。管理层需要为改变行为模式的操作人员提供支持与保护，这将对那些执行变革的人产生积极影响并将悄然打破传统的管理模式。
DevOps不是职位名称，也不是角色或部门，而是一个团队。总之，对于传统大型企业变革始于自上而下的投入，也需要从组织内部自下而上的涌现。只有形成正反馈，才能使DevOps变革扩展至整这个组织。
《DevOps实施手册》百度百科
《DevOps实施手册》“第2章 DevOps实施”的解读：驾驭你心里的大象
《DevOps实施手册》“第3章 开发DevOps变革的商业案例”的解读：发现落在隔壁的未来
《DevOps实施手册》“第6章 DevOps的企业级推广”的解读：打造军工级的DevOps保障性体系
峰终定律（Peak-EndRule）：对体验的记忆由两个因素决定：高峰（无论是正向的还是负向的）时与结束时的感觉，这就是峰终定律（Peak-EndRule）。
