网易张涛：网易新闻DevOps实践及在AI测试中的应用

2019年10月26日，第二届NCTS中国云测试行业峰会在京召开，此次峰会以“AI+未来”为主题，汇聚来自国内外测试领域的知名专家学者、领先企业决策者、高层技术管理者、媒体从业者等，共同探讨高端云测试技术，帮助测试从业者了解最前沿行业趋势，及最新的行业实践。

会上，网易传媒测试总监张涛做《网易新闻DevOps实践及在AI测试中的应用》主题演讲。张涛分享了网易新闻在最近一年里在DevOps方面的实践，并指出，“DevOps落地的过程也是一个提升测试价值的过程，从关注服务可用性到关注系统的可测性和稳定性，在研发、测试和运维全流程中发挥中枢作用。”

以下为张涛演讲实录：

我给大家分享一下最近一年网易新闻在DevOps方面所做的实践和落地，希望能给大家一些好的思路。正式分享之前，先简单的做一个自我介绍，我目前在网易新闻负责整个测试的质量保障工作，来网易新闻之前，在百度做了大概七、八年，主要负责手百质量保障的工作。在手百工作期间，我就已经在做很多关于CICD，DevOps方面的实践。近两年，一些大公司都在做各种各样的DevOps尝试和落地，希望能够打通串联，研发、运维，以及测试的环节，更好的提升迭代的效率。今天我重点结合网易新闻实践的经验，以及之前在手百期间积累的经验，给大家做一个分享。

首先是通过DevOps提升迭代效率的思路和方法。第二，在DevOps这个范畴里，如何突出测试的价值。前面这两个部分是讲落地实践的过程中如何提升测试的价值，我会把价值的提升稍微讲一下。第三，机器学习测试及DevOps，今年我们在这部分做了着重尝试，关于如何落地DevOps，尤其是机器学习相关的部分。上午我也听了一下艾老师的分享，他讲了AI测试上的思路和方法，其中有一部分内容跟我所讲的有类似的点，比如关于算法、模型、特征，怎么来测。当然，艾老师的分享重点还是偏重在测试的方法上，我们的重点在测试基础上，把DevOps和机器学习的测试效率做了更好的提升。

先来看第一部分，常规的迭代效率提升。常规的测试方法，在大的版本迭代上有几种方式，先是收集需求，然后去排期，研发测试，到最终版本的发布，是一个比较长的周期。如何把这个迭代变得更高效？近一两年我们的业务迭代速度越来越快，不管对于研发还是测试，压力都越来越大。如何将需求快速的交付，快速的上线，尤其是在研发、提测之后，到测试的阶段，其实是压力最大的阶段，如何提升测试在迭代过程中的效率，尽量避免测试的瓶颈问题，也是我们一直在探索的方向。

想提升迭代的效率有很多基础性的工作，我们之前在基础的工作上做了很多长期的建设，比如基础的自动化工作，基础的CI工作，只要完成这些基础自动化能力的积累，才可能提升整个迭代的效率。传统版本的迭代通常来说类似于火车模式，集中需求的收集、评审，集中的研发，集中的测试，类似于我们常规讲的模型，这就是整个版本迭代的模式。这里最大的问题是整个需求都特别集中，迭代过程中如果有任何需求的变更，需求的插入，都很难及时响应。另外，产品的交付周期也会特别长。

还有一个很大的问题就是研发的环节，长期很多功能同步在开发，在最后的环节会非常容易出问题，而且整个代码的末值非常耗时。这是火车模式明显的问题，如何优化该模式，是我们一直在探索的问题。之前在手百，一直在尝试从火车模式走到班车模式，班车模式改变了集中需求收集和集中的研发测试的方法，有新的需求随时去提交，随时去评审，随时做研发和测试。当然，这个随时也不是每天都有，也是在一个相对固定的周期里面，比如一周做一次需求的收集和发布，每周有一定需求的提测和测试交付，这需要根据业务的复杂度，业务团队的构成情况来评定到底设定什么样的周期比较合理。

我们在手百做了很多测试，通常传统的方式是一个月到一个半月一个版本，开始做火车模式的时候做得比较激进一些，想变成两周，涉及到的团队规模都很大，两周的模式，尤其是对于QA的模式挑战是非常大的。因为每次发布都要做回归，灰度发布，验证过程，对QA的消耗是非常大的。为了应对这个模式，专门成立了一个发布测试小组，这个小组常规的功能测试就不去参与了，就集中在每周发布测试的工作上。这需要投入很大的人力，而且是独立的人来做，成本非常高。后来也做了一些调整，网易新闻也是固定三周一个迭代的模式。

评估时间样周期是否合理，通常会看几个维度的数据，一是整个研发的交付周期，从需求发布后，到进入开发的环节，在这个固定的时间段之内，评估一个月的时间。如果这一个月的时间有两个版本，或者说有1.5个版本，再评估固定时间段之内研发产出是什么，真正投入在研发上的人时是什么，因为研发除了版本迭代投入外，还有很多其它的工作，比如需求评审，Bug修复，真正研发投入在需求开发工作中占了多少，这是我们需要评估的一个维度。另外一个维度是真正产出的方面，在一个固定的时间段内需求交付的数量，当然不能单看数量，因为需求的大小不同，耗时也有不同，通常来说，评估的都是耗时，一个需求耗的研发人力、测试人力，评估固定周期内产出多大量的需求。

在模式切换过程中，通常会遇到很多的问题，很多我们所依赖的工具、环境，都是非常割裂的。割裂就会导致无法提效，这样的问题会让很好的想法做起来很痛苦，这是我们之前业务的形态，各个环节都是割裂、分散的，需求管理有独立的平台，研发代码的管理，分支的管理也是独立的一套平台，上线配制通常是运维独立管理的一套东西，测试自动化的平台、工具都是测试的团队来负责的。各个平台又都各自维护，各自管理，在整个迭代过程中很难非常流畅的打通，这个问题非常影响整体效率的提升。

我们怎么做这个工作？业界也有先行的经验，之前百度内部就做了一套类似的平台，在阿里、腾讯，几个大厂都有类似的平台，研发效能提效的平台，比如阿里的云效平台，腾讯的TAP平台。在网易，我们是联合着项目管理的团队一起来做了OverMind平台，其最大的作用就是从需求到研发，到上线，到测试，把各个环节常规所需要用到的一些平台和工具都串联打通。比如需求的管理，研发所使用的分支管理工具，以及测试的工具，上线的平台，都进行串联打通。我们测试也都把iTestin提供的自动化的能力集成到了我们整个的流程里面。

我侧重说一下测试的部分，包括客户端的测试，后台的测试，推荐的测试，我们都各自有几个平台来支撑测试的工作，以及效率的提升。这里涉及到的客户端的自动化部分，网易内部有一个易测的平台，现在也在用iTestin做客户端UI功能的自动化。关于后台的自动化，网易做了一个叫“GoAPI”的平台，统一管理后台所有接口自动化case，实行统一运行。以前大家写接口，写case各自管理，各自维护，不太统一，写case的规范也不统一。通过这个平台统一管理后，包括后台的性能测试也都在统一的平台，测试的环节通过几个平台串联起来，把自动化的能力全都运营起来，这是测试每个阶段所做的工作。

我们现在基于平台的能力，把TDD的效果做了一个比较好的实施和落地，突破了以前做测试开发方面的局限。TDD能不能做好，最最核心的一个点就在接口契约上，有了GoAPI平台，可以统一规范接口的契约，研发现在每写一个接口，都需要在该平台上定义接口的所有参数及每个参数的取值范围。因为有了接口契约，实现了在真正写代码之前写自动化的case，这是最本质的变化，借此，整个测试的效率也有了明显的提升，大概估算了一下，接口功能测试的环节大概能节省三分之一的人力。

还有一个环节在测试过程中遇到的非常多，而且是非常头疼的问题，就是环境管理建设。大家做测试时都是每人建一个环境，建环境的脚本、方法，也都是各不相同，这个成本又比较高，研发每次更新代码的时都要修改大环境脚本，环境搭建耗时且整个配制都很繁琐，一个人只能用自己的环境，别人想用你的环境还要来找你，你再帮他去搭一个环境，这是非常耗时和麻烦的过程。而基于OverMind平台管理环境，实现了自动化的环境搭建，将整个环境创建的过程实现一键式自动化。当然，这非常依赖研发的配合，因为很多环境的搭建，一些参数，尤其是环境里面配制的工作，跟研发的代码是非常相关的，我们要和研发配合做很多很多的联动和修改，基本上每个业务模块都要跟研发一起去改配制，才能实现最终的自动化。

这是实现环境自动化之后的效果，一个业务模块变更了，只需要更新这一个业务模块的环境。我们有一个集成回归的环境，在整个大的环境里面，如果有服务调用，就可以去调回归环境另外依赖的服务。如果两个业务模块都有变更，需要调变更的模块，就需要通过回归的环境把另外一个依赖环境的代码同步过来。我们在OverMind平台上实现了环境的管理，每一个模块环境的部署情况，都可以在这里直观的展示。最终，环境搭建的整体效率提升了240倍，以前搭一个环境需要几个小时，两三个小时是常规的情况，如果遇到非常复杂的业务，这个过程可能需要小半天。我们现在有了这样一套在OverMind上做环境管理的工具之后，环境基本上分分钟就搭起来了。另外，环境的数量也提升了非常多，以前只能有自己的一套环境，现在随时想用哪个环境都可以快速的去搭建了。

另外，我们把CI的整个环节在OverMind平台里做了打通，通过该平台做CI的触发和功能的调用，在流水线里把所有自动化的能力集成起来。除了代码的CI之外，还有一个需求的CI，都能够在我们平台里有一个非常直观的展现。

前面所讲的这些部分重点还是关注在测试的可测性上，从大的DevOps范畴来讲，重点关注在测试左移，也就是说如何从测试自身的范畴里往研发，往需求的方向做更多的扩展，更多关注的是可测性和需求的合理性。除了刚才提到的自动化工具，平台工具之外，另外要做的一些工作，比如说单测，以及Code Review的工作，我们在日常工作中也会做一些投入，这要求我们和研发、产品，有非常密切的配合。

前面讲的是从需求起源开始，到研发，到测试，如何提升迭代的效率。下面的部分是说产品，或者是版本发布之后，如何做更多的质量保障，这部分更关注服务的稳定性。在服务的稳定性上，关注几个方面，一是服务的稳定性；第二是全链路的监控，更多的是把客户端、服务端，整个监控打通串联起来；第三，故障预防和演练方面的一些工作，切实发现系统里面隐藏的风险。

前面讲到提升测试的价值，在测试的左移方向上如何从需求到研发，到测试，这个方面来提升效率。在测试右移的部分，更多的是关注测试的稳定性和测试的风险预防方面，这方面QA可以发挥的作用也是非常多的，是重点需要协作的团队，一方面是研发，另外和运维协作得也比较多。

分别讲一下两个方面的工作，一是全链路的监控，我们已经做了有一段时间，全链路监控概念的方面，大家都有了基本的了解，如何梳理服务的依赖关系，做链路的追踪，把整个请求的链路串联起来。另外还有链路调用的性能，每一个请求的性能是怎样的，能够快速的发现性能上的一些瓶颈，这是全链路监控整体的思路。核心是做链路的监控，最核心的是要有一个监控的ID，比如在网易新闻里面刷新一次，或者点了某一条新闻，点击的操作就会有一个请求，在这个客户端给服务端发请求的时候，要自动生成ID，一直带到服务端，服务端再把ID一直带到最终请求的服务最终的节点上。服务端的调用涉及比较多调用的层级，每个调用层级又有一个核心的点，就是SpanID。它能够记录一个服务到另外一个服务请求的关系，最终整个全链路的调用过程会生成一个记录，这样就可以在追查问题的时候，根据一个请求快速查找到最终调了哪些服务，中间在哪里出问题了，这是全链路监控的思路。

故障演练核心关注两个层面，一个是服务依赖，如何把强依赖转成弱依赖。第二是把无损降级转成有损降级。可以看到右侧的两个图，比如网易新闻里面最常用的发帖，发评论，我们以前是第一个调用的方式，后来把依赖的关系都隔离了，转成右侧调用的关系，把一个强依赖转成了弱依赖。比如后台的服务，跟贴排行榜出问题了，但不会影响发帖的过程。故障演练更多关注的一个故障类型有几类，一是硬件层面的问题，另外是中间件方面关注得比较多，比如数据库的问题，缓存的问题，另外就是服务依赖，有自身的内部服务依赖，还有调用第三方的服务会有一些依赖。自身应用部分，重点关注现成的一些情况，这是常规关注的故障类型。

故障演练的方法主要是有几个方面，一是要有数据的积累，数据积累后如何定义故障的规则以及故障注入，相当于是故障的case，和写常规的case是类似的，最终是怎么做结果的校验，看有没有逾期的报警。现在故障演练也都逐步做平台化，做平台化需要很多基础的积累，需要数据和规则，如果没有，也很难实现平台化。目前做了一段时间，发现了几方面的典型问题，一是数据库方面，数据库和缓存这两类的问题都比较多。另外一方面是服务依赖的问题，就是刚才提到的有自身服务的依赖，还有第三方服务的依赖，还有是硬件方面的问题。

第三部分说我们的一些测试方法，以及结合DevOps提升效率。机器学习的测试，其实和常规的工程测试有类似的地方。在线工程和我们的常规后台测试方法是比较类似的，但是有一部分模型训练的部分，和常规的测试方法不太一样。艾老师在这部分也介绍了挺多，测试基础的覆盖方面我就不详细讲了。我们在线服务的测试，重点是关注在服务的稳定性上，模型这部分的测试重点是关注在特征模型准确性上。我们常规的测试范畴，包括特征的一致性，是我们关注比较多的。如何验证特征的一致性，其实是一个非常复杂，庞大的工作，之前在手百工作时，我们在这方面做了非常大的投入，网易新闻这部分也做了一段时间。另外，模型训练的部分，最主要的是如何验证模型的有效性以及合理性，这是比较难的一个部分，首先要去了解、理解模型是如何实现的，还要找到一套适当的方法来评估这个模型的合理性。另外是预估部分，要看正确性以及分布的情况。

这里可以简单看一下我们模型训练的整个流程，从线上所有的用户日志行为开始，我们拿到这些日志之后，做数据的处理，特征的计算，然后做模型的训练，以及在线的预估，这是整个模型训练的流程。在这个流程里面，最核心的两个部分，当然日志的收集和数据处理部分还是跟常规做业务测试，做后台服务，测试的方法是类似的，最主要的差别还是在特征和模型部分。特征的有效性以及模型的有效性，如何验证？这其实是最核心的。另外，我们如何配合研发，把这部分的工作能够做得更有效率一些。

之前遇到很大的一个问题，一个模型从训练到上线，耗时是非常长的，长的时候要一周，如果到传统行业里面，一个新的模型上线要经历更长的时间，半个月，甚至一个月的时间，如何提升模型训练的效率，这其实也是我们和研发配合做的一个机器学习的服务平台。这里面所做的核心工作，是把研发日常线下所做的很多工作，比如需要的日志，物料，所有特征的结果，以及模型训练的结果，通过这个平台直观展示出来，在这个平台上查询日志总体的分布，物料都有哪些，模型的更新情况，都可以在这个平台上快速的实现自动化。

我们做这个平台最主要的目的是把特征训练和模型训练方面的工作做平台化和服务化，也是结合着前面做迭代效率提升的方式是类似的，通过OverMind平台把整个客户端和服务后台的测试都实现平台化和服务化。当然，机器学习的研发测试和产品介入的比较少，类似于需求管理部分相对不会涉及太多。

这是我们的一个效果，在平台上把整个特征工程的训练结果，以及所有配制修改上线，全都服务化了，这里能列出来当前在使用的特征都有哪些，这些特征的状态是不是在线上，是什么时候上线的，如果有问题，需要在这里做一些配制，修改，然后再重新做上线的操作，一次性的都可以自动化的完成了。模型的部分也是，模型的实验和上线也是类似的方式，我们把整个模型训练的效果，以及它所依赖的一些特征，特征的关联关系，都在这里展示出来，在平台上可以做配制的修改和上线。辅助研发，把整个模型的训练效果和周期做一个有效的提升。

这就是今天分享的内容，谢谢。