特别说明
本文是已读书籍的学习笔记和内容摘要，原文内容有少部分改动，并添加一些相关信息，但总体不影响原文表达。
《DevOps入门与实践》 ：本书结合实例详细介绍了在开发现场引入DevOps的具体流程。
- ISBN: 978-7-115-51256-7
- https://www.ituring.com.cn/book/2407
个人简评
适合已有实践经验的实施人员，对已有知识和技能做结构性梳理。
适合对DevOps欠缺了解的人员，能够建立起基本的概念。
但由于外文书籍翻译引入与中文出版存在时间差，导致书中涉及的一些工具和方法，落后于当前主流应用场景。
前言
如果在实施DevOps的过程中，周围没有一个人支持你，也没有得到领导和团队成员的理解；
如果在采用DevOps的工具和方法之后，难以获得明显的效率提升，甚至得到了不少的消极反馈；
那就需要反省一下，是否误入了DevOps歧途。
误将手段当目的
采用DevOps工具和建立DevOps架构并不完全代表DevOps的实施。
采用某种工具或者某种架构只是实现DevOps的一种手段而已，如果没有获得人员支持，就应该重新思考下实施DevOps的目的到底是什么。
在较小的范围内采用自下而上的方式实施DevOps，可以先考虑具体的方法，而不是大刀阔斧。
在需要与他人一起实施DevOps的情况下，就要预想实施DevOps能产生什么样的效果、过程中会遇到什么困难等等。
在明确目标的指引下，思考采用何种工具和方法是最合适当前情况、易于接受的。
引而不用
团队成员很难完全抛弃原有的工作流程和体制，也难以完全接受一个全新的流程和体制。
虽然引入了DevOps的工具和方法，但在实际工作中，工具被摒弃，方法被弃用，规则被漠视，那么原因之一可能是现在的做法过于激进。
要想让团队成员适应DevOps，最重要的事是要做到能够在不改变原做法的情况下采用新机制。
也就是说，如果能够保证新方法和原方法的输入与输出保持一致，甚至不存在细微的差异，那么新操作的结果就不会偏离原有的规则，这一点最能说服他人接受DevOps。
加大运维负担
引入了新工具，却增加了操作步骤；
引入了新方法，却复杂了流程环节；
原想自动化，实际手工干；
如此这般，实际上加大了运维负担。
究其原因，可能是追求部分结果的理想化，或者向原有机制妥协，最终导致了整体工作量增加。
过早优化是“罪恶”，并行运维是“罪过”。
DevOps团队成为权威
权威将导致盲目迷信和割裂，但改善无止境，DevOps应始终开放和沟通，保持一种能和其他团队灵活交换意见的状态。
DevOps全能超人
实施DevOps不是要求所有人都具备相同的技能，也不是要求必须存在或增加一些精通开发、测试、运维的全能超人。
DevOps的本质在于互相理解和学习，消除不必要的沟通，从而提高效率。
因此，实施DevOps过程中，难度最大的不是技能性的要求，而是营造一种团队之间、个人之间互相理解的文化。
一败而折
阶段性的失败，尤其是一开始的失败，必然会导致各种各样的的意见。
但DevOps需要不断改善才能实现，不能基于短期的状态来进行最终的评判。
DevOps实现的其实是一个协作机制，最终将是任何组织和公司都应具备的一个基本能力。
为了避免出现“实施DevOps阶段性失败了就认为DevOps不适合自己团队”这种“一败而折”的想法，很有必要保证一开始实施的阶段成果是积极的，鼓舞人心的。
只关注成本
实施DevOps是为了实现和提升商业价值，而不是为了节约成本。
根本目标的不同，必然导致结果的差异。
如果只关注成本，那么在成功实施了DevOps后，虽然效率得到提升，资源得到释放，但面对却可能是组织变动、人员裁减的消极局面。
但如果从商业价值出发，节约出来的资源可以投入到扩充规模、探索新产品等业务活动中去，让团队成员拥有一个积极的期待和状态。