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

作者简介

叶鹏程

诺基亚技术专家

引子

诺基亚作为全球领先的通信软硬件制造商，已经有多年的 DevOps 实践经验。

今天我分享的主题是诺基亚DevOps演进-大数据推动流程优化与高效执行，分享的不是 DevOps 的理论，也不是如何搭建自动化流水线，我的分享更偏向于是一种处理这些问题的案例，如果大家在整个部署、研发过程中遇到了相同的问题，也许可以从中找到方法进行处理。

简单介绍一下这个标题，诺基亚在这么多年的过程中，实际上整个自动化流程已经处于一个高效的运作中，如何进一步提升，达到下一个效率台阶，使得整个开发更加高效？

经过我们长期研究，内部提出了一个方法，即通过大数据来推动流程优化，效率提升。

1、诺基亚DevOps发展

首先简单介绍一下背景，诺基亚在DevOps的实践中取得了非常好的成绩：

新功能引入效率提升了1000倍，这个实际上很难用数据来统计，诺基亚有上百年的历史，它的软件开发是从很传统的模式一步一步走过来的，所以说早期的时候软件开发模式，开发的过程中很难再讨论引入新功能，而在进行DevOps实践之后，我们现在就可以在任何的时间，任何的项目环节与客户谈新的功能。

我们在整个软件部署频率上提升了50倍，最初一年一两次，现在可以按照周来交付，当然这些成绩跟互联网还是有很大的差距，因为我们诺基亚软件和硬件都是相关的，硬件是定制的，软件系统是定制的，随时部署，对客户来说可能也是没法接受的。

在自动化流程之后，我们降低了三分之一，失败恢复率提升了20倍，减少了大量人工工作，使得我们减少了重复工作。

取得了这些成绩，我们不打算止步不前，有了更进一步的想法，从更细节的角度来寻找提升效率的方法。

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

我们在讨论DevOps的时候，通常会关注开发和运维，他们之间的混乱之墙，我称之为组织之间的混乱之墙。

它指的是传统开发模式，开发和运维相互独立，致使各自有各自的诉求，开发更关注交付速度，他们希望开发的每一个功能都快速交付部署，他们做的是不停变更；

而运维更关注质量，担心不停地变更不仅会带来更高的资源投入，还可能引起更多的质量问题，所以他们更关注稳定性。

相互之间的目标的不一致导致软件无法高效交付。DevOps方法鼓励各个组织之间加强沟通协作，通过流水线式的自动化工具，实现组与组之间的自动化按需交付，有效改善了双方在交付软件过程中的速度和质量，通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性，以及可维护性。

但是，所说的这些更关注的是一个整体的效率，当整体的效率达到了一定的高度时，继续改进变得困难。

所以当我们开始去思考细节的时候，发现了这个问题，个体之间的混乱之墙。个体并不只是个人，还包括整个自动化流程中的每一个环节、每一个部门、每一个流程。

虽然整个流程是自动化，但是实际上每一个环节都可能受到一个个体干预，比如上游触发下游任务，如果在这个过程中出现了一些问题、失败，都要个体干预进行调整，这样的话只要有人工干预就会产生一些不必要的影响，有些部门会因为自己的组织利益，有些个人会因为个人的利益来影响整个的流程，会做一些不正当的干预。

有些部门安于现状，整个流程搭建好之后就觉得没问题了，不会再想办法提高效力，这样我们如何发现问题呢？如何进行流程优化呢？部门与部门之间存在相当大的信息壁垒，每一个自动化的流程都是由不同的部门分别管理的。

这样的话下游只知道上游推送的一个最终结果，并不知道上游内部到底经历了什么，测试是否完整，如何获取详细的过程，这种情况也导致了我们在软件开发中出现的一些不必要的问题。

没有完整测试过的模块被正常发布出来。

a) 有的为了追求速度，人为干扰正常的开发测试流程，对一些测试人员认为不是问题的，可以先不去考虑的情况，直接忽略；

b) 或者就算测了没过，测试做了简单分析后，认为这可能是环境引起而是不是软件问题，于是并没有去重测，便直接往下游推送；

c) 这就造成了交付的质量并不能很好地得到保证，而问题发生后，因为相互之间通过触发器去触发自动化流程，但是相互之间又看不到对方内部的具体情况，于是便会经常产生扯皮现象。

案例：去年，我司的某个软件部门，发布了一个模块的软件，研发部门将这个软件合入主包，做功能测试的时候，直接导致硬件检测不到，更严重的是，无法通过软件直接修复，需要带上串口版，通过很复杂的命令行去做软件回退，这对于下游做功能测试的人来说，完全没有经验，不仅浪费了大量的时间来修复站，还拖延了其他软件模块的正常发布。

在后续的原因追查的时候发现，测试人员并没有完成符合要求的完整的测试流程，就把软件发布出来了。造成了很大影响。

越来越频繁的汇报工作影响个人工作效率

因为庞大的组织架构，使得当一个流程需要汇聚多个流程的结果时，这个流程的汇聚点便会自己构建一套完整的平台来对所有结果进行监控，而因为无法知晓对方的内部情况，这种情况的监控通常只是得到一个最终结果，于是就需要周会日会，来每日跟进没一个模块的具体情况，汇总具体的问题，跟进修复的进度。这在无形中增加了大量的资源投入，而这我们认为是可以大量减少的。

案例：我们有一个平台组，该组需要跟其他所有的模块进行交互，模块多大几十个，于是每天都会有个日会，着急所有模块相关开发组加入会议，讨论任务/计划/适配/问题定位/人员安排等等，每天一个小时，雷打不动。这对于日常工作非常繁忙的开发来说，着实是一件非常费时费力的事，而且因为无法找到合适的解决方法，只能一直持续下去。

跨流程的问题难以追溯

因为结果可以被认为干预，所以一旦就近的下游无法及时发现问题，问题一直流到更远的位置才被发现，将导致问题的追溯变得异常困难。这种问题的处理和分析能力因人而异，有人可能马上找到了关键原因并正确汇报出去，有些经验稍差，可能会花费大量的时间去做分析却做出了错误的判断，从而导致发出的问题分析又引起很多不必要的投入，绕一个大圈，才找到最终的原因。

如果研发在发现问题的时候，可以迅速检查整个流程，并发现某一个环节没有得到正确处理，那是不是就可以先直接找到出问题的环节，缩小分析的范围，从而提高速度和准确性呢。

案例：曾经有一个软件包，因为新功能的需求，有个大版本更新，于是同一时间，同时更新了全部的模块，测试结果失败了，分析原因的时候，非常难定位造成问题的精确模块。

我们初步定位是模块A，但是由于同时更新的模块太多，测试始终不承认是他们的问题，推托，扯皮，为了把控制自己的出问题指标，始终想把问题推给别人，导致这个问题在不同的开发模块组之间转移的很多次，整个问题分析过程持续了一周多。

最终发现，是模块A开发组内的CI过程出了问题，没有对新功能进行完整的CI测试，导致把其实没有适配的模块发布到了新版本中。

当我们做以上分析的时候，会发现，发生这一问题的核心原因，是信息壁垒，诺基亚本身是一个非常庞大的组织，同一条流水线，每个环节都可能在全球不同的地方去执行，基本上每个环节都会自己的负责人，搭建自己的自动化平台，相互之间，约定好触发条件来打通整个流水线。

通常下游只是收到上游一个触发信息，是上游的一个结果，别的什么都没有，上游具体的过程对下游来说是盲区，当然非要去了解，还是可以通过各种手段去查询，但是这样就变得低效，日常工作也不会这样去做。所以，如何来应对这种个人因素引起的混乱之墙呢。

我们的答案是大数据实践。

解决这样一个个体之间信息壁垒的问题，大数据使得所有数据进行统一的展示，下面是我列的一个简单开发的流程，可能不是很完整，模块经过验证之后会进行一个编译，编译出正式的包之后再进行一个产品级别的测试。

整个过程的话我们大数据平台对每一个环节都进行了监控，首先对代码仓库这边我们进行直接对接，收集代码仓库中每一个代码的排列号，记住代码中所列出的功能信息、功能ID，对接代码提交之后代码每一个测试平台，收集每一个测试平台的测试结果，包括测试哪些内容，测试时间，测试的覆盖范围，然后测试具体的结果报告。

在编译环节做一个详细的编包情况，相对于上一个包具体做了什么变化，还有就是产品出来我们对产品的测试平台进行同样的监控收集，这些数据收集完之后我们就会做什么呢？

通过大数据实践来解决这样个体之间信息壁垒的问题，整合全流程数据并进行统一的展示，上面是我列的一个简单开发的流程，可能不是很完整，模块经过验证之后会进行一个编译，编译出正式的包之后再进行一个产品级别的测试，大数据平台对每一个环节都进行了监控，首先直接对接代码仓库，收集代码仓库中每一个代码的版本号，记录代码中所列出的功能信息、功能ID；

收集每一个测试平台的测试结果，包括测试哪些内容，测试时间，测试的覆盖范围，测试报告；监控没一个正式包的数据，相对于上一个包具体做了什么变化，还有就是产品出来我们对产品的测试平台进行同样的监控收集。这样的话我们所有的环节都是可追溯的，任何一个环节想做一些不符合规定的内容都是可以马上监控到。

这是一个异常艰辛的过程，我们平台搭建好后，几乎花了一年多的时间来整合了一条完整的流水线，原因还是在与人，大家可以想到，让每一个组每个一人都心甘情愿配合完整这一项工作，是非常艰辛的，最终我们成功整合了一条完整的流程。

基于这些数据，我们进行清洗，分析，挖掘，从而实现了更佳高效/适合全流程相关人员使用的数据化展示平台。

每一个环节的过程和结果都可以被很好地以图形界面进行统一的可视化展示，这不仅解决了每个组有各自的数据展示页面使得对于其他组可读性极差，也帮助每一位相关人员都可以清楚地知道每个环节的具体情况。通过大数据平台可以对数据进行多维度的展示：

模块级测试展示

针对每个模块每个代码的提交，展示每次提交的CI测试结果，包括编译结果，单元测试结果，静态分析等等，并显示哪些提交是被正式并入正式包，最终都在哪个正式包中被使用。同样也可以显示具体的测试内容和细节。

通过这个对于下游环节的人员，就可以很轻松地得到上游完整的情况，比如下游测试失败了，反过来发现上游很多测试都没过，就可以直接对他们提出质疑，为何并不是所有测试都通过了，却还可以release出来。

这种情况有效帮助下游非开发人员更加高效的定位软件开发模块的问题，缩小问题排查的范围，甚至不需要很细致的分析，就直接把问题打过去，挑战上游环节的完整性，从而促进上游开发改善其缺陷。

产品级测试展示

针对每个编译后的正式包，展示其编译情况，以及包出来后各个流程的测试情况，同时对每一步测试，又直接图形化细节展示，有多少个测试线在测试，测试线的具体配置，每个测试线所测试的内容，测试结果，并根据结果实时跟新整个测试步骤的结果，并且每一个结果的日志都可以直接点击展示，将过程完全展示，消除测试内容和结果的人为非正常干预。

针对feature的全流程展示

针对某个feature从提交到交付整个过程所有经历进行展示。

原来检查一个feature的交付是否满足交付条件，都是设置看一个一个的检查点，项目经理来一个一个去检查，通过大数据平台，直接按定义的步骤，关联feature，展示整个过程中每一个步骤的测试/验证情况；

代码编译是否正确->代码是否提交到需要的包上->SCT测试是否完成->Regression-> SCT/PIT是否关联到feature->UT测试是否完成->静态分析->动态分析等等，全流程逐一列出。帮助相关人员更清晰也使其拥有自动化的方式，去评价一个feature的交付进程。

问题登记系统，帮助用户在发现软件问题时，快速在上面做一个登记，对问题进行实时跟踪，自动关联问题系统跟新问题状态

通过对全网数据进行整理存储，诺基亚建起来庞大的数据库，整合了全网的数据，存储了完整的历史数据，这使得我们在做数据统计的时候更加精准。

可以针对某个流程，某个包进行多重类型的数据统计，比如展示某个分支每日/每月/每年的执行情况，执行效率，帮助负责人更加清晰地了解自己组内测试的情况，为他们的持续改进提供数据基础。

举例，从这张每日的图，可以看出这个分支每次测的包的数量，每日的测试成功与失败数量的直观显示。另一张图更可以看出执行的效率，每日执行所有包的平均耗时，我们现在人容易就可以发现有些日子，红柱很长，管理者就可以切到测试页面，去看那几天发生了什么，这些问题的发生是否下次可以避免，从而有效改进未来的测试质量。

大数据平台不只是做数据的收集、展示，还有就是做数据推送：

自动触发下游任务，减少测试人员的触发脚本维护工作；

可以对接邮件服务系统，如果测试员想要了解整个平台中想要关注数据的情况，都可以进行邮件推送，查询，任何人都可以在平台上查询每一个包的情况，产品的情况以及具体信息；

对接包管理系统；

对接问题跟踪系统。

回到前面说的大数据平台要解决的问题，就是解决个体之间的混乱之墙，大数据平台完整的数据体系可以排除一些人为的问题，未经验证就发布出来的代码就会受到严格质疑，排除相互扯皮的情况，以数据说话。加强协作促进改善，相互之间的信息共的享更加流畅、减少沟通障碍。

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

我们搭建了大数据平台了，数据平台整合了所有数据，我们发现整个流水线上还有很多的流程、很多环节，每一个环节有不同的部门去做搭建执行平台，于是每个部门都需要建一套服务器，需要投入人员维护，每个部门相互之间是通过部门与部门之间有专门的维护人员去构建脚本，使得整个流程能够进行下去，整个过程实际上有很多的弊端，第一个资源利用率比较低，有些部门可能任务没那么重，资源就非常的浪费。

第二个就是构件流程非常复杂，各个部门之间自己去构建流程，有接收脚本，接收下来之后会把任务再分配给其他人，所以整个流程变得非常复杂，维护成本就会很高，并且让测试人员去完成平台的一些需求定制非常困难。

所以我们提出依托大数据平台，打造一个统一的执行平台，提高资源利用率，避免性能冗余或者性能不足，简化构建流程，通过大数据平台和执行平台相互触发去推送，来构建完整的自动化流程。这样做带来的好处:

抛弃了各类触发job，内置循环流程，大大减少了测试人员对流程和脚本的维护工作；

让测试人员更关注测试本身，不用再去维护繁多的上下游关系，只关注测试内容本身；

大量减少分散独立的自动化构建测试平台，优化资源投入。

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

具体来说，主要实现以下功能:

任务获取

通过用户配置实时关注数据平台的相关数据，从数据中获取任务；

任务分发

又系统统一调度，分发任务到各个流程，各个环节，各个测试线；

结果推送

收集测试线完成后的结果，反馈回数据平台；

回环式触发

平台收集数据后，对数据进行汇总判断，执行平台取得判断结果来调度执行下一个测试。

其他特性:

随机调度

支持对测试线的随机调度，从而充分利用空闲资源

测试线管理

以测试线为单位进行管理而不是job，使测试线管理人员更清晰地了解手里所有测试线的状态。

低性能开销

非实时连接，减少性能开销，单服务器同时支持更多任务的调度

用户定制化

专门研发团队，针对用户需求进行页面功能定制，省去了用户诸多人工搭建配置的工作，使测试人员更加关注测试本身，而不需要经常被一些琐碎的事件干扰

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

最后一块我们搭建完平台之后，最多关注的就是把测试线如何高效的利用起来，诺基亚核心产品是硬件，跟互联网不一样，互联网是软件，每一个部门会搭建各种各样类型的硬件环境，这些硬件环境都是实打实的，成本非常高，一套几十万。

每一个组都需要对不同的硬件进行测试，就算是一个很小的都有四、五十套，自己的组搭建这种测试环境的话其实上成本非常高，利用率非常低，有些测试线只测几个包，这样的话需要相应测试组开发人员维护硬件，要有专业的硬件维护人员，还有就是更换代价也很高，更换的话需要重新定制，配制非常的复杂，价格也是非常的高。

我们将硬件组合形成云测试线，通过云服务来统一管理所有测试线，形成统一的测试线资源池，用户不需要再管理维护测试线，每一个测试人员或者开发人员，只要在云管理服务页面订阅测试线，系统就会分配任务给这些测试线，就可以完成相应的测试或者相关的一些需求。

公司统一搭建上千条测试线，分布于全球各地，通过自动化进程进行统一维护，用户可以按需订阅资源进行测试。用户可以根据需求选择配置，选择后，测试线自动按需求进行初始化。

提供多种模式:

a)单条测试线预订

用户预订成功后，该测试线按配置的时间内完全归该测试人员个人使用，方便用户自己做一些自定义的测试

b)单个功能测试

用户可以在预订的时候直接选择测试的测试用例，在测试线初始化完成后，自动执行用户配置的任务，并把结果输出给用户

c)计划任务

做一些回归测试，批量的测试内容相对固定的测试，可以设置由上一个流程的推送结果自动触发完整的计划测试列表，系统调度全球可用资源，进行测试， 统一输出测试结果

诺基亚的测试线在全球不同的地方都搭建了实验室，主要实现了一些核心功能第一个就是用户可以直接在上面订阅一条测试线，个人的一些需求，就可以直接在语音服务上直接订阅直接配置，在一定的时间点都会完全给测试人员所有。

第二个的话可以做一些单独的任务分配，比如说我们的执行平台，收到任务之后直接调一个测试线直接测试任务，不需要人为干预配制。

第三个的话可以对批量任务做随机的调动，比如说一个包可以进行不同的测试，同时可以通过云服务的话对资源进行调动，获取所有相对应批量的测试线，并将整个这些任务反馈给大数据平台。

云服务给我们带来改变

降低成本

提高资源利用率

统一运维

用户配置选择，全过程无人值守，帮助用户进行一个简单的设置就可以直接进行测试。

今天的内容简单总结一下，首先诺基亚在前期的构建和自动化流程的时候，因为组织非常的庞大，遍布在全球，每个组都有自己的代码仓库，都有自己的平台，这些平台和仓库非常零散的分布在各地，使得整个的数据共享非常差。

所以我们通过大数据平台对所有的数据进行了一个整合，实现整个数据的可视化，在搜集数据的基础上做进一步的数据分析统计、数据挖掘，帮助我们开发人员或者测试人员更好的了解整个流水线的效率情况。

很多情况下我们发现问题寻找问题的根源会很难，但是通过数据的比对、碰撞就有可能会直接发现问题的关联性，使得问题得到解决。

之后我们基于大数据平台构建了一个完整的统一执行平台，与大数据平台进行交互、循环触发完成整个流程，从而减少了大量的分散小平台，减少了维护成本，让整个流程更加的高效，最后我们通过测试线的云化，形成统一资源池，统一调度，使得整个硬件成本降低了非常多，也降低了我们对环境的维护。

所做的一切最终目的就是为了让开发和测试人员更加关注他们开发测试本身，不用去做一些琐碎的、其他相关的内容。以上就是我今天的分享，谢谢大家。

说明：本文为诺基亚资深技术专家叶鹏程在 DOIS 2018 · 深圳站的演讲整理而成。

▼

GOPS 全球运维大会

2019 年全国首战

4.12-13 深圳启航