DevOps 让大象跳舞——传统企业DevOps转型之路

白凡

分享：方炜-浙江移动云计算中心副主任
编辑：白凡

传统企业通常会建设成巨石系统，浙江移动在探索巨石系统的DevOps实践中遇到较多的挫折，如何让大象跳舞？浙江移动探索出了大象跳舞五部曲：减肥、练功、步法、改进、欢快，特别是深入探索康威定律，使Devops转型更简单，并总结出“Fast+”体系，包括组织、技术、流程、机制、文化等内容，供大家交流。

讲师介绍：
方炜，浙江移动云计算中心副主任，超过15年软件研发项目管理经验，浙江移动敏捷型负责人，SAFeSA、CAL、CSPO、CSM等敏捷认证。《Devops标准》核心编写专家。带领浙江移动软件研发进行Scrum、看板、精益、Devops等实践，总结出《Fast+敏捷管理体系》获得国家企业管理创新二等奖，并在中国移动集团推广。

方炜：我是来自于浙江移动我是云计算中心的，大家看到我下面几个证书（CSPO、CSM、SAFe SA、CAL）没有一个跟云计算有关系，全都是做敏捷这一块的，我原先是做敏捷的，后来慢慢转到云计算，我们说云计算现在讲ABCD云，A就是AI，B就是BigData，C就是Cloud，D就是Devops我们浙江移动会把我们Devops放在云计算里面，因为它是属于ABCD云计算里边。

1. 背景

我的题目是叫大象起舞，对于我们传统企业来说整个IT就像大象一样非常的大，系统早上的时候我还跟中国银行开发中心的人在聊，我们企业很多它有很多系统，还有各种系统会非常的大，互联网没有历史的包袱，它的战斗就变成一个狼群，天生就是敏捷的，大象，从这么多年历史传承下来就是变的很慢，这就是跟互联网的差异。怎么让这个变的更快，这就是我今天要讲的故事。

首先我要说的是大象怎么来的。
大象移动通讯经过了好几代的发展，现在已经有人开始说5G了，4G开始很普遍的时候大家已经说5G了，在这个过程中会发现我们的自身系统，我们的IT系统从1996年非常单点的小系统，后来变成了我们的计费系统，一个电话一打收多少钱的计费系统，到现在整个系统变成了CRM，CRM包含了客户、订单、交易、支付，跟互联网没差异的有可能就是物流还没有，通讯大的已经接通了，还有两个领域我们已经有一个宽带，宽带要施工，施工就是物流，我们看到跟互联网企业是一样的，但是我们的系统会非常庞大，庞大到什么程度？这就是庞大，大家可以看到这里，我们的系统有七百万行代码，互联网不会，两千万行代码能做Devops吗，我做不到，我们一个系统编译时间要30分钟，我计算过我们一个系统晚上上线，改一行代码，晚上上线要花8个人，就改了一行代码就要8个人，而且要三四个小时，我们改一行代码的代价就是好几万块钱，这是我们公司最大的损失。

我们要变，我们要变，IT部门说我们的系统要稳，我们的历史系统没法变，业务部门说我们现在到无卡时代了，业务平台说，我经常说一句话，业务口跟IT口有一个巨大的矛盾，主要矛盾，业务口希望市场的差异化竞争支撑口被收敛，做到同质化，最后发现三家运营商的系统是一模一样的。市场是不一样的，我们要解决的问题要改变的是IT部门，而不是市场部门。

我们有一个目标，我们的目标就是希望做个会跳舞的大象，会跳舞的大象会面对什么样的问题?

刚才说七百万行代码只是其中之一，最大的系统100个人同时改一个系统，一个包，这100个人同时在改，最小的一千行代码，1个人在改，我们的厂商有三十多个合作伙伴，每个合作伙伴的能力都不一样，我们还有系统，我们说环境，一千行代码的系统是不是不需要测环境，开发环境，只需要生产往上做就行了，七百万行代码的系统我们至少有五个环境，我算了一下有七个环境，开发、测试、准生产到生产，这四个就差不多了，没有，我们有七个，这是非常困难的一件事情，那我们怎么办？

我们的历程经历了三起三落，最早我放的都是敏捷证书，最早我是一个产品经理，在2014年的时候我还是一个产品经理，产品经理做什么？我们要改敏捷，不能改变那些系统，不能不改那些系统，做跟用户最贴近的系统，传统企业，如果有敏捷教练或者是Devops教练找你的时候，跟你说要改变，他一定跟你说先改一个系统吧，改什么系统，他很会挑，他肯定会挑比如说跟用户相关的电子渠道，手机上的APP系统，像平安，他们也是这么做的，把平安APP那个团队先搞掉，所有的都会这么干，而且一定会成功，因为他没有历史包袱，特别容易做，做的很有成效，只要把产品经理改变了，把产品经理的思维改变了你会发现很容易做，我就做过，一个系统要一年上线，产品经理的思维一改变，两个月就能上线，你会发现非常容易，那个时候我就被敏捷吸引了，太容易出成绩了，两个月，但其实，我们同时还做了两个项目，敏捷转型，我们发现根本做不下去，只有我刚才说的系统才能够做成功，所有的敏捷教练都不会带你做这样的系统。

我们又去找系统，刚才的系统就十个人，我们还是做一个类似的系统，但是人数多一点，这个系统我用三十个人来做，大家也是跟用户更贴近，那个系统我们做了，做了以后发现光跑敏捷，那时候我还是产品经理，我是开发部门的，一个用敏捷数管理实践，而不要说工程实践，现在更广了，先说工程实践，我们发现管理实践脱离了工程实践一定会失败，我举个例子，我们希望一个系统本来改成敏捷小迭代的时候，因为小迭代测试速度更加多，这个时候你的团队效率是变低了，同样的事情要做好多遍，原来两个月一次，现在要变成一个周一次，我们那个时候说感觉这个很厉害了，七百万行代码，七百万行代码一百多个人在做，能不能做？我们专门请了咨询公司来给我们做了一个月的咨询，最后的结论是干不了。
花了一个月的诊断我真的干不了，我只能在那种小系统上面，新的东西上面就玩一玩，玩了我们的Devops，这怎么办？正好是有一个契机近来有一些尝试就打断了，这是非常可惜的事情，我们自己再去摸索这条路，这时候我们要成立ETC，大家都说的叫企业转型组织，我们自己要不停的尝试摸索转型，我们成立一百人的团队的工具和十个人团队的工具是不一样的，它一定是更大的工具，那时候Jenkins还没有出来，你会发现那些工具都只能干很小的事情，企业级一百多个人的工具，我们自己建设Devops工具链。

看板，刚开始做转型的时候，我建议是用物理看板，物理看板能够很快的，物理看板看的东西很多，你一看就知道这个团队做了什么事情。电子看板非常那，你即使拿这么大的电视机都看不到全貌，一百多个人的团队，物理看板是看不了那么多的东西，电子看板是能够看到有很多的度量，那个时候我们还有一个Fast+体系，Fast+体系我们现在已经做到2.0。一百人的团队我们都做的有模有样，但是有一个问题，我们干的嗨，业务部门还是老样子，昨天我参加李智华老师的讲座，很多同学说我们IT部门怎么怎么样敏捷，产品经理或者是业务口一点都不跟我们配合，这个原因就是因为我们做Devops的目的是什么，我们不是为了企业而做，我们Devops是为自己而做，我们IT部门感觉玩的很嗨，感觉我们很有价值，这是错误的，这就是我们碰到的第二个问题，企业的业务部门价值体现不明显，我怎么样让这个事情，跟企业的价值更快连起来，Devops有三驾马车，整个IT让它敏捷起来，让它快起来有三驾马车，第一容器，第二个微服务，第三个Devops。明天的通讯运营商联通周一峰他会讲三驾马车，很多人找的都是同样的路。这个是不够的，在我们浙江移动我们又干了一个事情，在三驾马车的基础上我们做了大IT架构，大IT架构才是真正企业级的Devops，至少我自己这么认为，真正企业级的大IT机构，它的Devops全部是颠覆的，我们浙江移动Devops是这么来做的，他说你们很奇特，从来没有想过这个事情。

2. 大象跳舞五部曲

大象跳舞有五部曲，第一要减肥，我们大IT架构，我们巨石系统要解耦，最后形成大IT中台小IT应用架构，大中台，小前台，阿里提出大中泰小前台，为什么它是真的Devops，巨石系统解耦怎么解？

2.1 减肥：巨石解耦、大IT中台小IT应用架构

我们会把所有的系统进行拆分，第一个，横向拆分，把所有的系统横向全部拆成微小服务的应用。第二个我会把底层的ABCD的应用全部往下沉，把所有的前端应用希望它五花八门，跟用户体验相关的东西跟业务逻辑相解耦，这是我们两年多前画的，那时候是这样的解耦。

这是我们现在画的，会发现我们解耦的非常彻底，最后形成了真正大IT的结构，这个应该比上次云栖大会分的更细，我们云资源，云计算这一层，还会做技术中台的东西。我们还会有数据中台，我们发现企业的数据非常关键，还有业务中台，能效中台。我们的业务和IT，我们在处理的时候是融合的，业务和IT一起工作加速反馈，但是它只关心业务的实现，它所有的底层，就像昨天嘉宾说的，这个Fast+1.0是谁来干的？

不是这个IT团队来干，是下面的IT团队来干，你那个团队只关心业务实现，不需要关心底层的架构，这样小IT就会变的很小，可能两个人就能干原来十个人干的活，这是巨大的改变，怎么样让我的团队变小，不管敏捷Devops最好的就是团队都很小，团队很小但是我的战斗力不能小，我两个人能干十个人的活才是事情的关键，剩下八个人的活是从这里来，这里我为他所有的团队赋能，这些上面的团队都不是属于IT部门的，我举个例子，能效中台，我建立Devops工具，这个工具全部都是用我的工具，不需要自己再去搭建这些东西了，全部用我的工具。

数据，我会把企业级的数据全部都存在大数据平台上面，营销客户他要拿数据直接从我这里拿，我会提供一个数据网关接口，他们很快就能拿到自己想要的应用接口和数据的接口，还有能力，这就是我们的大IT中台。
在大IT中台做了以后这个Devops就变了，早期的Devops很多系统都竖型的，一个团队什么都管，其实就是Devops，慢慢的变成我要专业化，运维团队要运维能力，这个时候你就会发现系统变的越来越大，我们要合并，运营商的系统就会变的越来越大，我相信其他企业也是一样的，越来越大以后，团队要拆分，就是开发、测试、运维，开发负责实现，测试负责质量管控，运维负责我最后的保障这些都拆了，大家这个时候又开始协作了，Devops开发、运维一体化的时候，我们的解决方案并不是希望它的协作更长，我希望每个团队都是Devops的，这个时候我们要分成Devops，分成Devops，我把很多能力都往下沉，那个团队，像云平台，它的建设、运维都是它，包括测试也是它，我们Devops工具链能效中台也是它自己开发，运维也是它，数据怎么建设、怎么拿来维护这个数据也是它，业务中台，我发现电商跟我们一样，客户有客户中心，订单中心，支付中心，各种各样的中心，其实这些中心我们都会把它缩小变成一个能力，这个能力的标准也是它自己，最终跟用户交付的两个人干十个人的活，他的开发运维也是他自己。

我举个例子，大家做软件，做硬件也是一样，我前段时间去了华为的工厂，他们的那个流水线，五分钟就能产一个P20手机，很多元器件都是准备好的，焊一下就能完成，这些元器件就是它的能力，小前台只是把我的东西拿来焊一下，就成为一个新的应用，这才是真正的Devops，每个团队都是Devops，而赋能是它的核心，但是我们传统企业也想变成这样的是非常难的事情，我昨天跟电信就探讨了，只有你们浙江移动才能做出来，我说不是的，如果我们做不了刚才说的那个，我们说的业务部门跟IT部门在一起，如果不能在一起，业务部门不跟我们变革的时候怎么办？这就是Devops经常会说的特性团队，我们的小前台团队全部做成特性团队，一个业务部门我就一个小前台跟他合作，那个团队跟业务部门非常紧密，我们IT要往前走，我要适应变化，我们现在基本做到我们的人比业务部门的人更懂业务，除了他出去做营销做不了，但是他的业务是非常精通的。

我们自己小前台的团队还在IT部门，但已经它跟业务部门是一对一的，能够实现自己这个团队的交付，所有的交付都在这个团队里做，可能大家会觉得本来就是分前端、后端、多个模块，按系统去分团队更方便，但是在大IT里面，我已经把这些东西都沉淀下去了，都沉淀到我们这一层去了，沉淀到这一层的时候，你会发现每一个成员团队都是可以独立交付的，就像华为的流水线，所有的东西拿到以后独立交付做成一台手机。
运维怎么办？Devops都拆进去了，运维怎么拆？我的运维我认为分三层，以后的运维分三层，第一层是平台运维。第二层是应用运维。第三层是业务运维。
平台运维我跟着云计算走，它做整个底层能力的保障，包括云的技术的保障，应用能力的保障，全部都在这个团队去做，负责所有的底层。
应用运维，就是做连续性，我跟业务没有关系，我保证系统不瘫，我举一个阿里的双十一，阿里就有希望持续保障团队，我保证双十一的量再怎么冲下来我都会保证这个系统不会垮。
业务运维，是负责业务准确性的，业务准确性它就应该跟开发走，因为开发做业务错了，业务错了谁最了解？开发最了解，我们就跟着开发走，刚才的大IT图里面，分别都有自己的ops，第一个我们就会转变，而且现在的系统就这样拆了，我们没有七百万的系统了，我们全部拆的很小，所有的系统基本上能够做到编译都是在分钟级能够编译成的。部署因为系统拆的太小了，部署还是会花一段时间，怎么让部署变的更快。

2.2 练功：企业级能效平台、技术平台化

第二步我们要平台去支撑它，我们有三大平台，第一个整个管理实践的平台。第二个我们CRCD的交付平台。第三个就是云平台，三驾马车。

第一个我们需求管理平台。
阔步和敏捷里的差异，大家都会说价值流、流动什么的，首先我们要看的是可视化，第一点看到全貌，看到这个信息你就可以知道自己精益里面的浪费在哪里，可视化是最关键的第一点，在我们平台很突出的就是可视化，我们会建立电子看板，还有燃尽图，待会儿会讲燃尽图。

交付平台，我们在企业级的交付平台，全都自己干不可能，很多都是开源上面去做的，我们做到资源分配，应用配置，开发部署等七个流程都是一站式的，比如说我点一个流程，测试到发布，上面就有一个小人在不停的去跑流水。

我们应用我们的构建基本上到分钟级。部署，我们拆的很小，现在我们部署非常多的系统，我们要通过这个工具，我们15分钟能部署500个应用把它部署上去，一个月测算速度九千多次，这就是我们刚才说的七个环节的能力，不细讲。

要不要开源？我们遇到了很多坑，如果你的团队上千人要做的话，我建议还是做定制的开源。

光有这两个管理平台是不够的，就像我们的标准，云平台的核心，如果没有做docker，我认为这个事情是非常难做的，为什么我说15分钟就这么快，因为我们全部都是容器化的，在容器平台。我们把私有云建成什么东西？很多企业不会考虑说我的公有云跟私有云一样快？我们的目标，我建云管平台的时候，我会画精益创业画布，第一个解决的就是痛点，第一大痛点我获得资源太慢了，不够敏捷，我做一个云管平台最重要的痛点是我的资源利用率低，不是的，你要为企业建立价值怎么让他更快的获取资源、获得部署。我们说十分钟一定给你资源，代码写好，你在上面写代码，写完之后你直接部署，10分钟搞定，不是说我要拿什么机器，配网络，不需要。我们跟厂家做了统一的框架，我们在docker的基础之上加了安全的东西，所有的人，厂家，都能够跟我们一起做成统一的共享。

就是微服务管平台，也是做了很多的工作，这些都不细讲了。
做完这个东西我们的业务效果，我就认为我们的云，我们是云计算，为上层提供的能力，首先我们是所有的管家来做，同时我们又是敏捷开发的催化剂，同时我们又能高质量的保证我们的中台，最后我们也是希望ABCD云智慧云，这就是我们现在在做的事情。

2.3 步法：以Scrum为基础的敏捷开发模式

刚才说的应用解耦了，我们有平台了，但是我们的流程如果还是老流程这都没有价值，我们在做scrum，我待会儿会讲开发管理，我们做这一整块东西都是在Scrum以可视化为基础做一些我们自己的东西，我们也做相应的流程，以Scrum为基础怎么做？开发和业务怎么去协作，在Scrum有很多的会议，

我们的Fast+会议，相当于需求细化怎么做？我们做一个迭代大家确定好东西，大家很自然的会想我迭代开始第一天会做细化、设计，第一天得做需求细化，完了再做需求的设计，做开发、测试，这个时候我们发现我们的团队这是有问题的，不管怎么做都会变成小瀑布，我们会怎么做？

我们从需求的策划，我们更关注用户交付的时候，把我们UI这部分的东西全部放在这个时间，上一个迭代去，你会发现这个迭代做的事情就好了，通常我们会说就是燃尽图，刚开始怎么办，前几天就是下不来，就是荡不下来，你会发现一个迭代开始，我开始做了，其实不是的，你在上个迭代，我们尽量让上一个迭代能够把这个迭代准备好，我们会帮助开发团队更好的实现这个事情，这个时候你就会发现测试团队特别慢，测试团队怎么慢？

测试团队他们说我们刚开始，会做编写，前几天做编写，我再准备环境，最后几天就下来了，燃尽图你就能看到这个怎么做的，这个时候我们就会说测试团队能不能改变，能不能让他按照我们的用户布施的要求去做，我们来看燃尽图的时候，为什么要做电子看板，你可以很方便的看到在迭代的过程当中有没有按照你要的方式，最后交付不就是这一天交付吗，我关心这个过程干嘛？

敏捷，你要提升IT部门，我刚才说的矛盾，你要提升IT部门适应变化的能力，你如果还是这幅图，当他在这里适应变化的时候，你干了可能会替代需求的设计工作和需求理解工作，这是浪费，最好是只干你这个迭代要干的事情，提前干的事情都是浪费，一个故事一个故事把它宕下来，在迭代的过程中你只要没有替换刚开始的故事就行的。我再企业两周一迭代的时候变化达到30%-40%，在迭代链的变化，我们业务部门已经习惯了快速的变化，而且我做了这个以后？那个时候我离开了开发部门到云计算的时候，开发部门还是两周一迭代，为了防止他出现太多的波动，任何的一次变革刚开始都会有波动，我们没换两周一迭代，现在的开发部门自己改成了一周一迭代。

我们为什么要做这些实践的时候，大家可以看一下敏捷联盟的最佳实践，最佳实践拿去企业级不一定都有用，为什么要做？我的思考，你要对好自己为什么要做标准转型，你的作用是什么，为企业带来什么，这些实践才整套的上，今天我就不详细说了，我这只是一个导图。

2.4 改进：测评驱动改进

最后是测试驱动，Devops标准要不要？要。

为什么说Devops标准是敏捷开发是我们浙江移动参与比较深的，在开始写之前我们有了自己的敏捷深度标准，每个月都会做测评，发现团队的问题去辅导团队，这是很重要的事情，现在也是用联盟的标准。

2.5 欢快：DevOps文化建设

最后一个叫欢快，文化是最重要的，文化很多人都会说第一位，到传统企业文化第一位你是非常的难做，所以我把它放到最后一位，你把前面的做好以后，文化自然会起来，就像我刚才说的开发团队自己会把自己的两周变成一周。

3. 总结：FAST+

我们讲的Fast+2.0，今天讲的Fast+都是2.0，Framework讲的是组织，我们的组织要变革，康维定理说我们的组成和基层架构会趋向一致，我们浙江移动的组织就是在这样。

A就是敏捷平台，敏捷交付平台是一个能力，这个能力非常重要，我们要建设这样的平台。

第三个就是流程，对于一个传统企业来说，我个人认为Scrum会更快，让你上手能力会更快，我们还是觉得Scrum会方便，因为我们用大IT架构去解决Scrum这个事情。
第四个就是T，就是我们的+文化。

这幅图不是我的，我在网上找的咨询公司做的东西，他在说敏捷的时候，你会发现我们的三起三落就是这样，你会发现业内都是差不多，只是今天我用了浙江移动的案例跟大家放一下。

最后一页，我们到底是为了什么，这幅图告诉我们，工厂要生产，工厂他会买一个机器人说提高效率，让工厂流水线更快，真的是这样的吗？我们做Devops，其他人跟我谈的时候，我要取经，好的，我说干什么，你们给我一个工具，干什么，他说提高效率，提高质量，不是的，效率、质量，我不认为它是我的目标，它的目标就是一个，为企业赚钱，在赚钱的过程中你会发现你要做Devops，怎么在赚钱的过程当中做到Devops这个事情这才是核心。