原创：万金 来自《DevOps实施手册》“第2章：DevOps实施”的解读 发表与2018年6月28日 估计阅读时间8分钟
作者简介：
万金
《DevOps实施手册 在多级IT企业中使用DevOps》译者
15年知名外企与中国企业的IT从业经验，包括IBM，华为，ThoughtWorks 具有8年云计算相关经验，多系统的研发和运维经验，熟练掌握敏捷和DevOps方法论和实践，具有软件研发生命周期工具与流程改进丰富经验。
不可能的任务
你有没有过这样的感觉？办法和道理都懂，还是过不好这一生。在年初制定了健身和学习计划，到了年底，生活还是老样子。如果改变自己都很困难，改变一群人的行为习惯则更加困难。比如在一个公司里，推动一场变革更是难上加难了。试想一下，如果你接到一个任务，要求六个月内改变一个越南小村庄的居民饮食习惯，而且是在没有任何资源配备的情况下。听起来，这简直就是天方夜谭。改变虽然很难，但改变确实在我们身边发生着，比如某人减肥后成为健身教练，像谷歌这样的公司持续创新。难道他们有过人的意志力？那些大型组织是如何做到持续改进的？他们只是顺应了改变的规律。
大象与骑象人
《象与骑象人》中提出了一个改变行为习惯的模型。书中指出，人的理性就像是骑在大象背上的人，而感性就是那头大象。为了长期目标理性可以牺牲短期利益，但是力量有限；真正的动力来自于感性，让你做感到怦然心动的事情。只有同时说服骑象人和大象才会让改变发生。
改变的规律很简单只需三步：
1. 引领大象
2. 激励大象
3. 营造环境
首先为大象指明前进的方向，设置路标简化执行方法，避免原地打转；激励大象持续前进，遇到让你怦然心动的事情，快速取得成果；最后营造一个驱动改变的环境，让改变容易发生，避免倒退。
实施DevOps变革的三个阶段
根据改变的规律的三个步骤，类比得出DevOps实施过程的三个阶段：
1. 路线图，制定DevOps实施手册，指明变革的方向
2. 商业化，发现DevOps商业案例，明确投资回报率
3. 领导力，打造DevOps能力中心，确保持续的改进
如作者对本书其他章节解读，《发现落在隔壁的未来》描述开发商业案例，让你有怦然心动的感觉；《打造军工级的DevOps保障性体系》打造DevOps能力中心和组织模型用来营造环境，解决人才匮乏和文化惰性问题。
引领大象
改变确实可以发生，国际慈善组织的杰瑞，接到了一个去越南一个小村庄的任务，希望他在6个月内，改善当地儿童营养不良的问题。杰瑞调查了当地情况，结果是卫生条件差，没有干净的饮用水，食物不足，所以当地人不关心营养均衡的问题。这些都是正确的废话。改善卫生条件，让人们生活富足，这是总统才能做到的事情，更何况要在6月内完成任务。
杰瑞在当地进行了挨家挨户的访谈，测量各种儿童成长的数据。终于发现一家特殊的家庭。这个家庭虽然生活不富足，但是孩子比其他家庭更加健康。原因是家长喂养孩子的方式很特别：少吃多餐、鼓励多吃，并且在田里采集虾蟹和野菜作为辅食。这就是杰瑞需要的，在当地条件下，在不增加花费的情况下，提高儿童营水平的饮食习惯。
找到榜样后，杰瑞召集村民，向大家保证：“只要饭前洗手，加入虾蟹和野菜作为辅食，孩子就能健康成长。”这个简单的方法很快就被当地村民接受了。当杰瑞离开后，当地的营养水平还在持续提升，改变确实发生了。
别让用户思考
这个例子里村民心里的大象是不需要被说服的，他们都希望自己的孩子健康成长。关键问题在于找到榜样，用简单可行的方法达成目标。避免方法过于复杂，导致骑象人原地打转。就如史蒂夫·克鲁克在《Don't Make Me Think》中描述的可用性第一定律：用户看到的内容应该是不言而喻、一目了然、自我解释的。用户无需思考就可理解：它是什么、如何使用它？
让用户感到熟悉，只要跟随已有的使用习惯，就能自然而然的达成目标。《思考快与慢》中提出了思考的两个系统，大脑为了快速做出反应，使用“系统一”本能的做出反应；而“系统二”则需要进行理性反思，过程缓慢。
意识即防御，在使用过程中，用户一旦启动了系统二模式，就会考虑是否能够继续下去，甚至导致用户离开。即使玩游戏这种休闲娱乐活动，如果反复出现难关，甚至是看攻略也无法玩下去，用户尝试几次后，就对游戏不再感兴趣，最终导致用户离开。
DevOps的实施手册三要素：一个目标、一条路和三个点
无需思考，就能让用户了解DevOps是什么，如何实施，还需要做到以下三要素：
一个目标：关系等于信息，对客户了解越多，就越能了解客户的内心感受，使用同理心了解用户痛点和目标。
一条路：内容不是产品，用户通过使用内容达到自己的目标，这样的内容才是产品。按照用户的目标，设计服务接触（Service Encounter）和用户体验地图（User journey），让用户跟地图指引逐步达成目标。
三个点：崩溃点与峰终定律，首先不要超越用户的忍耐底线，根据峰终定律（Peak-EndRule），集中优势资源打造峰值体验，为用户设计一个独特的终值体验。只要关注3个点，就能在有限资源前提下，给用户留下美好的回忆。
以Keep健身app为例，打开应用就会问用户，你的健身目标是什么？减肥、增肌还是练出马甲线（健身的本身不是目标）。然后询问用户能接受多大强度的运动（崩溃点），然后给出一个健身计划，每天完成视频的动作，就能一步一步达成目标。
有了用户和用户故事后，服务宣传方式也随之改变了。宣传内容变成了，有什么样的用户，用户故事是什么。对于新用户，只需要参考与他们类似的用户故事，选择适合自己的使用方式。
对于迪士尼，这个世界上最擅长制造快乐的地方，体验的峰值一定是某个刺激的游戏。体验的终值是累了一天，晚上坐在地上，看花车游行和园区上空的烟火秀。每个用户都会不禁感叹到：“好美啊”。所有的体验过程都会有各种小问题，但是峰值和终值决定你的记忆中的印象好坏。
价值流图：评估现状与设计未来
精益理论用完成率以及准确率(%Complete and Accurate，%C&A)作为衡量的标准 ——Martin，2011
大多数浪费发生在交接过程中，特别是跨职能部门的利益相关者进行交接的期间，还有就是操作人员等待他人做出行动的时候。当构建物发出去，接收方却无法直接使用时，也会产生相应的浪费。也就是说，构建物需要接收方进行修正或改良才能使用或者需要退回返工。
价值流图是一种精益管理办法，针对产品或服务如何交付给客户全过程中的一系列事件，分析其当前状态并设计其未来状态。 ——维基百科
本书提出使用价值流图工具，评估现状，并识别低效与浪费，从而设计未来可达到的状态。书中描述常见的浪费如下：
1. 不必要的流程步骤、功能与返工
2. 转换他人创建的构建物结构
3. 等待审批或他人执行任务或平台环境就绪
4. 为手动任务与手动更新数据和状态报告
编写DevOps实施手册
作者曾经供职于Thoughtworks，咨询项目的第一阶段通常是通过组织价值流图工作坊，识别当前状态与远期目标，分析在可见的将来能够达到的目标。不断执行迭代和反馈学习逐步达成长期目标。
本书描述了通过组织价值流图工作坊，编写DevOps实施手册的过程：
(1) 对“目标状态”(业务目标及驱动)的明确定义。
(2) 对“现状”(现时的能力及成熟度)的充分理解。
(3) 对最佳“路径”或最优“方案”(风险-价值-投资平衡)的选择决策。
控制下降幅度防止变革的崩溃
在收获成果之前一定会经历生产率的下降。这是引入变化的自然结果，不管变化发生在流程、工具还是团队架构方面。好的变革推行方案会提前做好预案并采取行动将下降幅度控制在最小范围。最终，在生产率实现正增长后，如果流失的生产率(见图 2-3)相比于提升的生产率而言是微不足道的，那么就可称之为成功变革。
克服文化惰性为变革代言
最后，即使已经完成所有的流程改进与自动化工作，如果无法克服组织内根深蒂固的文化惰性，DevOps 的实施改革也不会取得成功。大多数组织都有一种惰性，那就是对变化的本能抵触。改变很难，尤其是那些大型组织，这些组织中的文化经过多年的沉淀积累并潜移默化地影响着成百上千的操作人员。这些人员，作为独立个体，他们或许认可DevOps 实施的价值，但作为一个群体，他们就会抗拒变化，进而形成惰性。克服这种惰性是关键所在。
要克服文化惰性，需要审查导致瓶颈问题及浪费的根本原因。要想解决这些瓶颈问题，需要改变的不仅仅是传统的 DevOps 实践，还需要有改变文化的强烈意愿，上至负责并引领变革的高管，下至执行变革的普通员工。管理层需要为改变行为模式的操作人员提供支持与保护，这将对那些执行变革的人产生积极影响并将悄然打破传统的管理模式。
DevOps不是职位名称，也不是角色或部门，而是一个团队。总之，对于传统大型企业变革始于自上而下的投入，也需要从组织内部自下而上的涌现。只有形成正反馈，才能使DevOps变革扩展至整这个组织。
参考资料：
《DevOps实施手册》“第2章 DevOps实施”的解读：说服住在你心里的大象
《DevOps实施手册》“第3章 开发DevOps变革的商业案例”的解读：发现落在隔壁的未来
《DevOps实施手册》“第6章 DevOps的企业级推广”的解读：打造军工级的DevOps保障性体系
峰终定律（Peak-EndRule）：对体验的记忆由两个因素决定：高峰（无论是正向的还是负向的）时与结束时的感觉，这就是峰终定律（Peak-EndRule）。
