基于 Jenkins Log 秒级数据的研发效能改进

作者简介：

这是我自己的介绍，我之前在诺基亚和华为都工作过17年的时间，目前我是负责无线云平台公共服务部门，做研发团队的服务，跟Jenkins的定位非常接近。

前言：

在过去的17年里边我们碰到一个问题，就是如何不断地做效率改进。我一直在问是不是有一些普世的方法，或者一种通用的方法能够帮助我们的研发团队不断地改进效率。这是非常难的问题。在华为、诺基亚公司里边会有不同的方法去做效能改进，我相信各位在做的工作也有自己的方法。但是如何找区别找一个普世的？对我来说是一个非常挑战的事情。

一、数据是第一生产力

今天我希望带来一个目前的想法，就是可能的一种解决方案。我今天想介绍的解决方案数据是第一生产力，下面有一句话是沃德说的“使我们陷入麻烦的通常并不是我们不知道的事情，而是那些我们知道的不确切的事情”。

沃德是美国的文学家，在想想我们每个人的成长过程还是蛮符合我个人的经验，比如说我在读书的时候考试做不出的题一般来说是练得比较少的题目。在工作的时候写代码容易出错的一般是我对需求理解不太清楚的，管理岗位上工作上出的问题可能是老板不清楚。

大家开一下脑洞，假设有足够多的数据会变成什么样子，如果有足够多的数据每天的学习中就知道每种题型熟练程度是多少。我会知道哪一类的题会经常出错，哪个韵母发音相对来说并不熟练。我只要做简单的联系很容易提高学习成绩，因为我平时成绩比较忙，数据可以帮助我们很高效的工作和学习。

老板这儿问题也一样，假设你有足够多的数据，你可以对老板做一些客户画像、用户画像，你可以知道你的老板性格是什么类型的，如果你的老板比较强调控制力，如果有一天跟你说这个事情交给你去办，不用找我审批，其实你应该找我继续审批，不应该自己做决定。

如果是一个授权性的老板，你自己的事情了解清楚以后就可以自己做决定了。如果这个领导是自己家里的领导，不管什么事情都应该请示一下，要不然就不是智商的问题，而是情商的问题了。

1.1、产品线模块依赖关系图

接下来看一个具体的案例。这张图是现在所在产品线模块依赖关系图，这张图每个点表示我们一个软件模块，如果两个软件模块之间有依赖关系就画一条联线。

可以看到这张图复杂度是非常高的，我刚画完这张图的时候我自己也比较诧异，因为这是软件模块2.0的版本，1.0还没有这么复杂。之前我们整个产品线认知知道2.0迭代版本里边复杂度上升了，但是没有人知道到底复杂度上升到什么情况。我有这张图之后我把图发给工作人员，如果没有这个数据其实针对性就会相对比较弱。

这只是我们整个诺基亚产品线里边很小的一部分，也只是研发过程中的很小的一部分。如果把这些图，整个研发的流水线所有的数据都堆在一块，可以看到是一个海量的数据，这仅仅只是大海里的一滴水而已，即使是一滴水，每个后面都对应着一个研发团队，全球有600多个工程师。

整个研发过程数量量非常庞大，大数据技术在研发的过程上面的应用有非常多可以挖的点。今天的内容包含一些企业在日常工作里边具体的应用，我后面可以再具体的介绍一下。

1.2、平台研发发展进程

有了这样复杂的系统之后接下去在诺基亚内部整个研发改进的过程，可以看到水平线表现的是我们在整个数据采集过程里边数据的力。Y轴是定量的程度，刚开始做的时候可能跟每个公司一样，基本上是靠专家的经验，逐渐到第二阶段，可能这些专家升级了，这些专家的经验也比较一个KPI考核大家。

可能有些专家变成项目经理，可能变成项目的考核，或者项目计划。我相信很多人比较熟悉的是周报或者日报，一般项目经理都会要求发一些报告，在极限情况下一般来说项目报告一天发一个已经是极限了。我碰到更多的有的项目经理要求比较高，一天发两个，我估计项目自己也看不出来。

所以人的极限基本上就是在第三阶段，到第三阶段的时候，敏捷转型过程中伴随着整个工作的CI化，我们基本上所有的工作全部上自动化系统。这样的话上大量的数据，数据多到没有办法人工的分析数据了。

所以在第四阶段的初期数据是堆放在那儿，没有做太多的应用，直到最近几年大数据技术兴起，我们有能力分析具体的数据，那个时候才开始一些新的应用。

这里插一个段子，可以看到S轴定义时间序列的切片粒度。2015年的时候有一个伊斯顿（音）公司，当时2015年中国股灾的时候恶意做空中国股市。当时伊斯顿这家公司的做法用多个帐号去做交易，买和卖同时进行，分析出一百毫秒之内的分析。

这个事件带来一个提示，我们在数据上面有这个特性，如果你能够看到数据的切片粒度越小，你能挖出的信息量会越大。但是它带来数据会呈几何数的增加，不要说从天到秒，就是分钟到秒就差60倍，数据库是不是支撑数据量，后台的分析会带来非常多的技术和算法上的要求。

二、数据采集和分析方法

2.1、传统数据采集方法

所以在AI人工智能上有三个比较关键的点，数据、硬件、算法。这三个必须同时满足，算法和硬件早期是没办法解决的，直到最近几年人工智能的算法才能做下一步的改进。这是比较传统情况下的项目，这是五年前带的团队做的，当时我们的团队是全球分布的，橙色部分参与了国家项目，上面的点表示在那个城市有我们的研发中心。

这儿一共有8个国家，15个研发中心，参与到一个项目里边，做一个产品。当时在日本上班的同事上班的时间是最少的，日本同事下班了，美国同事还没上班。全球化的公司里边整个研发全球分布非常广泛，中间产生的数据有非常大量的数据不断地产生。而且是持续性的，因为全球时差的原因存在，第一个上班、下班，第二个还没开始，基本上24全球滚动的研发模式，任何一刻做的数据统计都是无效的。

还有一个比较大的问题就是人为的干扰因素，相信很多公司可能也会碰到这样的问题，我以前在华为的时候每个部门都会设一个CMO，专门做统计分析的，收集数据的人。我自己也兼任过一段时间，每天收集产品线的数据，报告给上一级，很容易出错，因为是全手动的。手动的误差一定存在。

还有一个比较麻烦，来自于央企或者政府部门的同学，因为有KPI的存在，大家在上报数据的时候有时候会有一些保留，不会把真实的情况完全报到上一级。虽然KPI导向稍微弱一点，但是或多或少存在，我们可能三四级。这样带来一个问题项目好不容易收集一个报告，但是数据跟实际情况不一定完全符合，在项目的管理上风险度是非常高的。

2.2、jenkins log采集方法

这个怎么破呢？这是很现实的问题，如果没有办法收集到准确的数据，什么都是白谈的。这个时候我们就想到了Jenkins，刚才我提到06—08年的时候杭州的部门，所有的CI的服务都在服务器上，我们的测试已经百分之百自动化了，基本上做到全流程都由Jenkins调度的。

这样的话就自然而然想到Jenkins Log的采集，这个Log记录了整个研发流程的所有数据。优点我这儿也列了，实时性非常好，Jenkins Log只要产生了就保存在Jenkins的服务器上。Jenkins Log想去作假对人来说已经没有能力做了，因为产生的数据太大了，滚动的速度太快了，而且广泛的在流程里边嵌入。

还有一个好处很容易收集，如果你想要相关的研发数据，只要找到像我这样的服务部门就可以了，扔个数据给我，马上可以扔给你。今天下班前收集一份，发个报告给我，那不好意思今天负责收集数据的工作人员请假了，下周给你，你也只能哈哈一笑。Log是比较稀疏的数据，里边分析的难度是比较高的，因为很多时候是人工的，有很多自然语言在里边，要做统一分析还是有技术难度的。

价值密度相对来说比较低，真正需要的Log就在一万行里边的一行，而不是说一万行里边全都是有效的。你要找到那一行的Log是最难的。过去几年我们在数据分析里边很难做更多的事情。右边这张图是目前存储在服务器的数据库里边，可以看到最近两个月的研发过程数据大概是3个TB，差不多就是每天5000万条记录。这还不是全部，只是杭州服务器上的数据，我只是截了一个片断。可以看到传统技术方案里边服务器能支撑的都已经很难了，对硬件资源消耗是非常大的。

我们来看看我们怎么去解决具体问题？刚才说到我们是用Jenkins来做整个CI体系，正好接上雪峰刚才说的方案，我们顶层的调度用的是Gearman，是做一级分发的工作，我们这儿目前使用的是Docker解决方案。左侧是Jenkins Master的截屏，一旦用完的话就直接删除，就释放回了。可以看到每一行对应到一个动态的节点，最下面表示即将被释放出去的Step，因为任务正好完成了。

使用权动态的模式之后会带来一些问题，大家看到各个模块全部已经Docker化了。带来的问题是实时性的要求比较高，因为我们要抓取整个研发过程所有的Log，Log还没采集Step已经被释放掉了。

2.3、OpenStack的解决方案

最后我们参考了OpenStack的解决方案，它是一个高实时性的队列管理的插件，做的主要工作一旦有Log产生发一条触发的消息出来。我们后台有一个是Log Puller模块，一旦受到了触发就会去抓Log。其实做的事情很简单，抓了Log之后要做几件事情，一个是要做所有Log数据的规划处理，因为在后台的分析来说对数据源的格式有一定要求，后台做事情很麻烦的，要做数据清理，要做规划，做完之后通过ERK平台存储到数据库里边。

同时大家要做一个备份，因为我们现在放到研发过程数据库里的数据不是全量数据，部分数据暂时用不起来，但是数据量很大，我们会存储到存储盘上，保证将来一旦需要用的时候这些数据还是可以被查询到的。大概从06、08年开始，之前的数据基本上还在，对研发来说这个数据是一个非常宝贵的资产，就看你怎么用起来了。

可以看到后面应用就是十年以来大量的存储上面，如果数据量少的话有些应用是很难做到的。可以看到我们这里还有一个AI系统，AI系统没具体化，AI系统用的各种框架也比较多。现在目前用的比较多的就是GOOGLE的解决方案。

最右边这一块就是运维系统，我们选了比较多的解决方案，对应道不同的需求上面，我列了一些开源，开源这一块参考的是Kibana，是目前研发体系里边做分析比较容易的解决方案，大家可以回去搜索一下。下面还用了Grafana，这个平台主要是服务器资源，我们公共服务架构在IT维护的基础架构上面，网络的问题和服务器的稳定性对我们整个研发体系的影响还是蛮大的。

所以我们在监控整个研发团队的开发过程之外我们还监控整个IT平台的稳定性，比如说杭州如果宕掉了，我们马上切到芬兰和美国，尽量对研发人员要做到透明，不用管自己设备在哪，全球任何一个机房里边都有可能是它的资源。

还有一个是Piwik工具，我们的客户都是研发的内部对象，我们还是用一些互联网公司技术，我们对研发人员做一些用户画像，我会知道不同类型的研发用户使用习惯什么样，可以对不同类型的用户提供更好的服务。中国的用户和芬兰的用户行为习惯就是不太一样，德国和美国的用户又不一样。

我们在资源的分配和整个研发生产系统设计的时候需要考虑这些因素，包括网站的使用都需要一个实时的监控。当然我们还有一些资源系统。这个平台带来的好处是什么？我们碰到管理上的痛点，很多的老大们会经常提我想要一个什么数据你帮我抓一下，现在还有比较大的好处，数据和可视化是分离的。

大家如果去看一下你去配的时候是非常容易的事情，现在有很多非常资深的管理团队的人员自己跑到我们的平台上，监控他希望看到的数据，而不是像原来传统做法，我要找到我的团队，你给我生成一个报告让我看到一个数据，这样效率很低。老大们的时间也是可以优化的，通过这个平台可以解决掉。因为在数据层这个层次已经把问题全解决了，剩下的只是排列组合，挑哪些感兴趣的数据而已。通过这个平台基本上这个问题就解决掉了。

我们再看一下最后搭建网的效果。最左边就在我座位后面搭的运维墙，上面把整个研发过程的数据都展示在那儿了。也带来一些负作用，夏天比较热，因为显示器会发热，夏天的时候把空调打得很足，因为我们是大厅，扔在一个角落里，但是也有一个同事开玩笑这就是一个烤箱，坐在边上的运维同事头发都掉光了。其实不是因为这个，已经掉光了才有了这个墙，因为研发比较辛苦。最下面是监控服务器，可以看到服务器响应的情况。

再往上一层，这一层我们监控的是整个研发过程中的吞吐量，整个Pipelines里边基于时间序列看产量的变化情况。如果做研发效能改进的比较清楚，你知道这个情况之后你会可以玩很多平衡生产线，或者做一些效率改进的事情，因为你知道整个研发流程中瓶颈到底在哪，因为哪个模块的开发让你的交付变慢了。你可以做这个分析。

这一块是我们集成测试的情况，显示的是最近三此集成测试，所有技术领域测试通过的情况。其实我们的力度可以细到每个测试，我目前可以跟踪到所有的工作，如果我想做一些测试改进，这些数据非常容易指导我们的具体工作，我可以找出10个经常失败的案例，找工程师谈一下有没有办法提高稳定性。

我找软件工程师，为什么你的代码在历史上的排名出错概率是前十名，我可以做非常有针对性的改进。最顶上这个是监控网站使用情况的数据。

三、案例分享

3.1、识别质量瓶颈

这张图是传统基于周报的分析，因为信息安全的原因，这儿所有的数据都做了一个透明的处理，最左边写了ABCD，其实每一行代表我们一个技术领域，每一列代表一次集成测试。里边的数字代表这次集成测试在对应的领域我们发现了几个错误，一般写报告的人分析到这儿就可以了，项目经理看一下这个地方红了。

但是他可能会忽略一些东西，因为项目经理也有资深和非资深，到现在可以玩很多东西出来了，比如说中间这个图可以做异常式分析，我可以得出两个结论，第一个技术领域比较有高风险的，红色和黄色这一行你可以加一块，我知道哪几个领域是高风险，经常出问题。这个时候可以找软件或者测试团队聊一聊是不是应该改进你的代码质量了，是不是应该改进你的测试稳定性。

还有容易被忽视的全是绿色的那一行，如果你做异常式分析的话也会识别出来。原因我们看到有些行永远是绿的，实际上去了解的话，业务上背景这几个领域案例测试覆盖率非常低，这也是一个异常情况，如果你的案例永远在跑，永远发现不了问题，永远带来不了价值，体现价值点就在于你发现了问题。

最右侧这张图，这张图是我们把每次测试的通过率，如果对单次的集成来说放在一行，最左边表示这个领域的测试是0%，最右边表示百分之百，就可以得到散点图。有了这张图之后，或者有了这些数据之后可以做一个相关性分析。大家应该听过一个故事，很多超市在卖尿布的时候发现买尿布的人经常买啤酒。最后分析出来是因为买尿布的人经常是爸爸，顺便买啤酒回家。A领域的案例失败的时候有高相关性领域的案例也可能失败。

可以看到这张图相关性非常复杂，如果人要做这个分析基本上不可能，除非你有非常深的业务领域的经验。研发团队首先分布在全球，人数也非常多，这个时候你要找资深的人在案例相关性分析上可能性非常低，因为这样的人在公司一定像宝贵一样，到处要救火。通过数据分析你就可以知道所有的技术领域之间相关性是什么情况，这样带来什么好处呢？

我们现在研发的工作模式是基于单创的开发，在分支开发的模式上面对质量的要求非常高。有了这个分析之后分支就可以给开发人员建议，如果没有足够的时间跑全量，可以跑高相关的案例。这样的话可以把整个测试的周期，这样的话集成的效率非常高。相关案例的概率是多少，这个时候有多少资源，有多少时间，一算就知道了，你能跑多少case。

从时间维度上可以看到下面，从分钟级下降到秒，从小事级下降到秒。如果完成的话，至少从天降到秒。第一个是编译的失败，我是用随机梯队的算法做错误分类。大家做集成这一块经常碰到一个困难，编译经常会挂掉，这时候我要去分析为什么挂掉。有很多原因，很有可能是因为代码原因，也有可能是因为环境原因，或者某一个脚本哪出问题了。

这个时候如果人工分析是很痛苦的事情，回到前面那一张，很多红点的图，你会发现600多个模块都跑的话，就算能做到99%的稳定度，每天假设跑一百次编译的话会有多少模块失败。

如果维护这个工作的人就会非常的烦，虽然每次已经做到很熟了，打开去看一下历史上编译失败是什么原因。而且做到最熟一分钟的时间还是需要的。我们当时大概就选了十几种算法对比了一下，最后选出来是SAD的方法，目前可以做到接近百分之百的正确率，只要这个编译失败了我就知道这次编译失败的原因是什么，如果是代码的原因就发给软件开发人员修复，如果不是代码原因就发给相关的人修复。

中间这个是另一个应用，如果有测试背景经常碰到一个问题，如果一旦测试失败我需要定位这次测试失败的原因是什么。一方面是个技术的问题，因为在集成测试阶段要了解整个产品，培养期是非常长的，特别是刚才看到有几百个模块的时候，每个模块都很熟悉几乎是不可能的。

所以你需要花大量的时间调查失败的原因到底是什么。假设发现这个问题就是A和B两个模块有一个可能出问题了，但是在企业里边经常碰到A和B两个不同的部门，两个互相踢皮球。作为集成测试团队来说经常碰到这个问题，最后扔到谁就是谁，先改了再说。

如果有一个方法能够自动的找出或者大概找出测试失败的原因，至少测试团队里边是非常有效的事情。目前做了11分类的算法，我们现在用的算法是随机的，这张图我们做了一个IOC曲线评估，在这个案例历史的数据会少一点，所以它的有效性不是太高。另外几种分类基本上可以做到97%以上的准确率，只要失败了我就可以知道是属于哪个错误分类，只要找对应错误分类负责人解决就可以了。

3.2、机器学习算法探索

最后这是比较有意思的项目，但是这个项目现在还在进行过程中，这个项目是我和贝尔实验室的几位同事在做的，因为贝尔实验室已经被诺基亚收购回来了，去年我们把阿朗合并进来了，贝尔实验室也加入了诺基亚。

这个同事是我和他们在搞的，现在还只是在启动期，我们的目标是这样，测试人员有大量的时间在日常工作里边写自动化脚本，我们最终目标是只要市场或者前端把你的需求用文字描述出来，我可以自动生成所有的自动化测试脚本，这个时候我可以把大量测试人员从手动写测试用力这个事情上解放出来。效率的提升应该是几个数量级的提升，一半以上的测试人员都可以做其他的工作了。

当然基于几个秒级数据更多的数据，首先是所有测试都抓进来，这个数量非常大，继续学习算法里边是非常少的。代码的数据我们也要抓取，因为在我们内部有一个工具，所有的编译做了一些工作之后可以让做功能测试这一级，跑完之后我知道运行了哪些分支和哪些具体的代码。

每个案例在各种测试场景下面覆盖到了哪些代码，反过来我就可以知道哪个需求在代码上的关系。一旦有大量海量数据的时候我就知道背后有哪些代码，当然指的是测试代码，还不能做到把程序员替换掉。基本上做到秒级就可以做到自动化配置了。

分享的主要内容和应用就这些，回到开头的主题，大家可以看到一旦拥有了Jenkins Log之后，在上面带来了大量新的信息，在这上面可以做非常多的新工作。这些应用只是在日常中应用的一小部分，数据在目前或者在可见的将来可以看到对研发效率改进变得非常重要，如果各位数据还没有开始积累，我个人建议你开始积累自己公司内部的数据，和一切想到对公司将来发展有意义的数据。