Vivo：基于 Jenkins 的持续交付实践与演进

Posted 2021-04-07 DevOps时代

作者介绍：

分享结构：

我分享的结构大概是这样的，首先会给大家简单介绍一下作为手机厂商，我们需要交付的软件类型，有哪些需求，挑战是什么样的。

因为大家对大厂非常熟悉，阿里系的产品可能天天在用，几乎没有人不用的微信目前有8亿多的月活。那么手机厂商，除了用户可见的APP之外，背后到底有哪些业务，做什么类型的软件，我会给大家做一个介绍。

第二个是我们从0开始的尝试，互联网业务对我们来说是近几年新起步的，最初也没有Jenkins，开始使用它遇到了什么样的问题？

第三个是业务持续增长的挑战，开始是三千万用户，现在是一亿多。最后是我们服务亿级用户的庞大业务交付这些软件的时候有什么新的挑战，包括未来的方向以及我们在社区参与方面的工作。

1 手机厂商的软件交付需求和挑战

第一个，手机软件厂商所面临的不太像一些同行所分享的那样，可能是专门针对一个APP的客户端、服务器，最多是这两个加起来。

目前软件行业的操作系统种类不是非常多，要么是微软系，要么是虚拟机的，包括现在做的Container，手机厂商的操作系统更新可能是最频繁的。

大家现在看到的iPhone X并不是上个月或者几个月前决定做这个产品，一年前几乎已经把这个产品原型做好了。我拿到什么样的元器件，当时元器件技术到了什么程度，我的软件需要做什么驱动适配它，一年前就定好的，生命周期非常长，另外还有底层的操作系统。

我们服务器技术是Java为主的技术栈。这些不同的东西有个非常共同的特点，就是对品质要求是一样严苛的，包括我们厂商互联网产品跟手机是一样的品质要求。

首先看一下我们大概的几类软件，第一个是安卓系统，我们叫做FuntouchOS，业内有的是叫UI，有的是叫OS，看上去是一个字眼的差异，其实差异非常大。首先是UI不关心底层有多少芯片，只是软件层面的封装，压力相对比较小。

如果说我的拍照功能是有一个专用的DSP，跟高通芯片集成的，这个代码谁来写？还有我们做的一个音乐功能有专用的HiFi芯片，要接入标准的类Linux操作系统，内核是需要自己编译的，这是一类挑战。

第二类就是右边的，安卓上有一堆预装APP，谷歌或者ios的系统，买到手机以后上面也都有了一堆APP。有的是用户可见的有的是不可见的，有的是有图标有的是没有图标的。最中间是vivo互联网业务，用户可见比如浏览器产品、应用商店、游戏中心等，还有的是用户不一定可见的。

我们知道互联网商业化的本质就是广告，要么用户直接付费，要么是广告主付费。到了目前的阶段像搜索、推荐、广告、榜单、安全、风控，这些都是必须要做的；这些东西对用户可能是不可见的，用户不一定知道买个vivo手机后面还有一个风控团队。

看看操作系统相关的软件在构建方面的需求，包括简单的数据。整个安卓操作系统是每天需要编译一遍的，因为我们有非常多的手机项目，所以加起来就要编译很多次了。

大家今天看到iphone还有vivo机型，其实我们是做了很多款的，最后成功了这几款，所以做手机研发的同学加班比较严重，一个人的BUG不解影响了整个操作系统的编译，大家的工作就没法完成。

单次编译平均2.5小时，包含了整个全流程，从MP到pack。操作系统编译使用一个单独的Jenkins集群，上面每个节点编译不一样的东西，配置也是不一样的，一级的job是500多个，因为模块众多，所以不能把所有的模块放在一起一次性编译通过，这个是非常难的，大家都了解C/C++编译的一些挑战，有的编译选项超长。

之前有同行说我的配置管理工具或者某个工具可以做个限制，编译选项不要超长，超长了一定风险很大。所以会把这些模块拆分开，大概700多个，先按模块编译，再按大模块类别编译，最后汇总到一起做整体编译。

中间使用到其他的内容，比如说多个job的串并联，这么多job和模块是需要专人维护的，所以非常严重的依赖于参数化构建、Gerrit交互，这么庞大的代码还是比较难做的；还有超多人超多分支超多标签的协作编程。

对互联网来说我们服务器系统比较复杂，大概几十个人在同一个仓库里写代码。如果有超大的几百人写代码，一般情况下接近操纵系统的级别了，这个挑战是不一样的。他们为了做这个事情也是有专职的配置管理小组的。

安卓APPS是跟前面差不多的，也采用每日构建和事件驱动构建，大概是30多个项目，构建作业数是200多个；但有不同的纬度，比如一个应用商店，机型、模块、版本甚至于渠道的不同，就构建出不同的内容，有的可以通过参数化构建实现，有的则必须使用不同job构建。

vivo移动互联网大概是1.6亿用户，这里的“用户”定义是最近18个月在手机上有用户行为的数据，比如说之前使用vivo现在换成其他品牌了，那就不算我们的用户了。之前是iPhone现在是换成vivo了就算我们的新增用户。

单品的日活，因为手机厂商的特点，用户的日活、月活都比较高；原因是一部手机不管给谁用，一定是时时刻刻在用的，没有人把手机买回家放在箱子里，掉在大街上以后捡起来的人都会继续用，这就是厂商互联网的特点，日活、月活特别高。

日总PV是300多亿的水平，手机上的产品每天跟互联网服务器端打交道的，总的统计是这个量级；产品线20多个，100多个项目，500多的开发人员。

前端的构建我们也剥离开了，因为前端追求Node.js，也使用服务器开发模式，经常要求安装使用不同Node.js的插件，所以干脆剥离出来了，会做前端自己的代码检查。

刚开始介绍了一下大概有哪些类型的软件需要交付给我们的用户，需求是什么样子的，最后看两方面的挑战。相对来说不只是我们公司比较注重品质，而是整个手机行业对品质相当重视；一台手机是一个移动数字终端，用户买来是消费数字化内容的，如果这上面有问题，会严重影响他的使用体验。

我们之前的目标大家觉得做一台好手机就可以了，实际上远远不够，而是不但要有一台好手机，一定还要有一个极致的体验，用户才愿意买单，包括了你的硬件、系统、应用、服务，和整体的用户体验。

这就是为什么很多人坚持用苹果的原因，很多人说苹果的钱可以买好几台某品牌的手机，为什么大家还是愿意买iPhone呢？原因就在于硬件、系统、应用这些东西大家差异化非常大。用户花钱不只是买它硬件设备，还需要极致的体验。这是第一个方面的挑战。

第二个方面，犯错的成本不一样。对于互联网用户，举一个例子，交友软件的“查看附近的人”功能，我打开找一找想聊天的人，这个体验如果很差，想找附近人的时候找不到，最严重的后果是什么？我一生气卸载了，不用了，我换另外一个软件，这就是最严重的后果。

手机厂商不一样，我在你应用商店下载了一个交友软件，上面有乱七八糟的广告或者我的钱被骗走了，用户不会直接找这个APP开发商，他会找卖手机的人，觉得你这个手机有问题啊，这就是我们的犯错成本。

更严重的成本就是用户会拿到售后退机，特别是对于线下渠道比例要比线上渠道更高的厂商来说，后果是不可承担的。某个地区运营商网络异常导致用户不能聊天了，可能就一堆人拿到门店退手机这是很可怕的。

2 从0开始尝试

刚才介绍了需求和挑战，看看我们是怎么从0开始应对的。这里给了一个关键词，就是ChatOps，调侃下开发运维的关系；上线的时候主要是开发跟运维打交道，两边关系很熟可能分分钟就好了，不太熟就得排队。

从这里开始后面主要是讲vivo互联网的部分，可能更偏服务器，不太会涉及手机软件。下面主要讨论没有使用Jenkins时，是不是就没法交付软件了？刚开始使用Jenkins是怎么用的，以及带来什么直接的好处。

非持续构建，大家都讲持续构建，我们之前其实是非持续构建，怎么构建的呢？这是几年前的事情了，我们使用java技术栈，还使用ant，现在看起来是很老土的了，当年确实很好用，而且能满足需求。

这些工作怎么串联的呢？shell脚本和python脚本串联起来就可以了，而且仅限于开发、测试环境，如果上线还得找运维，线上权限一般都是对开发开放，除非有完善的云平台可以做这个事情。所以刚开始是一个简单的非持续构建，照样可以上线发布，能满足当时的需求。

我们看一下没有持续构建的流水线，其实算不上一个流水线；我们经常讲的编码、构建、测试、打包、发布、配置、监控，打叉的这些环节都是没有的。

提交到SVN仅打TAG备份，本地IDE里编译打包，上传测试服务器，测试通过就改上传生产服务器，找运维人工发布，验证没有问题，就完成了，最后是靠用户监控的。

有人投诉说这个软件有问题，我们就去处理这个问题，我也不知道发出去有没有问题。相信很多团队刚开始一定这么做，五年前我们就是二三十个人做互联网的产品，是经历了这个过程的。

接下来了解一下，看我们自己是怎么理解CI/CD这个事情的。用最简单的方法刚开始能满足当时的需求，随着业务的发展挑战越来越大；比如说我一直持续的编译，代码一有变更就编译，甚至无变更提交每小时都编译一次，是不是持续编译就是持续集成了呢？编译和集成对于小团队来说看起来貌似是一回事。

第二个是不是持续集成加持续部署就等于持续交付了，我一直在集成，而且一旦完成测试环节可以直接部署上去了。这样我就持续交付了是不是？

第三个是做这个事情必须用Jenkins吗？不一定，Jenkins非常优秀，但确实还有其他的解决方案存在，主要看我们的需求。

看一下我们对这几个持续交付问题的理解，我从网上也看到类似观点，说明大家的理解都是比较相似的。

第一个是从代码到成品库的过程，不管叫什么名字，你在持续编译还是持续集成，到成品库的内容是经过测试还是没有经过测试的，只是编译通过了，还是自动化测试，甚至有的公司是人工验证、自由测试也通过了，这个每个组织是不一样的，但过程非常重要，就是从代码到成品库。

第二个是从成品库到可运行的服务，我要启动起来真正跑起来，这是第二个重要的过程。

第三个，从开发、测试到预发布、发布，这个环境有本质差异的。开发测试随便折腾，最多测试天天来找你，测试妹子喜欢天天来找开发；但发布环境这个门槛就很高了，我们刚开始理解可能不是很全面，这三个阶段一定要有工具或者方法覆盖到。

这个是业界比较知名的DevOps教练James bowman发布的CD工具全景图，覆盖的内容可能比之前大家看到的都更全一些，我们能看到其中Jenkins的位置。可以发现并不是说我用了Jenkins就CI或者CD了，流水线里面有这么多工具可以选。

我们现在开始使用Jenkins，在此之前什么都没有。第一次使用，我觉得体验比较好的就是Jenkins的Hello World非常简单。

右边是我在网上看到的关于Jenkins最多的几个问题，第一个是安装与配置，第二个是怎么发音，第三有什么用，以及上次持续时间什么意思、日志在什么地方等。

大家看到网上有些资料都是英文版的，所以我们现在也在组织翻译，把优秀的文档翻译成中文版的，让新手更容易上手。

在座的对Jenkins的Hello World都非常熟悉，知道去哪一个网站下哪个东西，简单的命令就可以运行起来；但对于新手比如说启动不能工作，日志在哪里？默认工作目录在哪里—-当前用户“.Jenkins”目录下。参考右下角的图对新手来说这些东西都还是有门槛和挑战的。

我们现在使用Jenkins有五大集群，要用起来并不是掌握Hello World就可以。手机这边的FuntouchOS大概有50个节点在维护，而且我看到他们的管理界面，视图是按人名字划分的，因为他们模块太多了，不能按模块化，按模块化这么多模块进去出了问题不知道找谁，而视图按人名字划分，谁的任务出问题了就是这个人负责。

安卓的APP大概是5个节点，重点是Gradle编译，而且支持多渠道的打包，网上很多开源多渠道打包工具，都集成进来了。

互联网大概也是五个节点，一部分使用Pipeline做串联。前端的三个节点，主要用于node.js。还有一个实验室，专门研究Jenkins新功能对我们的帮助；比如说使用“Blue Ocean”，开发很有趣的插件。

监控面板，都是很成熟的平台我们自己做了封装。对于刚刚开始使用Jenkins来说，根本没有能力开发，但也希望有监控，monitor-all这个大家都知道的插件，基本可以知道哪些项目是有问题的。

对于编译的监控，第一个图国产的一个工具，这个图不是很清晰，看不到面孔；主要是做了这样的一个监控看板。

第二个图是有人开发了firefox插件，一看就是程序员的用户体验，根本不是给普通人使用的，功能是有的，当你沉浸在浏览器中的时候，它可以告诉你所关注任务当前的执行情况。Chrome也有插件，看起来比较好一点。

第四个更有趣，国外有一哥们把Jenkins编译结果跟飞利浦台灯连接起来；编译通过了就亮绿灯，编译没有通过就亮度红灯，有告警或者最近编译质量不稳定，就亮一个黄灯。

这些有趣的工作完全可以帮助我们提升整个CI/CD的用户体验。刚开始没有使用，一旦使用起来有简单的体验，最直接的效果就是速度和效率的提升，问题反馈更进一步前置了；

刚开始没有这些脚本串联，一直到最后部署到测试环境，才发现有问题；现在编译阶段跑了简单的单元测试用例之后，这些问题前置了，能更早的发现。

还有开发的体验提升，会更加聚焦于分析设计和编码实现，不然所有开发人员都变成持续集成专家才能工作。

测试的体验也会提升，更加聚焦于测试工作，并且可以收集一些过程指标，更合理的量化开发交付的质量，测试非常反感。

开发人员说代码自测过了，编译也通过了，给我之后一大堆非常简单的BUG，不该犯的错都犯了，这个阶段看起来跟运维没什么事，还是保持ChatOps的阶段。

再看第一个版本流水线上使用的工作，这些工具非常简单，非常有效。跟你没有使用Jenkins之前相比确实解决了一些问题，Jenkins帮你跑了任务把结果呈现给大家，测试执行单里面可以把链接甚至测试报告图放进去，这是带来的好处。构建的工具，Gradle、maven还有依赖的nexus。

还有测试，我们的性能测试一直是要求比较高，对一个新业务，哪怕没什么用户，上线单个接口单节点的QPS一定得到2000，这是我们能做出好的用户体验非常重要的保障。

在我有能力做到2000的时候刚开始就做到2000而不是说没关系我又没有用户，先做200，后面再优化。还有打包、发布、配置、监控，刚开始看到的发布，没有虚拟机，也没有云主机、物理主机，发布的时候是运维值守的。配置刚开始只是做简单的参数化，监控，除了monitor是自己实现的。

3 持续增长的挑战

从刚开始什么都没有，到Jenkins开始引入，做持续的构建和持续的交付。刚上路，到第三个阶段，业务在持续增长，刚刚那一套东西面临的问题会越来越多，无法应对了，我们后面会简单介绍一下，遇到了哪些问题，大概的解法是怎样的。

第一个就是我使用了Jenkins就CI/CD了？这个问题前面大图就回答了一半了，接下来回答另一半。第二个是项目变得越来越多，第三个是人变得越来越多。

第一个，Jenkins使用起来之后，那么多集群，不但增加了并发构建数，还有不同的技术栈，刚开始发现一个JDK因为历史遗留问题，从6版本一直到7，还有开发测试、实验环境我要使用8、9，这些挑战刚开始觉得没什么差别。

Jenkins本身支持多个版本的配置，配进去就可以了。后来发现当一个项目里面有不同版本出现的时候，他发布的时候使用同一个用户名，他默认java环境变量是唯一的，你用8就改成java8，7就改成java7后来发现越来越多。还有拆分出来的Jenkins集群，这个需要人维护。

我们再看一下master-slave，一开始没有这个东西的时候，一个节点可能能满足当时的需求，后来不够了，环境有差异。

通过master-slave的方式加，后来因为手机的操作系统，编译要求很高，大家看到这个编译服务器给他编了ID，最高的配置有一百多个内存，用这种服务器做编译，一开始感觉很浪费，我们搞云计算是为了把资源使用率提升了，怎么这么高配置跑一个编译，最后发现一次编译耗的CPU是20几个，2000%多的消耗，所以就能理解这是为什么。

环境的隔离，环境隔离能减少项目配置冲突。还有访问控制，开发最烦的是提供一个工具，给我一个用户名密码，让我登陆。过两天我忘记了，找谁改密码也找不到，这种开发体验是非常差的。

所以说在这个阶段，Jenkins有专用帐户，这个选项不能选的，我根本记不住你的密码，你要支持CAS和LDAP。

还有权限管理，这个是最头疼的，上午提到几十个人，有人配置这个，包括我们基于角色的配置，说最多就是开发、运维，或者有的人只是看看那匿名用户就可以了。简单的时候都够用，人一旦变多就不够用了。

比如说最简单的，新入职的，离职的。最头疼的是有个人转部门了，他转走了以后参与的项目，依赖的项目权限都要变，都不知道谁去跟进这个信息，包括安全矩阵、项目矩阵，这些不管选用哪一种维护成本都是非常高的。

写了非常多的正则表达式，最后管理员都不知道这个权限是不是你该有的权限。

还有各种各样的凭证，你都配到一个凭证里面去，风控团队过来说你的风险非常大，是不是所有服务器上去一个RM，给你删除了你就悲剧了。

好像有同学发生过这样的问题，这些问题都是使用Jenkins来做你的持续集成过程中遇到的。当你的人员和项目变得越来越多是一定会遇到的。

下一个问题，只在线下做CI/CD，带不到线上，这里面有很多问题，运维是一个短版，软件资产混乱，根本没什么CI/CD，CI之后接不上CD，这个环节非常可以，真正到用户手里，上线部署的时候就会卡住。

这只是线下CD，放不到线上。这个过程中开发说我掌握的很熟练，研发流程做的非常好，最后上线运维成为短版了。

这个跟我们所处的阶段有关，我们刚好赶上云计算非常火热，容器技术非常热门。这时候的策略，我们现在回头看也是唯一的策略，就是拥抱DevOps。开发不需要总说运维是个短版，无法支持我的上线，大家一起想办法，从两个层面解决掉。

我们的paas平台，其实现在已经不叫paas平台了，我们是后来者，直接进入容器时代，我们CMDB包括DevOps发布平台，是跨过了这个大的阶段，这些东西暂不适合往外放，所以我们就关注一下里面使用的工具。

比如说编码阶段，以前不使用的自动扫描，静态检查的工具都用起来了，因为你跟别人扯皮的事情越来越多，他不相信这个BUG很简单，为什么你没有发现，我们有这些数据报告展现给他，这样就合理。

构建过程中之前可能是简单的，Jenkins上都没有写过，现在开始写一些groovy的脚本。还有测试阶段的jmeter，包括使用java可以跟Jenkins很好的做串联。Jenkins自动化测试我们基本上自己开始做了。

打包，我们遇到的问题是内网，我们之前跟办公网络共享的，网络IO竟然成为了问题，大家打包过程中，不管什么东西发布的时候，一股脑的，只要我需要的东西尽可能打到我的包里面，就往测试服务线上发，到某一天信息管理部过来说，你们业务部竟然影响我们的办公网络，我发现这个地方完全是可以优化的。

本次跟上次的包之间，有可能你确实打出个新包，但我不需要全量都发布，所以我们用了一个差分包，做安卓开发的都知道，是谷歌开源的差分包工具，bsdiff找出二进制不同，然后用bspatch打进去。看起来很小的技巧，但可以帮助我们解决当时网络流量的问题。

如果有的同学说，你打出来的包跟你机房之间走公网的，这个地方能更快的帮你加快速度。有的人说我的java是分几种级别的，结果几次网络传输加起来占了10分钟以上。

还有发布，这时候有了虚拟主机、云主机，速度也会快起来。配置我们基于ZK有自己的配置管理，不只是用来满足业务，整个编译过程到配置也可以往里放，Jenkins的配置就会简化。

项目依赖的东西自己可以去配置中心拉了，而不是人工一直往Jenkins堆，Jenkins很强大，但数量多起来，成本会非常高。还有监控，现在我们自己知道服务器运行是什么状态，比如说网络流量异常波动，我们不知道，可能没用户投诉，但我们知道业务一定发生问题了。虽然不知道具体的问题。

4 为服务亿级用户的业务实施持续交付

第四个部分，我们之前经过这样的成长之后，业务量也在往上走，来到了亿级俱乐部。这时候开发、测试、发布和预发布是什么样的需求、有什么样新的挑战，以及我们积累的经验和心得。

最早我们是java技术栈，当时可以搞定，后来服务化的时候，开始考虑SOA，后来觉得太重了，我们在SOA方向基本上走了不到五成，两三成之后就到微服务时代了。

开发层面面临的业务调用，比如说我在预发布环境，A业务发布了新版本之后，我告诉运维，我这个依赖于另外三个业务的什么版本，他认为去管理这个事情已经管不了了，必须要有工具和平台管理。还有一个是跟踪和排查问题的难度会越来越大。部署协调和同步，以及多环境的互动。

为什么写了一个“导数据”？相信大家都遇到过，预发布的时候，测试或者是你的品质部门，包括其他人员会帮助测试预发布环境到底有没有问题，是不是符合我们的预期，这时候很多数据产品一定要有线上的数据产品验证。

你说我预发布环境的时候看到，没有线上数据根本验不了那个功能，特别对互联网产品来说，导数据是最痛苦的事情；预发布运维就帮助你从线上导数据，后来大家想说，能不能把线上所有数据同步一番，这个老板肯定不同意，说你预发布功能这么重要吗？跟我占用同样的资源。

还有测试，因为依赖关系，包括客户端，无处不在的mock，但mock有好处也有坑，一旦集成的时候就很痛苦。性能测试成本也越来越高了，包括流量的拷贝，比如说广告这个产品很特殊，他不知道你这个路径，因为广告需要很多数据的埋点，路径就要真实流量回访来检验我的新版本逻辑是否可以。

流量拷贝应该是网易开源的TCPCOPY。还有海量客户端模拟，弱网络环境模拟，这个测试不是测试部的，是品质部的，这个品质部是对所有的用户体验相关的方方面面负责的。

所以说测试只是他的工作之一，他会从海量客户端模拟，包括弱网络环境都是要做的，我们现有的东西对他们来说是无法支撑的，他说我要模拟这么多客户端，用Jenkins模拟吗？显然模拟不了，必须要用专业工具模拟。还有流量拷贝，Jenkins落地这个东西吗？也落地不了。

不是说Jenkins功能不行，只是说定位不在这里。

我看到7年前有一篇文章，说测试到底要不要会写代码，按我们公司的标准不会写代码的测试一定被淘汰，只能做人工的自由测试，刚刚腾讯分享了，外包就可以了，为什么雇佣一个测试工程师做这个。

7年前就有人讨论这个事情，现在还没有完全的定论。我们的理念是测试工作可以提需求给开发帮你开发工具，本质上这些工作，如果他不会写代码，需求都提不出来，所以测试一定要会写代码，才能所保证面临的挑战能跟我们一起解决掉。

预发布和发布，我们到达这个体量之前，不太清楚为什么做所谓的AB。结果我们发明了新的词“A…Z Test”。我们发现算法能做的越来越多，思路越来越多，不够了，可能20个策略，而且一套算法有多个权重的组合。

一个算法十个不同权重的组合，我要放出去看效果，因为数据产品不能人工测试，你怎么知道好坏呢？流量拷贝永远是过去的东西，算法的本质就是用过去的数据对未来得做一个预测。为了支持这些功能业内是叫多层实验框架，流量第一层进来之后可能分成三组，走三个算法，每一个算法往后走不同算法参数的组合。现在人工智能很火，网上有一个玩笑说人工智能工程师在做什么，有个人工智能工程师列出了每天做的事情，可能两三天建模，半个月调参数。

所以人工智能工程师又有一个名头叫“AI训练师”。所谓训练师就是每天优化调这些参数，调的依据是什么？就是刚开始流量进来分三个算法，每个算法有非常多的参数组合，这样我们才讲了两级，有的业务是有多级，所以叫多层实验框架。要用真实流量放到线上看效果，才能决定选用哪一个算法的哪一组参数组合。这种挑战是我们之前没有遇到的。

最常见的是近年的蓝绿发布、灰度发布、金丝雀发布，这些都是发布的需求，新的挑战。后面我们用的技术docker-K8S、Jenkins、CMDB和发布系统，我们大体的理念是这些第三方都很好，但我们要自成体系的话，可编程性要非常强。

第三个版本的流水线工具。大家看编码阶段，比如说SonarQube的使用，我们觉得开发不应该知道Jenkins的存在，把他的代码提交了，工具帮他搞定这个事情就可以了，不能要求每个开发人员成一个持续集成专家，他的职责是做开发，所以SonarQube这个工具起什么作用呢？把我历史的数据，都帮我记录下来，并且可以在多个版本之间作比较。我只要在这个平台上看我各个版本质量的趋势就能达到管控的目的。

还有构建，我们自己做了Jenkins的查检，Jenkins有非常好的可编程性，比如它的API，它的插件功能，我们这个阶段只使用了插件，扫描插件主要是安全提出来的。同行确实发生过线上使用的包是被人篡改的，其实不一定有什么大的危害性，就是利用客户端流量给自己的广告增加点击。

我们做这个事情的出发点就是这样的，包括测试单元，我们有自己的测试平台了，还有增加了TSung的功能，对互联网来说loadrunner工具是偏重的，有很多测试工具可以选，我们尝试过TSung，它的优势是可编程性不算很强，但配置能力很强大，这是性能测试中可以做的，而且能够模拟大量HTP的连接，甚至支持TCP，不同协议的支持也是它的优势。

所以我们用了这个结果，而且这个结果也支持html的发布。这个地方增加了docker的镜像，上午同学都提到了，一旦走向了容器时代，你的包就开始演化了。发布，这个可以看到，我们除了混合的云主机增加了docker和K8S，有CMDB发布系统。

配置，我们业务更多使用的是配置中心。监控，之前是单一，现在有多个纬度的，提供两级监控，一个是基础设施的监控，一个是业务的监控。还有一些是普罗米修斯本身对容器栈的监控。还有可视化，还有使用了Pipeline的。

经验与心得的分享，我们总结了三点，第一个是CI/CD的理念，你所在的大团队，一定要认同这个理念；如果我是个小团队，十几个人，大家都认为我们不应该做这些东西，我们就把代码写完，上线让用户可以用就行了，那做这个事情是非常难的。

还有DevOps，我们认为是一种文化，既然是文化一定要影响到组织层面，刚才很多朋友提问说，我们没那么多人开发那个平台，这个问题的本质我们理解是文化的问题，也没有影响到老板的层面。老板认为重视一定会搞人给你做这个事情，老板觉得跟我们业务有什么关系，感觉就是你们技术想搞的东西，怎么可能花这个成本让你做这个平台，所以说一定要影响到组织层面。

落地方案一定要快准狠，我们分三个方面：工具、架构、基础设施。工具比如说选了Jenkins作为串联的工具，其他的东西一定要有很好的可编程性。

比如说我有八个工具，都是单独运行的，提供八个用户名密码给别人使用，这个肯定是不友好的，所以可编程性特别强是很重要的。第二个是架构，对我们做java的人来说，面向微服务和Cloud Native。

重点是说我们业务任何时候都可以自由的在私有云和公有云之间迁移。还有一个基础设施，我们最早是没有云计算的，现在从混合云到docker加K8S，软件和基础设施都是可编程的了。

5 未来方向与社区

最后一个部分，基础设施的演进，从最早的物理机到虚拟机、云主机、混合云到现在的容器云。混合云的阶段我们已经度过了，因为有些东西必须放到公有云上，比如说你在东南亚的业务，你说要到印度和印尼建机房，这个挑战还是很大的。

开发技术栈的演进，我们最早是java还有shell语言。第二个是python，现在python成为大数据很重要的语言，既然是大团队在用那我们也可以用，有些业务开始使用python语言，有的也会使用R语言；当然我们CI不支持R，只会支持java和python。

第三个是golang，为什么？主要是因为容器技术，他们开发业务也用golang，而且利用了第三方的C/C++类库，还有groovy脚本语言做解析的。我们跟世界上最好的语言php一点关系都没有，因此很担心这个技术栈的演进

架构的演进，最早是无服务，到经历了SOA、 ESB，到现在的微服务时代，再到service mesh，有人已经喊出了service mesh是下一代微服务的口号。

你的代码在执行在消耗资源就付费，你的代码只是在那里静默没有消耗任何资源就不用付费了，这个理念非常重要，这个方面的演进给我们也带来一些挑战。

大数据和AI的持续交付，这个花2分钟的时间介绍一下。我们算法团队会做很多的实验，有一大堆的模型，但这个东西跟业务对接的时候出现问题了。

业务说这个版本是今年1号开始做的，31号上线，刚开始做的时候不知道我做到什么程度，计算资源也是不可控的，本来说这个模型跑两天半，跑着跑着中间出问题了，这个完全是不可控的。

他们也对持续交付提出了需求，说你有没有东西帮我更合理的调度这些算法的计算任务，而且把大数据的集群使用率进一步的提高；算法优化跟我们刚才讲的所谓AZ发布或者是多层实验框架结合起来，我这个版本一旦上线，多层实验框架一旦上去，上线之后才是算法发力的时候，可以在我上线之后继续优化，只要算法和框架在的，可以继续花时间调这个参数。

这个方面的挑战业内我们了解主流方向就是使用K8S，集合我们选用的谷歌的 tensorflow 这个框架。

目前我们同事在K8S的社区分享了两三次了，我们1.0版本已经上线运行了。这个方面同行很多在实验，如果公司有算法团队的话完全可以考虑这个技术方案。

监控，就不多讲了，基本上我们是使用业内最成熟的主流方案了，没什么特别的，数据从kafka流过来，包括容器监控是普罗米修斯。我们还有很多日志，使用算法会帮你发现是偏离正常值还是跟正常值一样，这个跟后面的AIOps是有一点关联的。

我们期望未来的流水线是这样的，开发只关注自己的事情，其他事情不需要关注，而且编程未来是面向Cloud Native的。

第二个是中间环节自动化、透明化。开发不需要过多关注编译过程、打包过程，我只关注结果，这才是对我们比较理想的流水线。

运维的变动比较大，运维应该运营化，把我们产品持续的运营，对开发来说，开发是他的用户，他们要持续提升开发体验，他要做的只是开发好工具，最后运营起来就可以了。

最后介绍一下我们的社区参与，这是今年6月份我们在深圳发起的中国第一场Jenkins的Area Meetup，后面高效运维社区在北京和上海组织了第二和第三次，今天的中国大会是第一次。

大家有兴趣需要与本地团队交流，可以在自己的城市，通过网站上申请就能自己组织，这就是开源社区的魅力。

第二个社区参与，我们的Jenkins有很多插件，可能用到的我们计划释放出来提供给大家。比如说第一个，jar包的合法性扫描插件；第二个，我不知道你们的IM工具是什么，我们用过RTX，是腾讯的，最后还是使用自己内部的，因为现在手机厂商竞争很激烈，这个消息工具一定是自己开发的。

还有项目和子项目，构建结果的数据统计，这个可能不太具有普适性，每个人关注的不太一样。重大构建失败的语音播报，我们顶级项目这个方面不能出错的，出错一定要第一时间知道。

后来弹什么RTX消息、插件没有用不够及时，最后办公室有一个大屏幕显示、还有喇叭。有一个女声帮你读出来，谁的项目几点几分因为什么事情构建失败，大家就第一时间知道了。这个事情很好玩。

最后一个是监控面板，我们刚开始展示的监控面板，最后发现总觉得差点什么，不太好用，不能满足需求，所以自己开发了自己的监控面板。

国际化。上午有的同学提到了，好像资料也不少，但都不太权威，很多是个人二次加工过的二手知识，或者是博客文章写的，当时的环境可以，到我这里就不行，官方文章我个人认为非常健全，有三个部分，入门导览、教程、用户手册，我们现在也有参与翻译，有兴趣的同学可以关注我的github ID。

想参加 Jenkins 的专场活动，你还不知道DOIS？

6月30日上午 · 北京 · DevOps 国际峰会强势来袭！！

DevOps 风向标！ DevOps 的落地实践，尽在 DevOps 国际峰会

详情点击 阅读全文