从1到N的挫折和重启

白凡

作者简介
段新

我分享的话题是《从1到N的挫折和重启》，我主要是从四个方面跟大家讲，大家都说从0到1是很了不起的事情，从0到1的高光时刻不是今天的重点，重点是后面的三部分，就是从1到N的挫折和踩坑，然后碰到了这些问题之后，我们是怎么做调整的，就是怎么做一些重新的思考，以及怎么样重启在企业内部做规模化的推广思考和探索。因为这一次分享的主题是企业规模化的建设，所以我也觉得很适合今天的话题。

一、从0到1的高光时刻

中国移动广东公司（广东移动）在2017年底、2018年初，当时通过自己的团队，通过自研的形式，采用了全开源的工具的形式，搭建端到端的开源的DevOps流水线，基本上用的都是开源的组件。当然在2018年初的时候没有钱买JIRA，其他基本上都是开源的组件进行自主搭建。所以有一些话题不知道跟大家是否有共同语言，因为我感觉很多银行业或者金融业的很多工具都是自研，你们说的自研是真正的自研，而我们很多时候是基于开源自主搭建做的集成，对Jenkins做了二次开发，也具备提交代码和部署的CI/CD能力，所有的工具链都是基于全容器部署，包括构建的环境、部署的环境是基于全容器做部署。当然中间会应用到企业的PaaS平台，可能跟大家都是大同小异的。

我们当时是在2018年11月份左右通过了持续交付三级认证。当时我们参评的项目是一个非业务的平台，当时用的是微服务治理的平台，可能大家在自己企业内部做微服务架构治理和转型的时候可能都会引入这个平台。没错，我们当时就是拿这个项目、拿这个平台，作为通过DevOps三级认证的试 点项目。

如果有同事对微服务架构或者架构设计比较清楚的就比较了解，基本上是传统的微服务框架应该有的能力，包括配置中心、注册中心、API管理的能力。

这个项目当时有一个特点，这个项目当时是一个新的项目，这个挺重要的，我后面分享跟这个有关；

第二，因为运营商的IT主要还是靠以外包为主，当好我们这个项目外包的厂家是比较靠谱，厂家比较注重单测，一开始单测覆盖率就比较高。

我特别同意刚才方老师的分享，很多时候单测覆盖率是我们通过评估认证的绊脚石，很多时候很多项目在评估的时候都是因为单测的原因导致进度延缓或者最后的分数不是很高。再一个是这个项目本身自己也是微服务架构的，所有的采用容器化部署。这些条件、这些因素，就导致最终的交付的结果比较快速、敏捷，所以最终能通过三级的认证和评估。

二、从1到N的挫折现状

当然我们在2018年11月过了评级之后，我们当时领导层面给了我们两个接下来要做的重点工作：第一个工作，评级过程当中，各位评委、专家包括信通院的晓玲等专家都提了很多意见，一方面要尽快把平台的能力补齐；另外一个方面很重要的要求或者任务是能否尽快从1到N，能够真正把企业的效能，至少把整个团队部门的交付效能提升上来，因为一花独秀不是春，这样的话整个项目所有的交付效能的提升，才能体现团队或者组织级领导的绩效，所以当时有这样的要求。

我们当时也是这么做的，我们当时是基于去年评估过级的流水线，我们在短时间之内快速接入十几个到二十几个的项目，这都是我们自己内部的一些项目，这是当时仓库里面项目的名字，也有一个命名规范，有的模块多、有的模块小一点。

但是接入之后我们发现一个问题，就是整体效能并不是很高，我们单看平均每天Git提交的次数，都会发现很多项目可能一开始是尝试性的做接入，到后面基本上用的比较少的，只有部分的项目还是保持了比较高频的提交、构建，就是真正在使用咱们的流水线在做一些构建、集成和交付的工作。

我们当时也很郁闷，就是为什么标杆难以复制，我们都已经过了三级认证了，而且供应商也都给大家树立了一个表率，为什么当我们大规模推广的时候会碰到大家不买账的情况？接入的项目挺多，但真正活跃的不是很多，只是非常少数的明星项目；很多时候是常试性接入，后面由于种种原因处于停滞或者处于维持的状态。我们当时就回顾思考，有“三问”，就是反思为什么接入之后活跃度很低，为什么接入很困难，有一些项目你跟他聊，他说你的流水线接入很困难，门槛太高了，为什么很多人不愿意接入？当时带着这些问题，其实我们也跟很多的合作伙伴和供应商做了多次沟通，也是大家私底下谈心，想看看为什么会出现这种局面。

我们后来也总结了一下，发现制约从1到N规模化推广的种种困难，当然这是我们公司、我们企业内部的问题，我不知道大家有没有共鸣，我跟大家简单分享一下：

1.价值认同的问题。不是每一个都真的发自内心地觉得持续交付或者DevOps能够给他带来价值，或者他会评估投入产出比，他会觉得这个东西好像有用，但我投入那么大，我获得的交付的提升到底是否值得，他会评估这件事情。特别是如果DevOps的转型在企业或者团队内部不是一个自上而下强压下来的任务，或者平级推进的或者是自下而上发起的自我改良，这时候更加困难，这是价值认同，大家对它的价值和意义不一样。

2.害怕改变，很多人害怕改变或者改变一个人的行为很难。特别是很多时候底子太差，大家认为学习曲线太陡峭。我们工具链有一堆工具，每一个要用的溜，每一个都要长期学习，大家都觉得学习曲线太陡峭了，特别是外包商的底子太差，不愿意做这样的事情。

3.疲于应付业务，无暇做改变。他们就说我现在很忙，开发代码业务需求都来不及，没有时间跟你做接入和改造，这需要我额外付出大量的人力做这件事情。

4.担心改变对业务开发的影响太大，这确实是一个事情，特别是跟架构和环境关联在一起，这就会变成一个问题。因为在我们的项目里面，一些核心的系统都是建了十几年了，就是说这些系统都是零几年的时候开始建的，大部分都是十几年以上的单体的系统架构。我也跟很多企业做过一些评估和交流，我发现大家很多项目有的还是比较新的，就是最近几年才建的，所以说有底子比较好、先天条件比较好，很多时候就算不采用微服务框架，也是组件化的、解耦的，但我们很多系统都是十年以上的单体架构。第二，我们一开始新建的流水线起点很高，所以当时是基于容器做部署，但现在很多系统并没有完成容器化部署的改造，很多时候还是基于虚机做部署，所以整个部署的环节，你会发现通过流水线弄的和他实际想弄的根本是两套，这也是很重要的原因。

5.并不是每个都会在我们受控的环境下开发，很多时候有一些外包是离岸交付。他说我可能在大连或者我在成都某个离岸的交付中心，我希望我能够远程交付产品甚至代码，很有可能出现远程开发碰到网络环境的问题，特别是如果我们的流水线或者内部的调测环境是基于4A的堡垒机去接入和部署的情况下，这时候你要提交代码，在测试环境出现问题的话怎么调测，本地的IDE如何跨越4A的代理去做调测？其实这是很困难的清。

6.知识产权，这也是在外包的情况下会有的情况，就是很多外包厂家担心我把我的产品代码提交到你的仓库了，他会担心知识产权泄露的情况，或者跟他竞争对手的一些问题。

7.平台能力。这也是因为流水线的平台一开始平台服务化的能力不是很够，所以难以适配不同项目的分支模型，包括整个部署的需求。

8.培训推广、运营推广人力存在不足。

所以这是我们当时自己在回顾反思的时候，可能会碰到的规模化推广的困难。而这些东西到底怎么做？碰到了这些问题，企业在内部肯定还是要做从1到N的推广，我们到底怎么破这个局或者说怎么样往下走？首当其冲的一个问题，因为我当时在公司内部也承担了敏捷或者DevOps推广的牵头人或者推动人的角色，我当时一直在思考一个问题：我到底是拔剑四顾心茫然，我砍谁？我到底是选择某个模块或者业务、产品，来作为接下来我做推广的重点对象？其实这是我当时重点考虑的一个问题。

三、回归初心思考

我想跟大家分享一个观点？敏捷不仅仅是DevOps。今天谈的话题，我觉得在阿里这里谈特别有意思。大家都知道现在另外一个圈子里面也在谈敏捷，其实我不仅仅混DevOps的圈子，我也在混架构师的圈子。在架构师的圈子里面，很多人也知道最近这一段时间最热的词叫做什么？中台。大家在谈中台的时候，其实在谈中台业务价值的时候，其实瞄准的也是敏捷。这个概念也是被人玩坏的，但其实是一个好的概念，最早是阿里2015年提中台战略，后面大家都跟进了这件事情。我认为这个概念本身没有问题，只不过被各种炒作，最后被玩坏了。从最近一段时间来看，大家越来越达成了一个共识：中台的核心价值和目的是实现能力的复用，它的核心价值是要实现组织级的敏捷，就是你不要重复造轮子，你真正的业务的高智商的开发人员就重点做业务相关的快速变化的前台应用，而中台的能力能够尽量复用。

所以我认为敏捷里面有三个要素，而中台是一个比较重要的因素，其实就是在做正确的事情。我刚刚也听方老师分享了这个话题。我认为中台就保证了敏捷转型是在做正确的事情，就是不要做重复的工作，其实这也是为了敏捷。

另外一点，我的理解才是DevOps。DevOps更多是要把事情做对。一旦我通过架构的设计，哪些是要分层次做的，哪些是要放在中台团队赋用做的，哪些是作为上层业务做的，这些分清楚之后要通过DevOps方法和交付的方式，能够把中台的能力或者上层前台的业务能力做对。什么叫做对？我的理解就是又快又好，本身包含不仅仅是快，也包含了质量，其实就是质量那一块包括DevOps提到的测试自动化甚至安全，我认为都是做对的一种体现。

还有一个概念是大家认可的：容器，包括基础设施容器化，我的理解是能够让它更廉价的、更快捷地开展整个交付的过程，所以这是我们回到初心之后，就是我作为企业架构师，我当时在想我们要提高整个组织级的敏捷交付的能力，我不仅仅要考虑DevOps的问题，我还要考虑整个组织级架构的转型，所以中台的建设对我而言也是很重要的一件事情。

这是我们自己企业内部的企业架构的设计，其实就是中台架构的设计。

这些业务的名词大家不一定理解，但是这个形式是大家肯定似曾相似的，也是跟阿里学的，能力的中心化、双中台架构、大中台小前台的层次，中间有微服务和能力开放的平台来实现管控及统一的对外开放，包括我们有DevOps的平台在边上做一个端到端的支持。当时我在想我们能否把这两件事情结合在一起，因为我要拔剑四顾心茫然砍谁，我能不能把这两件事情结合在一起，一方面把DevOps的规模化推广和中台的转型、落地结合在一起，所以我当时就在想我接下来会尝试从业务中台里面的各个能力中心找一些突破点，我当时就在想接下来我们整个DevOps规模化推广，我会从这个地方入手。因为这个地方是一个目标蓝图的设计，真正的其实并没有完成能力的中心化和全部的微服务化改造，其实只是一个蓝图。在每一个中心的背后都有一堆小应用或者系统，可能会存在重复建设的问题，可能会存在层次不清楚或者是没有解耦的事情。

所以我当时的想法，我就想能否在这些能力中心里面来挑一些比较容易切入的微服务来开展规模化的推广工作。因为这样子，对整个团队而言是比较容易起步的。因为很多十年以上的项目，你让它进行整体的转型或者全部推倒重来做微服务的改造，这种风险还是太高了，所以当时采用微服务的绞杀者模式，就是挑选一些模块开展微服务的转型。

这是我们业务上的服务，大家不一定了解，只是给大家示意一下。我们当时在每一个中心里面都挑了个别的模块，就是消费者应用价值比较高的模块来开展微服务来进行改造。

这是另外一个中心，这是在采集指令中心。

这是另外一个用户画像、网元画像，这个是没问题的。

这是公共技术服务，包括账号中心服务和单点登录服务，其实并不是所有的系统都统一了，这里还是有重新去重构的必要。

四、重启转型起步

所以回归初心的思考，我当时就想把这两件事情结合在一起，就是把整个DevOps在企业组织及内部进行规模化推广，跟整个中台转型两件事情结合在一起，我当时在内部提了一个口号，我希望能够用DevOps的模式来推动业务中台的转型，就是一件事情能够实现这两个目标，慢慢推动整个组织的转型、敏捷的转型，因为敏捷不仅仅是DevOps，组织级而言，它跟你的架构关系很大，不要重复造轮子。

重启上，我们到底做了哪些工作？其实很琐碎，这是有点像我自己的个人工作总结。

1.重新组建7+-2人的转型小团队。刚才也说我们很多的项目其实是一个很大的团队去做的，如果你要推动这么大的团队希望去做转型，其实难度是比较高的。当时我也是去了很多项目外包的合作伙伴的工作，我作为一个甲方直接去到乙方的公司里面，跟他的领导、管理层做这样的沟通，说服合作伙伴管理层能够支持，一起来开展这样的转型工作。这种形式在每一个项目里面，在原有的团队里面抽调了一些精干的愿意拥抱改变的跨职能的团队，形成小而精的团队来启动整个转型的工作。这样的话，能够保证我们不对现有业务开发造成比较大的影响，能够从小入手，慢慢推动它的渐变的过程，这是我当时的想法。在这个团队里面虽然比较精干，但基本上包含了开发、测试以及做产品的同事。

2.工具赋能和管理要求是否要一步到位。我们号称过了三级认证，也有不少的平台支撑，工具赋能和管理要求是否要一步到位，我是否要一下子把所有推广的项目或者团队全部拉齐到平台能够具备的最高的水平上？我当时潜意识的决定不能太过冒进，我觉得需要做一些功课。

所以我当时在想转型的团队底子到底有多差？他的gap，就是现状跟我们三级的要求的工程实践和管理实践的要求到底有多大？

第二，是不是需要一步到位和标杆系统对齐？

第三，如何让转型项目团队小步快跑，看到价值，增强信心，持续改进，这个特别重要。我们也看到了很多企业很多时候做一些改进，经过了大半年的时间，发现还没有实现从代码到部署的过程，很多时候把所有的精力耗在前面补单测，就是补API的测试或者补扫描了，大家就会很困惑于我做这件事情，我连基本的端到端的部署过程都没有来得及打通和实现。所以我觉得整个DevOps的转型推广过程也要遵循MVP或者小步快跑的思路。

所以我们在转型团队里面组织了一次在线的摸查调研，调研发现情况不乐观，底子非常差。我们发现红色标记的这些，比如说Scrum，人家只是初步接触过，在百度上搜索过而已，还有很多没有听说过。包括kanban，我们很多人在推kanban，也是一样的，这就发现很多时候，我们整个开发团队的水平也是参差不齐的，特别是当你管理很多外包队伍的时候就会发现有这样的问题。

包括容器、制品管理，当然Maven肯定是没问题，只要JAVA都会用到。

还包括代码扫描和持续集成的实践、流水线，可能对大家而言都是新鲜的东西。

包括接口测试，因为我们当时流水线集成的是Postman和Newman开源的框架，很多人也是第一次听说，甚至界面功能测试的基础比较薄弱。

我刚才听到有同学问数据库变更的事情，我们当时也考虑过有一些比较好的工具能实现数据库变更的管理？比如说像Flyway、Liquibase，其实能够比较好地实现自动化的数据变更和晋级。

当然，去哪儿开源了一个数据库变更监控工具，能够实现对Mysql变更的实时监控，其实这些都是比较好的工具和手段，而当时几乎没有人听说过。要去强推，可见你的曲线该有多么陡峭。

所以我当时做了一个决定，我接下来要组织培训或者这一次辅导的这一批的项目、这一批小伙伴，其实我给大家制定了最基础的能力基线，因为我根据前面的调查，我发现很多东西如果是一下子在很短时间内，你要让他学太多的东西，他是接受不了的，或者他学不好。

所以我一开始制定了一个比较基础的基线，当然如果有一些基础比较好的团队，你可以先行实现更多要求，比如说Scrum、kanban甚至静态代码扫描，其实我都没有做要求，当然这是不对的，这不符合评估的要求。当然我没有压力，因为我觉得在组织内部去做改进还是要有一个持续的过程。所以我一开始也说了，其实这不一定是特别完美的思路，大家批判地看就好了。我当时就想一开始要尽快让大家尝试那种快感，能够把原来在研发自己打包，把Jar包传给QQ、传给运维部署的情况，要让他体验从流水线提交代码即部署的快感，一定要让他感受到快速部署。一旦有这样的快感，你后面说服他做别的持续的改进，他就会有信心或者更有动力一些，这是我当时比较朴素的一些想法。所以当时很多的要求，我都把它屏蔽掉的，包括数据库的变更，甚至包括很多敏捷的套路，其实都没有过多做强要求。

3.思维意识培训、工程技能培训。我们当时请了老师给我们做深度的培训，包括开展凤凰沙盘的培训，还有一些深度的体系化DevOps的培训，但这些更多是思维、意识上的培训。接下来我们每个星期会组织半天到一天的训练营集训，主要是针对这次转型相关的合作伙伴的研发骨干开展工程效能的技能培训，就是刚才谈到的这些工具链上的工具，你要通过实操的培训，基本上要学会怎么使用。

4.组建专业支撑贴身服务。我们前面在反思的时候也发现一旦你接入的规模变大了，如果整个持续集成或者整个工具平台团队的人力或者精力跟不上，也会影响最终的效果。所以我们当时成立了专业的敏捷交付的支撑团队，对各个项目和团队提供贴身的1：1的帮扶和支持，尽快让他们接进来，真正实现提交代码即部署的快感，体验这样的快感。

5.工具平台的改进。接下来我们对DevOps流水线做了V3.0升级，做的比较大的点是什么？一是我们终于花钱买了JIRA，其实我们原来用的是开源的redmine，但很多特性不是很足，包括跟其他工具链的集成也不是很友好或者不是很好，所以我们还是买了JIRA，这个JIRA可以比较好地实现跟Jenkins或者跟Git/Gitlab之间双向的关联和集成。

再一块，我们对部署环境做了升级，就是加了一个A/B平面，原来大家会担心我的核心交易、核心系统放在你的容器上到底行不行？或者说你的容灾能力行不行？所以我们后来在环境层面做了A/B平面，所有A/B平面的部署也都是通过流水线全部驱动的，这样的话一个包的话，一个部署的流水线，其实我可以同时部署到A平面、B平面，通过全局负载均衡能够实现流量动态的双活，这样就能增强大家把自己的核心业务部署到容器云上的信心，在一定程度上能推动大家的转型。再一个是我们加强了整个工具链支持传统的虚机部署的通道，我刚才也说最开始只是支持容器化，后来发现不太行，包括刚才老师的介绍也是一样的，我们跟华为、中兴合作的时候，发现很多大厂很多时候还是虚机部署的，所以我们也把Jenkins驱动去部署虚拟机的通道，也把它补齐了。这样子，我们基本上能够通过这一套统一的流水线，来实现多种形态的部署、多环境的一次性的部署。

二是做了远程开发环境的改造。大家一开始也在抱怨我在远程必须要通过4A，太不友好了，很多测试没有办法做调测。所以我们后来申请了VPN的能力，就是把我们的工具连放在VPN后面，通过VPN的隧道，大家就可以通过远程的方式，在它的IDE里面能够连到我们在开发测试的环境下，这样就比较方便他做在线的联调测试，对开发人员比较友好，所以大家的接受程度慢慢提高了。

三是云端调测工具。因为后面是远程离岸交付的，你把它部署上来之后怎么调测？原来没有这些手段，后来我们在研发和测试环境里面部署了，采用容器的方式提供了一系列的调测工具，包括基于ssh的自服务的、命令行的，还有一些图形化的，就是vnc的，然后在图形化的vnc容器里面又预置了自动化测试的工具，这样就便于测试人员能够登录里面来做自动化测试脚本的调测。自动化测试的脚本一开始不是一蹴而就的，它也需要一个比较长的调测和开发的过程，也是需要不断调试，所以都需要这样的环境。可能大家没这样的感觉，你们很多开发都是在一个受控的环境下做，但对我们而言是比较痛的点，很多时候影响整个工具的规模化推广，这些问题都是一个阻碍。

四是调整了分支管理策略。最早的分支比较简单，最早就两个分支，就是Develop和Master分支，我们后来又增加了几个分支。增加了分支之后的分工是这样子的，因为主要是基于微服务的架构去开发，做了微服务的框架的拆分之后，每一个微服务上的同时开发的人不是很多了，所以这种情况下我们基于主干做开发，然后在主干上做开发，部署到开发自测的环境下做这件事情。当一旦开发觉得OK了，你需要提测的时候，我们会把它弄到Master的分支上，在Master分支上让QA做测试，在这个上面做跟其他系统的连调。这是最终的release分支，在releas分支上做最后的发布。后面的hotfix分支就不讲了。

这一块，我想跟大家分享的点是什么？这一块我当时也有体会的。刚才我们也谈到了怎么样能够让团队之间协作起来，因为我们最早请景韵老师和萧帮主DevOps导入式培训的时候，我印象很深的一个词，当时萧帮主跟我们讲，就是说如果DevOps只提一个词，你就用一个词形容DevOps的概念，当时就说你只需要记住三个字：单件流。我现在仔细琢磨和品味，我觉得有道理的，其实很多时候就是要避免不同团队和组织之间批量交付和移交的过程，所以要尽量避免这样的情况。我们当时采用什么方式？我们希望你开发出来之后立马移交给测试，不要等你累计很多的代码量或者累计很多功能的时候再做批量的移交，这样肯定敏捷不起来，肯定是假敏捷。所以我当时给很多企业做评估和辅导的时候，我特别爱问一个问题：开发同学，从你接到任务之后，你第一次提交给测试会在什么时间点，我一般会看你的移交记录，或者你有多频繁提交测试，其实很多时候才是真正反映敏捷的程度。如果你只是一个月做一次版本发布，在你一个月第三周的最后一段时间或者是最后几天才把你的代码移交给测试做一两周的测试，才去移交，这样就很难敏捷起来。所以我们当时就想一定要把这两个环境分开，就是让开发同学在这个分支和环境上做不断的敏捷的开发。为了让测试有一个比较稳定的环境，所以我让QA同学、测试同学在Master分支对应的环境下做测试，这样就能实现开发、测试有一个相对稳定的环境做自己测试代码、测试脚本的编写，包括他的一些手工的UI的测试，能够有一个相对稳定的环境，所以当时是这样的想法，所以当时做了这样的调整。还有一个问题我也比较喜欢问，比如你在测试过程中发现BUG，怎么搞？因为我们是比较短的交付周期，就是两周一个迭代，所以我比较少，尽量避免在一个比较短的周期内还多版本的概念，尽量一个周期做一个版本，就是把迭代计划会的时候把任务分细一点，就是在迭代周期里面做一个版本，如果有BUG就在DEV分支上做快速修改和发布，不断提交我修复后的代码，让测试做回归。

五是分支发布策略。发布的策略也是对应的，我的DEV分支对应的流水线除了做持续集成，其实它是可选的，它可以做部署，也可以不部署，只做集成的验证，后面提交到Master分支上做，再做整个自动化测试和手动验证。release是要做全量的验证和回归，基于release分布做正式的发布。

六是开源流水线如何增强服务化编排能力。如果整个DevOps平台特别是整个核心的流水线的部分是你自研的平台或者你基于Jenkins做的封装，其实很多时候比较容易解决评估里面4级的标准，就是服务化和编排能力的要求。其实相当于一个流程引擎，你可以自由度比较高的去做。

如果是基于开源的，比如说基于Jenkins原生的去写Jenkinsfile的方式，怎么样能够尽最大可能把这种持续构建和集成的能力还给各个项目团队，让他能够以比较自由的方式做这件事情，自己去控制这件事情？我们都知道不是每个都能够写Jenkins方案，所以我们后来做了一件事情，实际上我们是通过config-info文件，在这个文件里面让项目组自己去控制你每次提交时候你希望的流水线要挂载的能力，或者要执行的步骤。比如你可能是一个微服务架构，为了实现代码更好的集成或者简化代码管理，一开始你所有的模块没有拆库，你可能是放在一个仓库里面不同的工程里面去做的。

可以通过这样的控制文件，你可以选择每一次发布的模块，不是说你每一次做提交构建的时候，你把所有的模块都构建一次，也没有必要，你可以通过这种方式做模块的可选。另外流水线加载的能力，也可以通过开关的方式去做。每一次流水线在读取Jenkins方案之后，它第一时间会读取yaml控制文件，把里面的参数提取出来，注入到后面Jenkins方案执行的判断逻辑里面，能够控制整个Jenkins方案到底要不要执行这样的环境或者这样的能力。

所以一开始为了降低大家学习的曲线，所以我们一开始把代码扫描能力甚至容器扫描能力关掉了，当然我们加了一些部署到平面的能力，通过这种方式实现一定程度上的开关控制。另外每一个分支和对应的流水线都可以控制，因为你把这个文件提交到不同的分支上以后，你在相应的分支上修改分支上的文件，这样的话你的分支上手工执行构建集成流水线的时候，它就会同样地读取我这个分支所对应的文件的信息。通过这种方式，能够最大限度地实现增强编排和自服务的能力。这是基于开源的组件在做的时候的一些特点，如果大家都是自研的话，其实这个问题也就不是问题了，因为你都是通过上层的，这些都可以非常容易地做到。

经过前面这些各种推拉拽，又是给他做思想动员，又是威逼利诱，又是各种培训，又是各种减负以后，最后发现这是所谓核心的关键指标。前面的是我们这一次的几个项目，里面包含了很多服务。一开始的效能其实还是比较差的，部署的频率包括需求上线时间都是很长的。后来经过这样的调整之后，至少这些新的模块和服务的交付效能有一个比较大的提升和改进。

所以最后也跟大家分享一下作为我个人的一个年度的工作总结，今天是12月20日了。我自己大半年来在企业内部做转型推动的感受：

第一，DevOps整个组织及规模化的推广一定要耐心培育，实际上就是要培育生态，这个生态既包含业务和IT我们的管理层和执行层，对我们而言也包含了甲方同学和外包团队之间，而且还不止一个外包，其实这都是一个生态。就是要让整个生态的人都能意识到这个东西的重要性，其实是需要有一个耐心导入和培育的过程，其实这个还是很重要的，我们觉得很多时候需要有一些顺势、借势、造势、助势，包括我们请老师给我们做培训也是有意为之，就希望外来的和尚好念经，能够借外部的力量和大咖的咖位摆着，能够借助外部专家对企业内部培训和说服，这也是借势和造势的一部分。

第二，要接受不完美，持续改进，特别是持续改进，当然这不适合过级的项目，过级不能这么搞，过级是有时间周期的。我的意思是说如果我们没有这样的OKR或者KPI，在企业内部真的推动、规模化推广的话，可能要接受不完美，做持续改进。因为我们一开始拿出来做各级评估的一定是内部明星项目，底子比较好。但是规模化推广了，其他的项目的兄弟可能是学渣，这时候需要用不那么完美的方案解决当前的痛点，而且从1到N需要控制节奏，我们一开始走弯路、踩坑了，老板一发热批量上，最小发现真正活跃的没有几个，大部分是尝试性的接入，可能要重启。再一个是平台不成熟的时候，要控制扩大接入规模，这一点跟其他的因素关联，关系非常紧密。

最后一点感悟是系统思维，是整个DevOps的实践。这是我自己做的抽象，我从标准框架里面读出来6个P，确实是需要从这几个维度做推进，然后进行紧密配合。很多时候工具链的搭建是最显性化，最容易给老板showcase，也最容易入手，但不是全部。真正要在企业内部落地整个DevOps的实践，其实上面还有很多的东西做工作，很多工作需要持续推进。

非常感谢借这个机会能够做一个个人的年度工作总结，感谢各位专家、各位老师的聆听，谢谢！