[关闭]
@gaoxiaoyunwei2017 2018-12-12T02:17:51.000000Z 字数 6405 阅读 511

诺基亚DevOps演进 大数据推动流程优化与高效执行

luna


作者:叶鹏程 技术专家

image.png-53.4kB

引子

诺基亚现在依然是全球最强的企业,运营商服务方面都是未来世界领先的,诺基亚现在还是很好的,并没有被干掉。我分享的主题是诺基亚DevOps演进-大数据推动流程优化与高效执行,这个分享不是分享DevOps的理论,也不是分享自动化的构建,我这个分享的话大家可以当做整个案例,如果大家在整个部署、研发过程中遇到了相同的问题,可以从中找到方法进行处理。

简单介绍一下这个标题,诺基亚在这么多年的过程中,实际上整个自动化流程已经处于一个高效的运作中,我们如何进一步提升,使得整个开发更加高效,我们开展了一个引进,内部提出了一个方法,通过大数据来推动流程优化。这块涉及的软件都是诺基亚的内部软件,所以不会介绍整个架构或者软件的基础,整体上是以方法来指导。

目录

image.png-58.1kB

1、诺基亚DevOps发展

我首先介绍一下这个案例的背景,诺基亚DevOps的发展,现在诺基亚发展阶段DevOps的方法取得了非常好的成绩,目前新功能提升了1000倍,实际上很难用数据来统计,诺基亚本来有上百年的历史,它的软件开发是从很传统的模式一步一步走过来的,所以说早期的时候软件开发模式是跟客户进行沟通,中间的过程很难再添加新功能,在这么多年的实践之后,我们在任何的时间,任何的项目环节与客户谈这样的开发。我们在整个软件上也提升了50倍,最初一年一两次,现在可以按照周来交付,这些成绩跟互联网还是有很大的差距,因为我们诺基亚软件和硬件都是相关的,硬件是定制的,软件系统是定制的,所以提升了50倍的频率,已经非常高了。在自动化流程之后,我们降低了三分之一,失败恢复率提升了20倍,减少了大量人工工作,使得我们减少了重复工作。
image.png-70.9kB

2、个体之间的混乱之墙如何解决

image.png-58kB

今天要介绍的内容是我们诺基亚在取得了这样的一个成绩之后,从一个非常传统的软件开发,非常低效的,整个流程搭建好之后非常高效了,在这个程度上如何再次提升,我们就要从非常细节的角度发现和挖掘这些问题,进一步把效率提高。我这边介绍的功能和平台都是针对研发这一块的,我想从三个分析来引出我们这个解决的思路,第一个我们关注的是个体之间的混乱之墙如何解决,这张图大家应该都见过,大家对DevOps也很清楚,介绍的是DevOps解决开发和运营之间的问题,是从宏观方面去看待整个流程,这样的话开发更关注的是快速的交付,快速的跟进,尽可能的部署出去,让软件更加的稳定,这种相互之间目标不一致导致了整个开发流程并不是特别的高效,所以我们在引入了这个方法之后打通了,整个流程实现自动化,从而提出了整个的效率。

image.png-266.1kB

我要说的是,我们在做更细致的研究之后发现,希望从宏观方面观察混乱之墙,我们发现还存在大量的组织内部的混乱之墙,我称之为个体间的混乱之墙,个体并不只是个人,还包括个体、整个自动化流程中的每一个环节、每一个部门,每一个人、每一个流程,虽然整个是自动化的过程,但是实际上每一个环节都可能受到一个人工干预,比如说下一个流程是上一个推送的流程触发的,如果在这个过程中出现了一些问题、失败,都要人工干预进行调整,这样的话只要有人工干预就会产生一些不必要的影响,有些部门会因为自己的组织力,有些个人会因为个人的利益来影响整个的流程,会做一些非法的干预。有些部门安于现状,整个流程搭建好之后就觉得没问题了,不会再想办法提高效力,这样我们如何发现问题呢?如何进行流程优化呢?部门与部门之间存在相当大的信息壁垒,我们每一个自动化的流程都是由不同的部门进行一个管理的,这样的话下一步只知道上一个部门的最终结果,并不知道上一个部门内部到底经历了什么,测试是否完整,需要知道详细的过程,这种情况也导致了我们在软件开发中出现的一些不必要的问题。
image.png-462.2kB

比如说没有经过完整测试的模块就发布出来了,我们可能会存在这种情况,有些研发组织工作量非常大,因为进度或者一些其他因素的影响,在整个测试环节中没有经过完整的验证,可能就会觉得这个测试环节对这个模块有影响,还有一种情况做了测试,但是测试失败了,做分析的时候发现是由环境因素引起的,这个问题没有相关的,不再做重新完整的测试,直接把结果发布出了,说这个结果是没问题的,这种情况下就会对下一个环节造成不必要的影响。
image.png-101.9kB

平台的工作汇报,我们组里面有专门的操作系统开发组,这个组是要跟内部每一个人建模块,一旦有功能更新的话每一个模块都应当进行适配、调整、开发,这样的话基本上每次发布一个新的功能都需要召集所有软件部门进行周会、日会,讨论一下情况,一些问题改进的情况等等。诺基亚员工遍布全国各地,东南亚的,中东的,这种实际上非常消耗时间而且没有意义,我们发现每次会议都要开一、两个小时,这样对效率非常有影响,这种情况我们如何去解决?
image.png-200.8kB

第三个是问题的追溯变得非常的艰难,问题没有得到解决就往下面推的话,慢慢这样就会找不到问题的源头,寻找起来也非常的艰难。
image.png-154.7kB

在这些问题中我们一个核心的问题就是我们信息壁垒,相互之间不知道对方的情况,信息获取非常艰难,如果下游的组织想要了解上游的具体信息需要直接沟通,但是这样会非常的低效。
image.png-287.7kB

解决这样一个个体之间信息壁垒的问题,我们大数据使得所有数据进行统一的展示,上面是我列的一个简单开发的流程,可能不是很完整,模块经过验证之后会进行一个编译,编译出正式的包之后再进行一个产品级别的测试,整个过程的话我们这个大数据平台对每一个环节都进行了监控,首先对代码仓库这边我们进行直接对接,收集代码仓库中每一个代码的排列号,记住代码中所列出的功能信息、功能ID,对接代码提交之后代码每一个测试平台,收集每一个测试平台的测试结果,包括测试哪些内容,测试时间,测试的覆盖范围,然后测试具体的结果报告,在编译环节做一个详细的编包情况,相对于上一个包具体做了什么变化,还有就是产品出来我们对产品的测试平台进行同样的监控收集,这些数据收集完之后我们就会做什么呢?
image.png-183.1kB

大数据可以干什么,我们可以监控在整个流程中的所有数据,什么时间,现在处于什么环节,做的是否完整,内容是否按照要求完整进行了,都可以做一些监控。将所有的数据进行可视化,统一的展示,所有相关人员都可以从同一个地方直接获得他们想要的数据,不再需要我要找这个部门去要,找那个部门去要,这是数据可视化的平台。我简单截了一个图,这个是一个模块级的测试监控的结果,外面这一圈就是我们监控的代码仓库,每一次提交都会有代码仓库自动形成一个编号,这样的话收集的每一个代码编号,往下游走的时候我们会监控每一个测试的环节,包括编译的情况,就是中间这一块,代码测试情况,功能测试情况,分析以及代码最终去了哪个包,又可以展示具体的内容,右边会直接弹出整个测试覆盖的情况,测试的结果,测试的时间,这样的话我们所有的事情都是可追溯的,任何一个环节想做一些不必要的或者非法的事情都是可以马上监控到。
image.png-110kB
image.png-336kB

这个是产品级别的展示,比如说最左边是我们的各个包,每个包中间有一个小圆圈,代表着不同的变化,第一个包做失败了,这个就很快定位了,这个模块可以快速做一些软件分析定位问题。比如说下面有一些红色的小圆圈,往前追溯的时候可以快速定位到失败的情况到底在哪里,点击每一个测试内容,测试在哪些硬件做的等等。这块是一个功能,这个表不全,这里展示的是一个功能从提交到交付,所有的测试、验证,整个的过程是否每一步都是正确的,这边展示的是整个测试数据,这块的话我们内部也在开发中,所以数据可能不太好看。对于项目经理来说,如果比较关注整个项目周期的话可以在这里看到整个需要的功能经过了多少时间完成,测试是否都是通过的,整个周期怎么样,看到周期的比对如果觉得周期不好如何去提升这样的效率。
image.png-217.9kB

我们的平台还有一个问题跟踪登记的过程,包括用户如何发现软件问题,快速在上面做一个登记,之后的话对整个问题进行一个全流程的解决过程,哪些问题是比较严重的,怎么样避免。对于大数据平台来说要挖掘数据的情况,从而进行流程的优化,这是其中的一个数据展示功能,展示的是每一天包平均的测试时间,绿色都是通过,灰色是有问题的,这样的话对于整个流程来说可以关注,绿色与绿色之间做关注的话可以知道为什么有些频率低,看红色的话就会看到这几天测试情况有些问题,对于管理者来说就会更加清楚的知道当前整个流程,整个环境中哪里出现了问题,可以做一些分析,这是其中的一个,如果我们还可以做各个流水线之间的相互比较,从而看到那一条流水线消息高,这一条流水线消息比较低,这是所有展示的介绍。
image.png-126.7kB
image.png-102.3kB
image.png-213.7kB

大数据平台不只是做数据的收集、展示,还有就是做数据推送,整个流程的话在搭建自动化流程的时候都会上游做一个,下游做一个,我们数据平台可以直接往下游接送,减少测试员不同的建立自己各种的脚本。可以对接邮件服务系统,如果测试员想要了解整个平台中想要关注数据的情况,都可以进行邮件推送,查询,任何人都可以在平台上查询每一个包的情况,产品的情况以及具体信息。
image.png-131.9kB

这是我们内部的大数据平台的现状,当然在互联网上可能这个数据是不怎么样的,但是对于一些内部平台来说其实很客观,日新增数据达到了10GB,日用户访问数达到800,负载均衡分布式部署的。我们做完这个平台之后收益是非常大的,对于开发人员来说可以自己提交代码,代码提交了之后代码整个的CI情况,可以看到自己的代码是否被正式的产品应用了,可以查看自己提交的代码在哪个产品包里使用,还可以查看自己提交在对应产品包的相关CI情况。
image.png-62.8kB

每一次对测试的时候可以知道这个测试的包相对于上一个包具体做了哪些变更,这样的话心里已经有数了,万一失败了就很容易定位失败的原因,这些改变可以关注每一个环情况,本身这些改变是否已经被完整的验证过了,这些验证的过程是否按要求做了完整的覆盖。对于项目环境来说一个feature是否在整个流程中进行过完整测试验证,检验整体开发进展,检查各个环节的效率,可以改善交付质量,促进流程优化,提高交付效率。
image.png-116.4kB

回到前面说的大数据平台要解决的问题,就是解决个体之间的墙,这样的话整个流程实际上排除一些人为的问题,未经验证就发布出来的代码就会受到严格治理,排除相互扯皮的情况,以数据说话,以数据来进行对话,这样的话会排除很多项目扯皮、推托等情况。加强协作促进改善,相互之间的信息共的享更加流畅、减少沟通障碍。

image.png-149.1kB

3、分散的构建测试平台如何统一

image.png-58.1kB

我们本身已经搭建了大数据平台了,本身这个数据平台已经整合了所有数据,我们就是要如何解决分散的平台,现在实际上很多情况不知道大家都是这样的,整个流水线上还有很多的流程、很多环节,每一个环节有不同的部门来去做,需要搭建一套这样的平台,需要建一个服务器,需要投入运用维护,每个部门相互之间是通过部门与部门之间有专门的维护人员去构建脚本,使得整个流程能够进行下去,整个过程实际上有很多的弊端,第一个资源利用率比较低,有些部门可能任务没那么重,资源就非常的浪费,第二个就是构件流程非常复杂,各个部门之间自己去构建流程,有接收脚本,接收下来之后会把任务再分配给其他人,所以整个流程变得非常复杂,维护成本就会很高,每一个组可能都需要投入人员,人力、物力需要维护服务器脚本,难以做需求的定制,对于测试员难度比较大,这一块的话想对平台做优化其实是很困难的。
image.png-85.3kB

这一块我们就提出了依托大数据的平台做的一个统一平台,这个统一平台是提高资源利用率,避免性能冗余或者性能不足,可以做弹性扩容,简化构建流程,所有整个流水线的流程不再有大量的企业,只有验证本身测试内容,通过大数据平台和流程和执行平台相互触发去推送,帮忙解决每一个推送触发问题。降低维护成本,可以统一开发运维,减少重复工作,不需要再关注各种各样的复杂的一些事情,按需定制,专门开发团队支持,帮助团队完成需求定制,让测试人员关注测试本身,测试的内容是什么,关注这方面就行了。

image.png-95kB

这是我们基于大数据平台核心的功能,执行平台是与大数据平台相关的,数据平台碰到代码提交之后就会把代码提交情况送给执行平台,执行平台第一个任务就是获取这些任务,获取任务之后会做一个任务的分配,把任务给到下一个测试内容,测试完成之后又会把结果反馈给执行平台,就是这样一个相互循环的过程使得整个流程高效执行,有些看到的只是测试的内容本人,不会看到后台的内容。
image.png-94.4kB

我们如果做一些统一平台的话需要一些特性,支持对某一资源进行随机调度进行相关测试,充分利用测试资源进行一个管理,对测试线管理者来说可以很好管理的自己的测试线,减少性能开销,同时支持更多的任务调度,最核心的就是我们满足部门开发不同的用户个性化的需求。
image.png-113.4kB

4、大量冗余测试线如何高效利用

image.png-57.9kB

最后一块我们搭建完平台之后,最多关注的就是把测试线如何高效的利用起来,我们诺基亚核心产品是硬件,跟互联网不一样,互联网是软件,我们每一个部门会搭建各种各样类型的硬件环境,这些硬件环境都是实打实的,成本非常高,一套几十万,每一个组都需要对不同的硬件进行测试,就算是一个很小的都有四、五十套,自己的组搭建这种测试环境的话其实上成本非常高,利用率非常低,有些测试线只测几个包,这样的话需要相应测试组开发人员维护硬件,要有专业的硬件维护人员,还有就是更换代价也很高,更换的话需要重新定制,配制非常的复杂,价格也是非常的高。
image.png-85.3kB

这块我们所做的努力是将硬件组合,云测试线,包括测试控制机,自动化框架,在这个基础上我们云服务就对整个测试件加了进程,主要就是将每个测试线自动的初始化,当我们有足够的云测试件之后我们再通过云管理服务,将这些测试线进行整合,形成统一的资源池,这样的话用户就不需要管理这些测试件了,每一个测试人员或者开发人员,只要在云管理服务商订阅这个测试线,或者分配任务给这些测试线,就可以完成相应的测试或者相关的一些需求,而不需要维护、调试,初始化测试件,因为刚拿到的测试件都是初始的。
image.png-89.1kB

我们的测试线在全球不同的地方都搭建了实验室,主要实现了一些核心功能第一个就是用户可以直接在上面订阅一条测试线,个人的一些需求,就可以直接在语音服务上直接订阅直接配置,在一定的时间点都会完全给测试人员所有,第二个的话可以做一些单独的任务分配,比如说我们的执行平台,收到任务之后直接调一个测试线直接测试任务,不需要人为干预配制,第三个的话可以对批量任务做随机的调动,比如说一个包可以进行不同的测试,同时可以通过云服务的话对资源进行调动,获取所有相对应批量的测试线,并将整个这些任务反馈给大数据平台。
image.png-218.4kB

云服务给我们带来核心的保护就是降低成本,资源高效利用,我们现在统一运维,不需要测试人员,可以做自己单独的配制,整个是无人值守,会自动完成整个初始化配制,帮助用户进行一个简单的设置就可以直接进行测试。
image.png-172.4kB

今天的内容简单总结一下,首先我们在前期的构建和自动化流程的时候,因为组织非常的庞大,遍布在全国,每个组都有自己的代码仓库,都有自己的平台,这样的话这些平台和仓库非常零散的分布在各地,使得整个的数据共享系统非常差,所以我们通过大数据平台对所有的数据进行了一个整合,实现整个数据的可视化,在搜集数据的基础上做一些数据分析统计、数据挖掘,帮助我们开发人员或者测试人员更好的了解整个流水线的效率情况,如果数据积累到一定程度到时候可以发现一些关联性的问题,我们很多情况下发现问题寻找问题根源会很难,但是通过数据的比对、碰撞就会直接发现问题的关联性,进行效力的提升。

我们通过大数据平台想构建一个完整的统一执行平台来与大数据平台进行交互、循环的流程,从而减少了下面这些,如果还在用的话减少了维护成本,让整个流程更加的高效,最后我们通过测试线使得整个硬件成本降低了非常多,也降低了我们对环境的维护,以上内容就是这个的,最终目的就是为了让开发和测试人员更加关注他们开发测试本身,不用去做一些琐碎的、其他相关的内容。以上就是我今天的分享,谢谢大家。
image.png-118.1kB
image.png-90.4kB
image.png-79.6kB

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注