分享回顾怎样挑战 DevOps 实践之旅
Posted DevOpsClub
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分享回顾怎样挑战 DevOps 实践之旅相关的知识，希望对你有一定的参考价值。
本文根据DevOps核心组织者，资深DevOps教练刘征老师和张乐老师在 DevOpsDays 2018北京站主会场的分享内容整理而成。本次分享是合作演讲，两位老师为我们带来的主题是“怎样挑战DevOps的实践之旅”。
演讲者介绍：
刘征 Martin
Nutanix 高级架构师
《DevOps实践指南》译者
DevOpsDays中国核心组织者、出品人，EXIN DevOps Master 首批授权讲师，EXIN DevOps Professional 官方授权讲师，致力于推广DevOps的理念和技术实践，喜欢跑步、开源软件和写博客。
张乐
京东研发工程效能部资深
解决方案架构师
前百度资深敏捷教练、DevOps与持续交付专家，DevOpsDays中国核心组织者、出品人，EXIN DevOps Master 授权讲师，EXIN DevOps Professional 全球讲师最高分保持者，凤凰项目DevOps沙盘官方授权教练，设计并发布了DevOps道术法器立体化实施框架，设计并实现了端到端持续交付流水线工具集成解决方案。
今天我们合作演讲的话题是企业如何入手进行DevOps的转型。在这一过程热炒几年之后的今天，我们要讨论的目标是，转型过程中的一些难点和误区是什么？我们用什么样的套路启动DevOps之旅？这个过程中我们如何评估和度量我们取得的进展和成果？最后是保持一颗学习的心态，我们如何在学习的过程中逐渐成长。在演讲的结尾会有一些总结和新的活动发布。
DevOps转型的难点和误区
难点1：DevOps也许在互联网企业推进更合适，传统类型企业并不适合？
（张乐老师）很多人认为DevOps更合适于互联网公司，传统企业是不是也合适呢？这是一个很好的问题，我们通常认为互联网公司具备一定的基因，它们的业务模式和系统架构相对更适合做DevOps转型。
的确，我们可以看到很多优秀的公司，包括谷歌、亚马逊、Facebook等，DevOps都做的很成功，从统计数据上看，有的可以实现每天发布上万次，平均每隔十几秒就进行一次发布。但我想说的是，这些公司并不是生来如此，它们大多经历了与传统公司一样的问题，包括技术无法跟上业务的飞速发展，不能快速发布新功能，复杂系统维护困难等。但是这些公司有非常强的进化能力，它们重构了系统架构、改变了技术实践，改变了文化的氛围，才最终走向成功。
比如说谷歌，之前看到一些文章说它的架构已经从头到尾重写过五次了，亚马逊从2002年的就开始进行从单体架构到SOA架构的转型，这些公司其实都是逐步进化成现在的模样的。
就像我的配图一样，独角兽公司其实是从普通的马驹公司成长进化而来的，所以我们应该用一种发展的、演进的思路看待问题。我们今天的大会也邀请到了很多各行各业的很多嘉宾，他们会分享在现有条件下DevOps转型所取得的丰硕成果，所以DevOps已被证明是普适的方法和技术，而并不是互联网公司的专利。
传统一些的公司也是可以进行转型的，DevOps也会让这些大象翩翩起舞。
难点2：DevOps的变革成本很高，需要采购一大批工具？
刘征老师）很多领导说：实施DevOps的话，是不是需要采购很多工具，这些工具怎么选型？在我的职业生涯中我是乙方，十几年前我就是给甲方提供IT服务管理工具的，那个年代甲方企业在IT系统管理工具的选择上是非常简单的，从四大厂商的产品选择就可以了。而现在整个DevOps工具蓝图发生了巨大变化，每一年都在更新。在这里先讲一个故事，是来自于《凤凰项目》临摹对象《目标》里，Alex和Jona的一个桥段。
A：你是做什么的？
J：我是工厂经理，我要去参加一个技术大会？
A：你讲的内容是什么？
J：我的演讲主题是“在工厂里如何通过机器人提高70%的生产率！”
A：哦是吗，机器人可以提高这么多生产率，你是怎么提高的，你们销售提高了70%吗？
J：不不，我不是销售部门的，我是工厂经理，我不知道销售的数据。
A：哦，那你们工厂是不是裁员了70%的人？
J：不可能，我们有工会，不可能做这种事。
A：那我认为你们的工厂并没有提高任何的效率，相反你们的库存可能已经要把库存房撑爆了。
这是对我非常非常有启发的故事，从技术上来讲，任何一家公司：如果不能增加销售的吞吐量，同时也不能降低生产过程中的成本；那么你上的任何工具可以称之为“高效”，但它不一定是有效的，更别说它是一定会有效益的了。
所以在实施工具过程中，我们不仅要遵从DevOps工作三步法的‘流动原则‘，更要看你是否给企业的价值流带来了帮助，看它是否做到了一部分的增值工作。所以不管DevOps的工具有多复杂，但是我们依然是可以‘以加速价值为导向’的原则去建设的。
难点3：DevOps需要大规模组织结构重组，否则无法实施？
（刘征老师）在我的客户中也有很多正在开展DevOps项目，当然有人也问过我这样的问题：DevOps实施都需要大规模组织结构的重组，我们如果不进行组织结构重组那我们怎么实施呢？
（张乐老师）这也是我经常碰到的问题，其实我们讲团队有不同的组织形态。第一种是职能导向的模式，强调专业性和集中管理，等级式的组织结构，工作频繁移交、效率较低。职能导向的模式通常有很多部门，一个业务需求过来，需要穿越所有部门边界，通过很多工单流转、很多等待和协调会议才能完成一个需求的最终交付，所以这是一种为成本优化的模式。另外一种是市场导向的模式，比如敏捷转型的团队里通常是跨职能团队，各种不同的角色在一起密切配合，可独立快速交付用户价值，这是一种为速度优化的模式。我对这个问题的回答是，组织结构重组并不是推行DevOps唯一的选择，我们可以有很多变通的方法，在保持现有组织结构不变的情况下也能达到DevOps的效果。
比如我们可以采用类似于矩阵的模式，让大家物理的工作在一起，减少工作障碍、提升协作效率。但更推荐的方法是，使用技术的方式实现一个自助化自服务的平台，让下游通过这个平台给上游赋能。后端团队通过平台承载他的能力、降低对个人技能的依赖，上游团队调用这个自动化自服务平台完成他们的日常工作。通过这种方式降低团队之间的依赖和高带宽的通讯，可以在不改变现有组织结构的情况下，依然能获得实施DevOps的很多收益。
难点4：在实施DevOps的道路上，未来的那些坑可以预测和避免么？
（张乐老师）DevOps路上每个人都想成功，但是罗马不是一天建成的，我想问一下刘征老师，在DevOps实践路上有哪些坑，这些坑是可以预测或者避免的吗？
（刘征老师）在翻译《DevOps实践指南》这本书过程中，我的世界观发生着巨大变化，我思考了这样一个问题，同样都叫工程师，有修路的工程师，也有建筑工程师，可是你们从来没有见过：他们修着修着把路给修歪了，建筑工程师把楼房改着改着给搭歪了吧？而我们在写代码过程中为什么写着写着，自己认为写的是一个程序，可是写完之后，团队整体感觉你整个写了一个大BUG呢？那么差异何在呢？我们IT工作是存在于一个不可见的复杂性系统中的。复杂系统是很可怕的，因为当一个灾难事故发生的时候，我们都会进行根因调查，我们试图挖掘出一个唯一的根因，但是经过事后分析发现，任何灾难事故都可能是十几个，甚至二十个隐患同时爆发而产生的，而我们为什么不知道？实际上是因为我们没进行过敏锐的持续监控，我们不能持续地监测和持续感知这个世界，当然世界确实也是非常的难以感知。我们引用德国量子学家的一个定理“不确定定理”。我们在IT系统中也是一样的，就是世界对我们的挑战，是非常大的挑战，因为它是不可知的。所以除了在这个复杂的不可知的世界里，努力的实验和探索，不断提高我们对世界的感知度意外，没有任何人能预言您将会反的错误。
难点5：其他公司的DevOps实施路径是什么？我们就模仿他们来做吧？
（刘征老师）其他公司都已经上路了，刚才说了未来已经在诸位各位身上发生了，只是还不太平均。那么，现在其他公司实施的路径是怎么样的，是不是我们模仿一下就可以实现了？
张乐老师）这是我非常喜欢讲的一个故事，先让我们来类比一下人类发明飞机的过程。人类的飞行梦想源于非常遥远和古老的时代，但是人类真正的飞行实践，是源于仿鸟飞行。但是大家知道，无数次的尝试都以失败告终，人类的仿鸟飞行是无法实现的。这条路走不通，但后面的一些科学家发现，其实可以用另外一种方式解决问题。我们现在看到的飞机都是固定翼的，而不是振翼的（像鸟一样煽动翅膀）。因为科学家发现了鸟类飞行背后的空气动力学问题，包括动力和升力问题。我们现在飞机是基于固定翼飞行的模式，这源于模仿，但最终超越了模仿。
人类不是简单像鸟一样飞行，而是根据它背后的原理去进行发明、解决问题。DevOps也是一样，我们从模拟模仿开始，方向性没有错误，但是真正发挥效益，对质量和效益产生帮助一定看企业自己的特点和自己的问题在哪里，最终我们要超越模仿。
启动DevOps之旅的正确方法
（刘征老师）回想我们曾经于各种大型企业的工作经历，当我们要在这种企业里，启动任何一个转型之前都是先要探究一下，所需要遵循的原则是什么？回想十年前的一个项目，2007年的时候我曾经给建行实事过一个CMDB项目，我还能非常清楚的记得，当时郭总问我一个问题：实施CMDB的价值是什么？我们花这么多的钱买了软件和服务，能给我们带来的价值是什么？项目组另外一个甲方同事宏光问，你给我设计这么复杂的CMDB结构，让所有团队去维护它，那么是否能有一条所有人可以遵循的原则，这条原则应该是什么？
在很多传统的IT管理项目中，都有这种重流程而轻实践的现状。那么我们要在这里提出一些DevOps转型所需要遵循的原则和心法。在DevOps的转型过程中，我们可以参考的是：DevOps工作三步法原则：
第一步是流动原则。保证你所有的工作从左到右可以顺畅的流动，形成一个稳定的工作流。
第二步要保证持续反馈，在流动过程中实现从右到左稳定快速而丰富的反馈信息流，给你的上游工作者带来更多质量的反馈。
最后一条原则是，在整个过程中，进行持续学习。坚持不断的优化和改进。
（张乐老师）持续学习和实验也是一个很关键的话题。衡量一个商业模式是否成功最低效的方法是什么？就是把整个产品构建出来，拿到市场上找用户去验证预期的需求是否真实存在。微软也曾经分享过一个调查数据，大概只有三分之一的实验可以改进关键指标，也就是说无论你的想法看起来多么正确、多么合乎逻辑，最终也只有三分之一能对你的业务指标有正向影响，而其余的部分除了增加了系统的复杂度、降低了可维护性之外，对业务没有任何帮助。所以小步快跑、持续学习和实验是DevOps的核心原则之一。
那么带着这三个原则我们就可以上路了。下面请张乐老师分享第一个启动DevOps转型之旅的正确方法。
方法一：《DevOps实践指南》中的推荐的循序渐进的路径
（张乐老师）DevOps转型的前几步至关重要，这对于走向正确的道路非常关键，这里面我给出了四个步骤。
第一步是选择价值流，即首先分析转型要解决什么样的问题？企业中通常有两种类型的项目，一种是绿地项目，一种是棕地项目。绿地项目就是没有进行过任何开发，你可以在上面做任何事情，比如一些传统企业与互联网相关的应用，完全可以在企业内部划出一块特区，工作在现有繁重的IT流程之外，用更敏捷化的方法实施。
但实际上我们看到，在国外的DevOps企业峰会上，60%的分享都是来自于棕地项目，就是有很多遗留系统、已有很多现行的流程。那么这里的思路应该是问题驱动，找到影响业务目标实现的关键点，到底是发布效率问题、线上质量问题还是其他问题，然后选取应用的技术和实践也各不相同。
第二个步骤是可视化价值流，价值流梳理的过程可以对齐所有相关角色的认知，找到其中的浪费、问题和瓶颈。然后组建专门的转型团队，辅助以相关工具的支撑，对特定改进目标的达成负责。
第三个步骤是组建适当的组织和架构。组建市场导向的团队，招募通才团队成员，并合理设计团队的边界。很多大规企业生产效率非常高，并没有因为企业规模的扩大而降低效率，正是因为他们的系统架构足够解耦，并由一系列自组织团队负责对应的组件或服务，最终多个小团队组成一个庞大组织时也不失灵活性。
最后一个步骤就是运维和开发的融合。DevOps强调Dev与Ops的协同，强调下游给上游赋能，以及运维可以更主动融入到开发的日常活动当中。
方法二：《精益思想》中推荐的行动计划
（刘征老师）我介绍第二个套路，是来源于精益思想，这个套路对我来讲全部讲完可能需要一上午的时间，我就讲这其中对我感触最大的几点。其实精益思想是可以指导任何类企业做转型，做改进和提升；在这九个步骤当中，有几点对我印象非常深刻。
第一个步骤是寻找变革代言人，这不像以前那样，什么项目都等着领导往下面拍，CIO、CEO有了一个想法，就拍下来，大家照着做就行了。但是DevOps不是这样的，《精益思想》书里面所讲的观念，跟我没看到这个书之前的想法是吻合的，DevOps和精益都是中间爆炸式的转型模式，其实我们可以在中层，找到中流砥柱的变革代理人，他们有新意和创新改革的动力，有转型的主动性，这些人在组织中其实是大量存在，我们需要把他们识别出来。
第三步，寻找危机。如果我们做了一个项目，而这个项目是可有可无的，它能为企业挣钱多少无所谓；而我们还希望从中积累出什么宝贵的经验，这往往是绝对不可能的。你需要创造一个危机，不这样做的话公司就可能会倒闭，不完成这个项目的话竞争对手就会马上超过你。这样我们团队才能团结一心的来挑战这个危机。
第五步，制造行业经常改变价值流，他们会改变他们的工作流，更让我惊讶的是：他们会根据价值流的情况来重构他的组织。不像 IT行业做转型的时候，大家往往还犹豫不决的问是否要重新调整组织结构。另外在制造行业里跟咱们IT行业有一个区别，比如丰田这种公司没有开除制，所以他的内心是稳定的，放在哪个部门工作都无所谓。
最后一点是要同化你的客户，甚至是合作伙伴，也就是说，这不仅仅是你的部门做就好了就万事大吉的，而且还要把你的上下游，周围所有人都同化过来，让他们和你有相同的思想意识，遵循相同的工作实践。
（张乐老师）理论和方法很重要，但我们也要落实到具体实践，固化在具体工具中。下面我们快速介绍两个案例。
首先是一个使用开源工具为主实现的DevOps的工具链的案例，从敏捷项目管理开始，通过可视化看板管理研发过程的价值流动。每一张需求卡片对应到具体的代码开发，然后经历代码扫描、单测、构建、各环境部署、各级别测试，最终到发布上线、运维监控，形成端到端的持续交付流水线。通过管理维度和工程维度的整合，提升整个交付过程的效率和质量。
（刘征老师）这是美国的National Wide保险公司的案例，在这个公司历史上，在IT领域里面曾经使用过很多种框架：敏捷开发、精益和大规模精益，CMMI等；当他们实施了这些足够多框架之后，发现业务并没有得到预期的很大的提升，两年之前他们加入了DevOps实践，也就是说他们现在有四条实践路线，并且在同时做，他们在DevOps方面，套路是这样的，所有的业务条线的所有价值流都要遵循统一的“前置时间”这一指标，所有人拿这一个指标衡量。他们有一个非常好的蓝图，分三个阶段，在三个阶段中规定出目前状态、中期的、远期的目标，会将DevOps转型的路径规划的比较好，他们也有一个非常好的支持体系，他们内部有一个非常成熟和完整的咨询部门，这个咨询部门里有敏捷、精益的教练，和DevOps教练。这些教练会出来下到项目组里，给项目组进行一对一的辅导，保证所有的工作流，包括所有转型中的价值流可以齐步走，一起攀登DevOps转型这样的一个旅程。
DevOps的实施能力和效果如何评估？
（张乐老师）刚才说了罗马不是一天建成的，DevOps实施需要一个过程，有没有通用的标准可以参考和指导呢？
有人提出我们可以设计一个通用的DevOps成熟度模型，或者跨行业的DevOps标准。比如阶梯式定义一些技术、过程和组织能力的静态等级，让组织参与评估，然后组织的目标就是”通过”某个级别。
根据经验梳理一些DevOps最佳实践是好的，但业界的普遍看法是，在DevOps的领域几乎无法形成统一的成熟度模型和所谓的标准，因为这种方式存在巨大的局限性。首先，每个企业面临的环境和约束都不一样，高度监管的金融企业跟一个互联网聊天APP的技术要求肯定不一样，那么通用的模型显然很难全部适配。
其次，IT行业每年会发生剧变，我们使用的技术架构可能两三年就发生很大的变化，但成熟度模型、或者所谓的标准几乎很难更新，那么如何与时俱进？
再次，仅仅衡量一些静态的实践和技术本身，而不是度量对业务目标的贡献，那显然是不充分的，所有级别的实践都做到了，但对业务增长没有帮助，也就失去了改进的意义。
除此之外，上面图中还列举了很多问题，那么我们要思考，有没有更好的方法？
（刘征老师）先聊聊魔兽世界这款游戏，2005年发布的时候主要角色最高等级是70级，每隔一两年游戏会发布新的版本，会更新里面的角色、道具，人物的最高等级可能是70、80、85，你在2010年以前打到40级就觉得已近很强了。
随着游戏的不断发展，现在这个游戏的地图也逐年发生着巨大的变化，有新的大陆出现，也有新的角色，角色等级上限达到了120，即使这个游戏你还是一直在玩儿，可是如果你没有进步的话，几年以后你之前很牛的等级，到现在的话，也可能是很丢人的等级。
以这样的例子来说我们业务环境就是这样的，业务环境不断的变化着，你需要持续改进的是自己的能力。
（张乐老师）所以我们要有一个动态的、可以持续演进的模型，我们要考虑每个公司内部实际的情况，做针对性的改进，而不是一刀切的标准。我们要根据团队的特性做一些定制，并聚焦在实际的落地上。
刘征老师）我们都非常想成为一个高效能的组织，直接影响高效能组织的一些方面在于：每个员工个人的认同感，软件交付的效能，企业的文化，所有员工对职业的满意度。如果说这些点都是对效能的加分项的话，同时也有很多对减分项，我们需要减少他们。我们需要降低的就是：职业的倦怠感，部署的痛苦和返工。这些点又是谁来影响呢？然后是靠后的第二梯队管理影响因素。包括精益管理，这就是普世意义的经典精益管理理论，以及精益管理与IT行业嫁接，而形成的精益软件开发，精益软件开发今天不细讲了，还包括持续交付，也是软件持续开发的能力点。最终还是跟高层领导非常相关，虽然我说了DevOps转型依赖于中层的爆发，但是没有领导力转型的支持也不行。领导力转型包括：领导要有愿景，要认同我们个人，鼓舞我们的势气，这些都直接促进了那些管理方面。
具体讲到能力模型，上面这个图来自于这个《Accelerate》这本书，它把所有DevOps的能力进行了很多更加全面的分类，今天不做详述了。大家可以根据以后我们的资料会后去学习。
如何持续学习和持续改进
（张乐老师）我们介绍了这么多的方法和实践，但具体实施过程其实还是很有挑战的，我们如何能够一步一个脚印的做好呢？
（刘征老师）为什么说我们在小学、中学、大学过程中是持续学习，为什么工作环境中，那些自学能力差的人，往往会逐渐后退，他们的成长就不能持续了呢？这是因为我们工作以后，丧失了学生和老师的模式，在企业环境里，可能是没有老师/教练来手把手教你了。但是丰田可以做的很好，他们文化是要改造你这个人，改造你所有的思想和学习的行为，第一他有一套改进Kata的做法，这是一套科学的体系，引导你不断的提升，让你一个阶段一个阶段的改进提高。然后也会问你很多问题，这个过程中让你自己找出改进的方向和方式。
持续改进和学习是一个科学的过程。我们必须要有科学的思维。为了让我们更好的体会科学思维和思考，我给大家分享一个视频，这个视频是TOYOTA Kata一书的作者发布的。这个视频讲解了：科学观是什么？我们如何通过科学思维指导我们进行科学实验，在这个实验过程中感知这个世界，只有这样才能让你自己持续的提升和改进。
就让我们保持用科学的思维去探索这个世界。
总结：模型、实践及有用的资源
今天我们从DevOps实施的难点说起，介绍了有用的DevOps实施套路，也给出了建议的度量和持续改进方法。DevOps的体系非常庞大，覆盖了很多内容，我们需要持续学习。
（刘征老师）我们也想组织业内相关的从业人员和实践者进行线上的DevOps研讨会，我们希望让更多的人加入到我们当中，我们来研讨这件事情，长期进行研讨学习这件事情。大家如果有兴趣参加的话可以扫我的微信码提示我在后续研讨中可以碰面。
（张乐老师）最后想送给大家一句话，也是我非常喜欢的，Don’t Fight Stupid Make More Awesome。(刘征老师)翻译过来就是：别和傻叉较劲，让我们一起做些牛叉的事情吧！
关注
2018 DevOpsDays 即将席卷外滩！
1
官方组织
隶属国际DevOpsDays
核心组织
2
聚焦实践
DevOps实践
经验的分享
与探讨
3
回归社区
更纯粹
更自由
更有爱
这里“阅读原文”，观看演讲视频
以上是关于分享回顾怎样挑战 DevOps 实践之旅的主要内容，如果未能解决你的问题，请参考以下文章
DEVOPS架构师 -- 02Kubernetes落地实践之旅