大型企业实施DevOps的三个阶段

luna

作者：万金 《DevOps实施手册》译者

《DevOps实施手册》介绍

我们现在开始我的分享，先讲一下我为什么要翻译《DevOps 实施手册》这本书，有人说现在发展的太快，但是在我的这本书里面叫DevOps实施手册，比如说像福特汽车的生产流水线，像丰田的生产，还有以前开发的思想，这并不是近期出现的，在这些思想的基础之上我们的DevOps应运而生，让开发更为高效，希望这本书能够帮助到现在在做DevOps的企业，能帮你解决现实的问题。在书里面会介绍自下而上的实践，如何让领导者和参与者到DevOps里面去，这本书里面有两类DevOps的实践，后面会进行详细的介绍，主要是制造还有一类是常见的比较多的DevOps的一些自动化实践。

目录

消费改变需求被满足的方式

我们开始今天的正题，首先我们来看看，按照以往的方式DevOps一定是要提高效率，我们提升效率，降低成本，把一台汽车做到2000块钱，和手机一样的价钱，福特汽车在2014年的时候引进了流水线，市面上有90%的汽车都是由福特来生产的，提高了生产效率，随着六年之后，流水线优化、时间，十秒钟就能生产一辆汽车，你花一个手机的钱就能买一辆汽车，而且生产的效率是很高的，老福特的创始人有一个笑话，他说我的客户可以选择任意一种颜色的汽车，只要它是黑色的，为什么呢？因为它的生产线里面喷漆生产线都是黑色的漆。我们在生产线做了六年的优化，把效率和价格降到了极值，但是再过六年订单远远低于了产量。

当我们解决了交通工具的时候，2000元买了一个手机，下一个汽车我要买什么样的呢？不再是2000元的汽车了，所以通用汽车占领了市场，不再成为红极一时的汽车了。我们说到汽车可能我们都有这种，有5万元的汽车，有十几万元的汽车，还有三十几万的汽车，不同的汽车为什么定这个价，买的人买的是什么。比如说2000元的汽车，你做到了所有的需求，这种需求是够的，这就是初型代步工具，那么如果你有更高的需求，更强的动力，更大的空间，在车里面听个歌，这就是一个期望的需求，如果这样需求得到满足的话用户的满意度是直线上升的。

还有另外一种就是兴奋性需求，比如说我想买的那辆车有自动泊车功能的，还有如果有的车后面拿东西的时候，拿着一个东西想放在后备厢里的时候拿脚一滑后备厢就开了，这就是特殊场景的需求，这就会让你很兴奋，或者有自动驾驶的功能，儿子要上幼儿园都是要开车去的，如果有自动驾驶功能的话是可以做到的，最简单的来说就是黑科技。

我们实现用户的需求有三类，这三类的需求客户对产品的评价有非常大的差异，而这些需求比拼的能力也是不一样的，我们接下来看一下我们在不同需求下面我们要做哪些方面的设计和考虑，对基本需求来说要注重流程的设计，我通过我们的严格流程，减少产品失败的可能性，通过部门之间固定流程的分工，提高部门内部的效率，因为比如说像软件产品，基于需求，我的需求几乎是不变的，这就是第一类需求要做的事情。如果要做第二类需求的话就可能有很多定制化的需求，这就要考虑客户调研，比如说要白色的还是要黑色的，或者是金色的，但是谁也猜不准市场的需求，这就是调研客户需求的能力，这就会把我们的产品退出市场的速度和成本降低的最低。

我们怎么知道客户在某种情况下使用产品会感到兴奋，比如说像脚滑一下就开后备厢，这个就要知道客户是如何用的这个产品，情绪是怎么样的，要有深刻的了解，我们简单来看一下，我只要降低成本，反正车都是一样的，就像买电、买石油都是一样的，只要成本最低就好了，对于这种模式还是可以讲一下的，在十年前左右，我可能在一个通讯公司里面，它研发的模式就是有一些业务分析，去收集客户的需求，然后把我们通用的软件或者新的软件来满足客户定制化需求，这样需求就考虑到通用功能的研发，还有就是定制团队的研发，这两种团队工作模式还有对工程师的能力是完全不一样的，他们之间就要高度的协作，具体功能是否要拉出来一个分支，这都是需要很好的配合的。

谈到兴奋型需求，要对用户的情绪和行为感知，你能感觉到客户情绪这件事情基本上是做不到的，但是有大量的数据和互联网上，很多时候用户再不来了，这样的客户情绪是失落的，只有了解到用户怎么使用该产品，在产品过程当中情绪的变化，你才知道你如何研发出来。我前两天跟现在在腾讯的视频在聊，他把抖音和另外一个视频分享过来，划了30条，里面抖音就做到了，这就是一个算法和数据结合的产品，怎么样抓住客户的喜好，典型的角色就是产品了解，用户的年龄、喜好，对用户做一个调研。

从需求来看我们满足三类不同的需求，结构是不一样的，如果我们想逐渐提高用户满足和需求，比如说以前流水线生产出来就结束了，如果把需求联动，最后再到与用户的协作，与客户协作的场景，这样的话一定会有变化的，从需求、研发到业务运维整个的协作过程，你只有打通了协作，把整个协作的过程做的很顺畅，业务才会更成功，这是我最后的结论。分工一定会带来更好的提成的，但是过度的分工，比如说30多个工具，过度的分工怎么去全局、系统性的打破这个窗口，提高整体的效果，这个才是我们做优化的关键。

企业核心竞争力来自于协作效率

我们现在开始分析用户是什么样的，我们企业应该如何做好，这个是一个例子，也在IBM做过五年的时间，它是以大型机为成功的产品，但是使用相同的产品，IBM在企业计算机领域使用相同的技术战胜了科研领域的UNIVAC，有些看不上给企业的会计或者秘书做这些，但是我们现在知道了，在企业上面我们的规模是非常大的，IBM在这个市场里面获得了成功，我们所说的企业竞争力是你服务的对象，你服务的市场是否足够得大，这是第一个前提。

第二个我认为是企业的核心竞争力在于它有能力去建设一个新的价值网络，价值网络源自于传统的供应链，我生产什么我给我的供应商下单，但是下单的规格还有数量变化是很小的，但是对于价值网络来说，两个小时是工程师给中国的工厂去下新的设计图纸，两个小时以后整个图纸上进行了改变，24小时之后就可以生产出来新的了，但是我们中国的价值网络能力非常强大的，是世界第一的。下面的这个是2007年的时候诺基亚的手机，也许有些人用过其中的一个型号，放这张图的意思诺基亚很好的满足了我们对手机外观多样化的需求，但是被另外一个外观只有一个，而且每年只出一款手机的公司打败了，为什么呢？它做了IPhone手机，让广大的开发者去加入这个协作网络里面去，让这个手机从只能打电话到个人的效率提升的工具，可能我们现在真的是一分钟离不开手机，可能在十年前不是这样的，现在对硬件进行了提升，更大范围内协作的网络。

现在基于云计算的平台，这是三家公司，每个人都有自己的布局，电子商务的数据，安全、或者说社交的一些应用里面，这些图标可能大家都用过，这就是要收集用户行为的数据，感知你在用他们产品时候情绪的变化，从而把产品越做越好。组织数据可见性，其实是说构建一个生态的话，在范围内你的信息数据，在云上的这种协作交易成本非常低。第二个就是自动化的基础设施，像我昨天参加供应链的会议，现在已经有成绩了。我们所说集中化和分布式，本身有利也有弊，像一块石头一样一定是非常坚硬的，我们所说的我们要在中心的平台上面做出一些事情，可以在自己的小团队里面做一些工具，有不同才有比较，有比较才有不断的创新。

企业竞争力在于外部的协作，我们都认为我的企业做的好是我企业内部的管理好，我企业的效率高，所以我才有竞争力，其实不是这样的，企业的竞争力是来自于外部的协作，你能加入多少，比如说像生态的合作，或者是说供应链也好，或者是价值保护也好，只有企业在价值保护当中提供足够多的价值，这才能体现出你的竞争力。在云计算平台上构建这种生态，对于云计算来说是非常容易的，就像以前的系统可能会在公司内部会有不够满足的行为，最后要说的一点就是以前我们一些商业产品或者说实现需求一定要达到一定的批量，只有大规模生产才能降低生产，就像流水线一样，做的廉价、高效，但是对于云计算来说，你有一个生态，有一个公司，有不同服务的供应商，这个就非常可怕了，有些定制化的工作，或者重筹的平台能满足一定环境下的需求，这个云计算具有比以前更提升的能力。

大型企业实施DevOps三个阶段

下面就切入正题了，实施DevOps的三个阶段，首先我们说这个是系统的革命，是系统性的工程，不可能说我把一件事情做好了我的DevOps就完成了，提升研发效率的3D原则，我们在类比集装箱运输的体系，我们在工程运输和用户的过程当中可能有这种集装箱很散，不是用一样的货物，不断的拆包、解包，从汽车运到轮船，在中间的过程当中我们损失了非常大的效率，这个3D原则是在二战时期，美国军方去运输非常多的货物到战区的时候想到的，基于这个原则我想到了我们在软件研发的平台上面怎么能把效率一次性的提高，就是说在部署的时候，构建打包的时候不要二次再打包，第三就是我在部署环境的时候，我有一个一次发布所有环境的能力，在每一个中间过程当中我们损失了非常多的项目，我们遵循这三个原则之后我们在中间过程当中就会更高效。

这个是一个把一个软件研发过程当中所有的步骤拆开，下面这句话我非常喜欢，比日常工作更重要的，是对日常工作的持续改进，其实我们每个人都在做很多工作，可能每一天都会比前一天进步很多，之前有老师也说过，这是来自于一本书的公式，上面是实际的工时，下面是总工时，你对实际产品产生价值增加实际的时间，如果我们能把顶上的时间逐渐的扩大是不是就在提升我们的效率，最后算出来的效率乘以16%，原因就是很多的工作都有等待，有的工作有返工，减少这种浪费之后我们的企业效率就会不断的提升，就算20%，我们再提升的两倍、三倍是绝对有可能的，这个就是DevOps能做到两倍，十倍或者二十倍。

随着时间我的业务在更新，像这几个积木一样，所有的技术都是不垂直的，需求和利益也都是参差不齐，我们所说的DevOps变革，就向扔一把扑克牌，落地之后就是整整齐齐在那里，这就是DevOps兴奋性需求，如果谁的DevOps能实施到这个程度那真是体赞了。

怎么做到的？首先我们要考虑两个因素，其中之一就是我们要做敏捷，敏捷是什么呢？就是说我们把我们每次交付的时间缩短了，缩短交付的周期，第二个例就是我做精益，我减少刚才所说的一些浪费，结果就是这样了，只要持续的改进，最后的结果一定是把我们软件研发的过程，到最后的生产，甚至是运维的环节做到统一、高效。

我们说DevOps最开始发展的时候是在促进研发和运维的协作，但是在我们来看，现在面临的问题业务是要获得回报的，我们DevOps整个帮助业务的时候要获得更多的回报才是实际的，自上而下的实现要求的是统一，因为我要做这种DevOps时间的话我在公司推广的话一定需要非常大的成本，把实践进行标准化，这就是要做的事情之一。在这个过程当中要有风险，怎么能保证干这个肯定能赚钱，一定要有风险收益的可控。

业务思维的DevOps，投资拿钱人是听不懂你这个的，我们要把DevOps提升的收益和结果翻译给业务人员能懂的语言，比如说我们可以让我们的产品提前上市，可以让我们的生产更加稳定。下面说业务会产生新时间，而我们工程师很多时候都喜欢去研究一些新东西，这个很好，但是很难去说服老板，如果你有很多团队在做这种尝试和创新的话，其中有各种比较的话我们就能知道我们系统里面下一步创新的方向，所以说其中自上而下也好，从分布式的创新也好都是一种更好的创新。

企业级与团队DevOps实践，如果在一个大公司里面，有4000多人研发团队里面作出一种工程实践，有些可能是集中式管理的，先保证工具与实践标准化，每个人都不喜欢改变，但是我们还是有好奇心的，我们DevOps团队里面一定有这样的人，想去做一点新东西，让这样的人发声，让这样的人组织语言去宣传它的新的产品。公司是鼓励创新的人，创新的人得到报酬也是会让更多的人接受DevOps的变革。协作信任，很多时候并不是老板不信你，而是老板听不懂，只有把DevOps的好处和收益翻译成业务人员听得懂才能进行沟通。

这里有没有想回答这个图片上的问题的，上午有位老师说这个曲线是有含义的，我也特意画了曲线，真的是不谋而合，我替你回答吧，首先来说 做任何实施的时候都有学习成本，你要把手头的工作放下来，然后我们再做工作当中一定会遇到不可知的问题，一定会让你目前的工作有一定的效率下降，随着我们逐渐对工具流程的熟悉，我们的效率会逐渐提升，这就是我们在做试点的时候一定会把这个试点做调整，因为你投入了资源，拿了很多的资源和人力，给你很大的权限做这件事，这是一定能做的，但是你在这个标准化规模推广的时候可能就没有试点的那么好，因为很多条件，所以就意味着做开放实践一定是曲线，先向下有一个磨合和适应的过程，虽然大家能力不断提升会不断的找到最佳的准备。

简单讲一下这个过程，首先要有一个路线图，下面就是说要有一定的试点团队做这种恐惧和实践的标准化，要观察你投入多少资源，获得了什么样的收益，限制条件是什么，可能对你将来的规模化实施会有影响的，要有发展持续改进性。今天我讲的东西之前可能提到过。最后就是在事实DevOps的过程当中并不是我们这种工程师自己去做的实践就完成的，一定要有领导去推动这个实践，投入资源，认可这件事情，我们做完了实践之后，也会为业务带来效果，领导会认可这件事情，才会这样的非常好的结果，要不然是没有效果的。

做任何东西都是在做服务或者是产品，你做DevOps的变革也好，能力提升的变革也好，也是一个成果，不要让用户去思考我怎么去做开发，做DevOps的变革很像建设，要自己变得强，要自己有这个能力，有不断提升的能力。第二个就是说我要清楚设计这条路，我知道我生产率的下降，我会慢慢的提升，就像这个生产线一样，最后会达到一定的水平，要保证底线，这样的话会平稳的过渡，不会受到很多的质疑和煎熬。

我会有一个控制，因为资源有限，不可能让老板把所有的资源都给你，资源有限的情况下怎么能让业务人员也好体会到DevOps的价值，做好最优的。比如说我上线时间从一个月变成了一周或者一天，这个绝对是让老板爽到爆的，这就是绝对的体验变化。

我们可以做了一年的DevOps，大家都那么辛苦，能不能让老板花点钱发点奖，这样的话每个人在年底都会有福利，这对作出贡献的人会很好，比如说你再说要投入DevOps会更容易。第二阶段就是交付方式，我推进了很多需求，在最后交付方面没有办法满足效率，只有从系统性的把整个效率匹配做的好，才能把效率整体提升，在我们做试点的时候，这是第二部分做试点的时候，我们要考虑到投资回报率，不是说我们做到最好，是做到什么程度，还有就是说我们所需要什么资源，这是在大规模推广的时候体现的。

所有的DevOps都像要求爷爷、告奶奶一样，为什么要求人呢？因为人家的工作里面本来就没有DevOps，比工作更重要的是工作的感情，如果每个人不这么想的话就很难去改变，我们的工作可以认为是一个领导部门，有很多研发，在研发项目里面有很多角色的人，他们之间是有一定的联系的，是一个测试的峰会，会定期的见面、分享一下最近做的一些事情，比如说像两个部门里面，一个大公司或者一个团队里面会有一个DevOps工作组，会不定期分享案例，或者是组织一些评选，这样的话你的小团队的分布式的实现就会被整个组织看到，这样的话慢慢就会被所有人看到，从而达到我能从自身去实践，而不是一直在外面。

最后还是说对领导的培训，做个广告，有的人真的把我的书给老板看，有些话可能不太适合说，这些话我也不适合跟领导说，所以我就拿这本书说事，把一件事做成功，得到公司的认可，这才是正确的做DevOps实施的方式。首先按照我说的做一定会有不错的效果，明确商业化明确收益率，团队模型不断产生新实践，让分布式的实践让大家探讨，只要让大家探讨一定有效果，不用推，就直接能看到效果。

DevOps五个能力能级

首先就是我的一个思考，公司有三个等级，产品、平台、生态。

对于环境来说分为五类，最复杂的一款是无序，如果在这种环境下做实践的话你想这个难度会多大？

这是对环境的描述，这个是演说里面对工程师成就的一个分类，也是五类，不小心都是五类，最大的一个等级就是开创一个产业，比如说像开创一个产业的人应该算一级的工程师，其实只有达到了6.5，能生产一个独特的产品，达到这个就可以了，其实我们每个人能完成自己独立的就要就算是一个一级的工程师了。

最后就是我想说的，我们的环境、我们的标准、等级，比如说服务个人的DevOps，极限就是服务所有的工作在这个工具上都能完成需求，第二个就是我在团队内部协作，我每个研发团队内的协作的时候是不是能满足我的需求，能让我所有的信息投入，还有就是有需求，所有公司内的同事要做这些业务的话就涉及到一些部门，让他们也进入到协作里面去。平台和生态就是我今天说的，你能引入多少外部协作的力量和资源，就是你们公司竞争力的体现。

当你满足基本需求的时候消费者一定会有最高的需求，如何满足更高的需求？就要不断的扩大协作范围，这对你的结构有非常大的影响，我们可以跨越这个影响或者其他来提升效果，提升自己公司业绩的要求。第二个就是说技术和业务的变化带来的组织模式的变化，就是说我刚才所说的，让4000个员工按照相同的规则做研发。大型企业通过三个阶段实施DevOps，首先要有路线图，要有商业化的试点案例去明确你的投资回报率，让老板继续扩大你的试点的范围，这样才能全面的落地。我对DevOps的服务，引入多大规模协作的思考。