标签：dev 多公司 超时 重要 制作人 数值 数据采集 部分 这一
APM时代的质量保障之路：腾讯互娱品质管理部性能负责人访谈导读：11 月 23 ~ 24 日，GIAC 全球互联网架构大会将于上海举行。GIAC 是高可用架构技术社区推出的面向架构师、技术负责人及高端技术从业人员的技术架构大会。今年的 GIAC 已经有微软，腾讯、阿里巴巴、蚂蚁金服，华为，科大讯飞、新浪微博、京东、七牛、美团点评、饿了么，才云，格灵深瞳，Databricks，等公司专家出席。本周购买可享门票88折优惠，高可用架构会员低至6折。
在大会前夕，高可用架构采访了2017年 GIAC质量保证分论坛 出品人何纯，就目大家广泛关注的质量保证方面的问题进行了访谈。
何纯,腾讯互娱品质管理部性能负责人,腾讯TDR专家，参与制定腾讯手游发布标准，聚焦移动游戏在性能问题上的定位和调优。主导开发性能分析工具（UPA）及APM手游客户端性能管理工具。负责参与《王者荣耀》《穿越火线：枪战王者》《魂斗罗：归来》《火影忍者手游》及战术竞技类手游等多款战略级产品的性能优化，在客户端性能领域积累了丰富的经验。
高可用架构：现在性能问题是非常火热的问题，因为性能直接影响到用户体验，很多相关从业者也在各种会议上强调自己解决的是真实的用户体验问题，那么从您所从事的游戏行业来说，您觉得怎么定义真实的用户体验？根据你的经验来说，现在的手机游戏性能问题通常在哪里？
何纯：以我所处的游戏行业举例，性能问题主要是体现在画面的抖动和卡顿上，还有用户操作的响应时间，这其实是我们平时所说的比较广义上的性能问题。针对从技术层面我们关注的是以上几个方面的数据，但是转化到用户的感知，用户在游戏的时候手的操作和用户眼球的感知，其实并不会反应在数字上。比如说我们平时说内存很高、CPU很高或者是网络延迟很大，但是转化到产品的功能上，对于用户来说，他并不知道你的CPU有多高，用户看到的可能是一个画面的抖动，或者是网络延迟造成的响应的超时，或者是整个APP直接闪退，这是用户直接从眼睛可以看到的影响，我觉得这才是真实的用户体验。
在性能监测上，游戏主要是看画面的帧率，玩家在操作的画面不是标准的操作系统画面，它既不是安卓的界面也不是苹果的界面，而是通过游戏引擎把它画出来的，所以画面的抖动和画面帧率的变化，对玩家感受的影响是很大的。还有一些特殊的点是说在游戏类的监测上，我们要给用户一个选择的空间，就是让用户选择他的核心场景。因为很多游戏，假如说你在登陆阶段或者是游戏大厅当中，虽然说出现画面抖动、网络延迟也会影响用户体验，但是对用户来说并没有太大影响，就是加载时间长一点而已，但是一旦进入到地图之后，在玩的时候就不应该发生任何性能的问题。
高可用架构：您之前在做性能测试工具，现在在做APM工具，谈谈对于研发这两种不同的工具，您有哪些感悟？
何纯：性能测试工具面向的是测试人员和开发人员，测试工具其实可以拿到的性能数据更多、更深、更全，并且测试工具对APP本身有一定的性能影响，这都没有问题，因为这是研发阶段才用的。说到APM，性能的监测、采集、分析，这是面向C端的，它是直接集成在产品当中对外发布的。所以说监测的时候，它对APP本身的性能影响一定要降到最低才行。并且在不同的国家，可能还会存在一些用户敏感数据的限制，所以说目前我们有一些业务出海的时候，也会碰到欧盟GDPR协议的限制，会在数据采集的层面做一些取舍。广义上来说，现在的监测是为了更好的改善用户体验。
高可用架构：提到收集数据，APM和产品经理常用的数据后台的数据来源有很大的统一性，那么是否可以考虑把两者的数据源合二为一？如果可以，需要注意哪些方面？如果不行，原因是什么？
何纯：可以，需要把数据类型和数据定义标准都对齐。当然，两者对数据的隐私性要求可能有区别。本文提到的所有性能数据的“监测”及“采集”，腾讯互娱都有一套严密的监管流程，在不涉及用户隐私的前提下，通过这些性能数据助力研发的质量提升，呈现更好的产品品质及用户体验。
高可用架构：您演讲当中提到了性能检测的闭环，有四个环节，包括验证对比、实时监测、性能预警、问题定位。腾讯作为一个「大厂」，非常注重体系化的建设，能不能分别说说为什么选取了这四个维度？
何纯：首先我们说第一个维度是验证、对比。性能采集、分析、监测的最终目标是为了改善用户体验，也就是说在版本迭代过程中能够尽快的发现问题并且修复问题。一旦修复了问题，新版本上线之后是一定要做一个前后的对比。
第二个环节是实时监测，所谓的“实时”是说我们在后台做大数据计算的时候，尽可能把计算频率缩小到一定范围，比如说1分钟、5分钟。目前我们的计算频率延迟是最大5分钟，当用户在任意的时间点打开我们的APM产品页面，他看到的数据都是最新的，都是当前已经计算好的。
第三个环节是性能预警。我们目前在做的是一个工具类的平台产品，从工具的角度来说，有一个原则就是“用完即走”，我们希望工具不要消耗开发同学太多的时间。因为像我们这种平台类的研发工具，它的本质是提高我们的工作效率，如果说我们每天花大量时间来看这个页面去看数据的话，其实并没有提高我的效率。所以当项目团队一旦认可我们这个产品功能的时候，他就不会每天到我们的页面上来看，他希望我们能够通过一些告警的方法，帮助他们自动筛选并发现问题来，其实就是为了节省他们的时间。
最后一个环节是问题定位。我们需要在有限的环境和条件下，尽可能把问题缩小到某个范围当中，比如说我们平时会提到，你这个游戏的画面帧率是多少，可能是每秒25帧或者23帧，假如说突然某一个时间点出现了问题，帧率降到很低，这个时候我们需要进一步找到一些可优化的点，缩小问题的范围。这个时候我们需要针对具体某个小的场景，或者是某个手机的型号，甚至是安卓或者是苹果的版本号等等。所以说在问题定位上，我们把数据分析做的很细，分了很多维度，并且在多个维度之间做交叉的对比，这样一来，我们分析的数据可以能够精确到游戏的版本与游戏的场景，也会精确到玩家的机型，甚至是加上性能出现问题的时间段。关于时间段这个概念，我在演讲中也讲到了，有很多第三方的原因导致了游戏性能问题，这是游戏项目团队可能并不清楚的。比如说第三方的组件突然有一个线上的更新，或者手机厂商进行操作系统的版本更新，这个时候是项目开发团队可能不会提前知情，这就需要我们监测时间段，在我们的工作中确实通过这些问题定位的方法，帮助项目团队发现了很多问题。
高可用架构：目前很多公司采取了微服务的架构，微服务的规模和动态性对数据收集的成本也有一些提高，并且服务拆分一定程度上对端到端的监测会产生一些影响，您怎么看待这些问题？
何纯：在我的理解来看，微服务的本质是把后台很多大的服务拆分成很多小的环节，每个环节之间降低耦合性，提高服务之间的独立性。这样一来，让每一个小功能的团队规模更小，在小功能的开发上能够更加快速，更加高效，更加独立，更加有自主权。随之带来的问题是从用户体验来说，当我发起一个服务请求的时候，产生整个链路上的环节会非常多。目前我们WeTest的APM服务的重点是客户端的监测，服务端的监测是我们下一阶段的重点。服务端的监测业界其实也有成熟的方案，Google的工程团队在一篇论文当中讲解了他们的大规模分布式系统的监测系统Dapper，它是针对全链路消耗时间的分析，这套方案比较成熟的应用在一些网页端的产品上。比如说用户在网页上提交了一个购买商品的请求，这个请求从我点击按钮到后台响应，这个请求消耗的总时间会分为很多个节点，这样可以很快发现这一次请求中间的耗时在哪个服务的耗时是最长的。所以在我看来，微服务架构可以更加便利去做一些性能的分析和定位，假设在实施微服务架构之前，无论是出现后台响应超时，还是服务器发生了哪些问题，可能需要后台团队耗费更多的人力去排查问题。但是如果说有了现在这样一个按节点来计算消耗时间的分析的工具，我们很快就会知道哪一个节点出了问题，这个时候我只需要通知到那个小团队就好了，不需要团队中不相干的人停掉手上的工作来做这个分析。
高可用架构：WeTest应用性能监测研发经历了哪些阶段，未来有什么计划？
何纯：第一个阶段的重点是我们要做一个SDK，这个SDK本身对客户端性能的影响是要非常低的。游戏和大家常用的APP在SDK这件事情上还是有很大不同的，常用的APP也有APM的SDK，但是对性能影响的要求不一定很高，因为常用APP操作是低频率操作，举例来说一些IM软件，我们大部分时间只是打字聊天并不会进行复杂的操作，所以即使SDK对性能有一些消耗，用户也感觉不到。但是如果是玩游戏的话，玩家的眼睛和精神是高度集中的，手的操作频率也是很高的。这个时候SDK本身对游戏性能的影响是要几乎降到零才行，这是第一阶段的难点。
第二阶段的难点是后台的高并发，特别是在国内，一些爆款游戏的高并发、用户量非常大，活跃用户数量动辄达到几千万，反而在海外会简单一些，海外大部分游戏全球产品的日活数量还比不上国内一个产品的日活数量。
第三阶段的难点是后台的数据分析。数据分析既要有数据分析的专业知识又要懂游戏本身。目前在我看来，我们的数据分析做得还不够，虽然说我们现在已经能够帮助项目团队发现很多问题，但是数据分析的深度还不够，很多数据其实还是可以交叉起来的，做更深的交叉分析。
未来计划方面，我们也是回去做全链路监测，我们会基于上文提到的Dapper的思路去把全链路分析应用到游戏上。这个里面涉及到游戏后台服务器的架构调整，目前我们正在跟腾讯自研团队做尝试，就是在做游戏后台系统的微服务。当全链路建设完成之后，我们每个节点的消耗时间都可以把它统计下来，假如说一天有一百万个请求同时发生，在这一百万个请求当中我们知道当中有一万个请求消耗时间是超出了我们的标准值，然后我们再看这一万个请求当中，大部分的问题是出现在哪一个节点，这样一来其实很快就可以把后台的响应时间做一个修复和优化的工作。
高可用架构：您刚才的回答中提到了高并发，APM针对高并发做了哪些优化？对于1.2亿DAU的产品线来说，数据清洗是如何实现的？
何纯：APM的高并发其实和传统的APP后台服务器都一样，高并发在同一个时间点采集的数据量非常大，并且我们不能让数据丢失，基于游戏业务的特性，我们是全量采集的。处理高并发在APM这边的特点是说，我们一个客户端完成了一局对战之后，我们会以单个文件的形式采集，文件传上来之后，对后台的高并发处理应该是将文件接收。传统APP的高并发只是一个请求，一个请求的数据量是很小的，可能只有几个字节。我们现在后台平均文件大小大概是100k左右，大的话可能有300k，所以接收一个文件并且把它保存下来，再把文件当中的数据解析出来，分别存到不同的数据表里，然后再把文件删掉。这是我们高并发的特点。
高可用架构：您提到的全采集是把所有指标都采集吗？我们知道数据采集的性能通常和采样率紧密相关，如果采样率高那么性能通常会受影响，如果采样率低，那么一些极端情况可能容易错过。WeTest APM采样率是怎样确定下来，以达到高性能和尽可能多的采集数据？
何纯：是的，所有指标都采集，后台进行取舍，这样更加灵活；我们APM是采集每帧渲染的时间，把数据写入到一个固定的cache memory，cache写满时转存到文件，用了磁盘缓冲技术进行写入操作，把性能影响降到最低。
高可用架构：您的演讲当中也提到了机器学习和深度学习在您做的产品中的应用，那么机器学习和深度学习究竟是怎么应用的，应用在哪些场景？
何纯：在APM这边，机器学习主要是用于两个方面。
第一个是告警系统的学习，在这个项目上我们的深度学习有一定的进展。在演讲分享时我提到告警邮件的打开率现在是75%，最早的时候可能只有30%。一开始告警可能一天会出现好几次，大家看多了会有一些审美疲劳，可能就不愿意打开了。后来我们做了收敛，就是说同一个类型或者说同一个级别，或者是之前连续两周或者是三周发现的问题，已经出现的问题我们就不会做告警。另外是基于人工去做一些有监督学习，例如我们在告警系统当中会有两个按钮：确认、否定。通过按钮的点击再基于当时告警系统当中的数据数值做一些深度学习的尝试。目前告警邮件的打开率已经提高到75%，我们的目标是提升到90%。告警的准确率现在已经有90%了，在深度学习或者是说在提升告警准确率的过程当中，我们团队自己也会在单个项目上去验证。比如说有款战术竞技类手游项目，它每天产生的告警内容我们都会人工的一个个去确认，因为你必须要人工确认才能把深度学习的这条路走下去。告警系统完全是无监督式的学习很难，因为大部分的性能问题是偏主观的，它跟崩溃、闪退不一样，但是性能问题比如有人觉得这个画面有点卡，有人就觉得不卡。每个人的容忍程度和主观的因素有很大关系在里面，所以我们还是在这块去做有监督学习。
另外一个是我们正在努力但还没有很好的效果的项目，简单来说就是我们需要将各种监测数据糅合成一个分数，可以把这个分数理解成游戏的「性能健康度」，这个分数的准确性和有效性是需要通过深度学习去做的，因为这个分数的背后其实是需要有一个计算公式，有一套算法，我们要通过深度学习去强化这个计算公式，提高公式的准确性和有效性，甚至是它的合理性我们也要把它提高。在这个项目上，我们已经开始尝试，期望未来有进展后可以和大家分享。
总结一下，在APM这边的深度学习主要是用于告警系统的强化以及未来综合评分的强化上。
高可用架构：您提到APM采用了AI告警准确率有90%以上，也就是还是会有一些误判，一般出现误判会怎么处理？怎么通过技术手段持续优化减少误判？
何纯：重点项目的告警、我们都会人工逐个确认，通过人工干预的方式，让AI进行监督式学习；谷歌最近在微信朋友圈发布的你画我猜小程序，其实也属于监督式学习的一种。
高可用架构：支撑腾讯代理和自研的80多款热门游戏，APM压力应该不小，在全量采集的情况下，你们用来支撑这套APM的存储集群和应用集群目前是什么样的规模？后端架构有没有出现过压力大、不稳定的情况？怎么解决？
何纯：对于一些实时性比较高的数据，我们还是用mysql来存储；实时性要求不高的数据用hadoop存储、并进行离线计算；随着业务量的增长和产品自身的需求，后端架构先后进行了三次调整优化，因为我们是以“单局”单位来采集的，所以QQ飞车这类“单局”数量多的项目会产生较大的压力，大地图项目反而压力不是那么大；解决方案包括接收端动态扩容、大项目进行独立存储、实时性要求不高的数据采用离线计算等。
高可用架构：采访中提到的在数据分析这块，咱们收集上来的数据最终如何进行分析、对比和展示的？实时？还是离线？你们一般重点关注哪些维度的数据？
何纯：数据分成实时和离线两类，大部分是用hadoop离线计算，小部分是实时计算；从用户体验来说，重点关注的还是帧率、卡顿、延迟；
高可用架构：对于全引擎兼容来说，C2DX,U3D,UNREAL这三大引擎如何进行全部覆盖？在适配的过程中碰到什么有趣的问题？
何纯：其实就是三个版本的SDK包，c++版本、unity版本、unreal版本；适配测试也是最基本的流程之一，每次更新版本时都会在wetest top300 机型上跑一遍，确保主流机型都没问题。
高可用架构：作为一款工具类产品，在内部推进起来应该并不容易，可能不同的业务线或者工作室都有自己的工具、自己的「轮子」，在这部分您有没有什么经验可以分享，可以让做工具的同学学习？
何纯：首先在大公司内部确实是会有「重复造轮子」的情况出现，这对我们做工具的同学确实是一个有点棘手的情况，这里边最重要的是要改变一下思路，把自己正在做的工具当成一个to B的产品去推广和运营。在腾讯自研的项目里，取决于每个项目团队对问题监测和问题修复的重视程度，确实有团队会做APM的工作，会做一些数据采集。但是项目团队只是把数据采集到后台，并没有做交叉分析，没有做很详细的、多维度的组合分析，而且这种工具他们也没有很友好的产品页面，开发团队可能是根据开发需要想看的时候从数据库里拿一些数据出来看。分析到开发团队这两个痛点，其实这就是工具团队可以努力的方向。也有了机会去做APM。比较有意思的是，其实我是后来才知道APM这个名词的，我在做这个系统的时候，其实就是想做一个全套的、让腾讯所有项目都能够用起来的监测系统。后来逐渐的才知道这个在国际上的叫法叫APM。
说到APM产品，它本身是一个To B的应用，一开始确实会很难做，但是一旦做进去之后，你建立的壁垒就会比较高。比如说前面提到的性能测试工具，一个公司内部可能有好几套类似的系统，项目组可以用我的，也可以用你的，甚至用他的。因为测试工具本身对产品运营阶段没有任何影响，但是APM这个SDK，只要接入并且表现稳定，项目组不会轻易替换。
另外，在To B领域你得学会和不同团队产生一些交集和合作的方式。假如说你知道了另外一个团队也想做APM的SDK，那么你要想他的目的是什么？他的最终目的应该不是为了做一个SDK而做一个SDK，最终目的应该是项目团队想拿到一些数据，去发现和定位他们的问题。知道他们的真实目的，我们就可以把数据开放接口给他们，就相当于SaaS服务。这个相当于一个生态合作或者是团队之间的合作，开放共赢。这可能会打消很多团队「造轮子」的念头。
高可用架构：再谈一点关个人成长这一块的。您去年的时候还是做性能测试这一块的，今年转做APM，其实我们觉得这个可能从技术路线的角度比测试要高一块的，因为在性能管理上可能需要更大的全局观。未来在移动互联网时代，性能也是很重要的话题，您觉得对于一些测试工程师，或者说正在做性能或者说以后可能会往性能管理这方面走的工程人员来说，他们更应该在个人成长上关注哪些问题？或者说您个人成长当中有什么好的经验？
何纯：先说说背景，腾讯的手机游戏是2013年开始的，2013年开始做《天天酷跑》，后来做卡牌类，再后来做RPG，直到现在做MOBA，从这个趋势来看，重度游戏会逐渐搬到手机上。从目前来看，很多游戏的运营策略是长线运营，希望单个产品能够有稳定、长线的运营收入。这会要求对产品各方面的要求特别是体验上的要求会越来越高，所以说从大背景来看，性能的监测优化、持续迭代是一个刚需。
个人发展来说，原来做测试工具，只覆盖到研发期的一些团队，如果你做了一个线上的实时的APM系统，你就可以把你的用户群体扩大，扩大到开发团队甚至是策划团队，甚至是项目的制作人、总监这种更高层面的人，扩大你自己在团队中的影响力。除了个人技术提升以外，作为技术人的全局观也会有很大的提升。原来做测试工具，你只是看到单个项目单次测试的结果是怎么样的，但是我现在可以看到一个项目的大盘数据，并且能够看到所有项目的数据，所有项目数据出来之后我可以做品类细分，可以按照游戏类型细分成MOBA类、赛车类等等，细分品类的性能数据出来之后，对于将来的新的项目有一个指标意义。
这些数据出来之后，可以直观的告诉游戏开发团队，只要达到这些指标，你的游戏虽然不能说一定成功，但是在体验上绝对不会差。对新项目来说，这有很大的参考意义。
这一年时间我的感受是APM平台其实是一个桥梁，桥梁的左边是研发团队，桥梁右边是各种厂商，APM平台不仅能够帮助项目团队做优化，而且能够推动整个硬件厂商做一些通用的硬件产品的优化。因为游戏是最消耗手机软硬件资源最高的APP，很多厂商还是很看重他们手机在重度游戏上的表现。以前我记得有一款新机型发布，发布时在《王者荣耀》默认是开了最高画质的，但是其实监测下来发现性能数据并不好，就把它默认选项调整为中等画质了。因为通过长时间的数据分析，现在我们发现不同硬件组合起来的工作效率并不是加法的关系，CPU、内存、GPU甚至是一些底层的主板、芯片组，他们并不是1+1+1=3的关系，有可能是1+1+1=2.5或者是2.8这样的关系。
高可用架构：您当时说一开始想做这个东西的时候，还不知道这个东西在国际上叫APM，当时做这个东西是领导派的任务呢，还是说自下而上团队想做的？
何纯：是自下而上发动的。腾讯很多的创意、很多的工作任务都是自下而上的，领导的想法会占到30%-40%，余下部分是团队内部自上而下的发起。每一个人需要技术成长，需要有创新，腾讯也是鼓励每一个人在内部创新，鼓励每个人要有自己的想法，要有主动思考的习惯和能力。我之前做测试工具，有开发同学问过我现在的测试工具只是看测试阶段的数据，真正发布到线上后，能不能也有工具去帮们做性能的监测。所以当时我决定做这个。
今年6月份我去参加了微软在西雅图的Build大会，微软提出APM是DevOps里很重要的环节，它既能服务测试也能服务运维，当然也会服务开发。APM里面产生的大数据经过我们进行数据分析得出的结论和指标，是公司决策层非常希望看到的东西，通过这些结论和指标，工作室负责人会知道哪一个项目的用户体验或者是外网的反馈会更好。这就是我们工程团队可以通过做工具自下而上在公司内部去推动业务改进的一个很好的例子。
高可用架构：对于GIAC，有什么寄语？
何纯：作为去年质量专场的出品人，深深感受到了GIAC的现场魅力以及到场听众的积极热情，这不仅仅是纯粹的议题分享，更是行业思维的深度碰撞交流。祝GIAC办的越来越好，加油！
关于WeTest：
腾讯WeTest是由腾讯官方推出的一站式品质开放平台。十余年品质管理经验，致力于质量标准建设、产品质量提升。腾讯WeTest为移动开发者提供兼容、云真机、性能、安全、企鹅风讯等优秀研发工具，为百余行业提供解决方案，覆盖产品在研发、运营各阶段的测试需求，历经千款产品磨砺。金牌专家团队，通过5大维度，41项指标，360度保障您的产品质量。
本期 GIAC 大会上，质量保障/DevOps 部分精彩的议题如下：
参加 GIAC，盘点2018最新技术。点击“阅读原文”了解大会更多详情。
标签：dev 多公司 超时 重要 制作人 数值 数据采集 部分 这一
原文地址：https://blog.51cto.com/14977574/2546723
