测试右移实践的一些总结思考—稳定监控“及时雨”

随着项目开发的逐渐敏捷化，QA的职能早已不单单是曾经简单对功能的测试，在领域内测试左移和测试右移这两个概念被一再提及。

本文将分别从稳定发布、监控、风险控制三个方面，主要介绍一下目前测试右移概念在组内的落地应用、一些还没有落地的构想以及有意向采取的行动。

随着项目开发的逐渐敏捷化，QA的职能早已不单单是曾经简单对功能的测试，在领域内测试左移和测试右移这两个概念被一再提及。实践了左移和右移的QA团队，在项目组内往往能够获得更大的主动权，产品的质量也更加有保障。虽然项目本身可能更多采用敏捷的迭代增量型或适应型的开发模型，但是就具体功能而言，实际落地还是更多采用偏瀑布的预测型生命周期。测试左移和右移的基础概念便是在原本测试应有的阶段的左右延伸。

测试左移与测试右移

左移和右移实际上是两个挺大的领域，展开来其实都有挺多可讲的。对于右移而言，笔者个人的定义更多是采取措施稳定线上生态、主动控制、发现并规避问题。笔者所在的天谕测试组是我认为在右移方面做得很不错的团队，我们有非常多的工具在线上问题的预警上发挥了不小的作用。但正巧最近产品出现了几个刷类事故，有未测试充分导致的回档问题，也有线上潜伏了数年但是一直未被发现导致被利用损失惨重的问题，也让我有机会对右移在项目组内的实践重新产生了一些思考。

01、稳定发布

稳定发布，类似灰度发布的概念，当新内容/新引擎上线时，先小范围测试，再在全服覆盖的做法。在功能层面，采取开关的形式，在每段功能逻辑入口增加开关判断后续逻辑是否能走到，这样可以在上线新功能时先小范围测试，稳定后再修改全服的开关状态；在引擎层面，客户端方面采取的是同一个客户端同时存在两套或多套exe，每次启动时根据配置的概率有低概率启动更新的偏不稳定的exe；概率文件可以在每次启动登录器时随时无感更新。服务端则是在引擎更新后，在小范围服务器优先发布，观察数周稳定后再推广至全服。

02、监控

1.LOG监控

LOG是玩家行为最直观的记录体现，也是我们分析线上问题、进行数据统计等行为的最基础数据来源。作为QA掌握项目LOG的主动权是很有必要的。

据我所知，有些项目的LOG主要由UX或其他第三方部门处理，策划需要时提出需求，由平台方进行处理后生成报表。相对而言，天谕端游对玩家行为LOG建立了一套相对完善的体系，这边先对我们的工具做一个简单介绍。

首先我们建立了LOG的基础展示页面即数据中心，将存储进mongo db的日志数据以字段详细内容的形式展现出来，可以对几乎每一条敏感操作做非常详细的记录和操作较为简单的可视化查询，即使是不懂得使用SQL的非技术岗也能够从这个平台获取到信息，对平时的运维工作提供了很大的便利。

LOG数据中心界面

但是这种平台化的展示更多是针对微观的具体的数据，当想获取宏观的数据如统计类信息时，单纯的数据罗列会显得有些无力。

于是我们引入了第三方伏羲的数源平台，也就是针对技术岗人群可以直接对LOG进行SQL查询及脚本处理的平台。伏羲数源是在处理跨越时间较长、条件较明确的一次性需求时常用的平台。天谕的大部分LOG数据目前都寄存在伏羲的这个平台上，只要明确要查询的字段和条件，只需要简单的SQL语句便可以获得我们想要的结果。虽然从可视化的角度不及上面的工具，但是依然具有高度自由、门槛较低、查询范围较广等优点。

在此基础上，我们希望对SQL的结果能进行一些更复杂的脚本化处理，于是有了线上日志监控系统。该系统在获取db数据的同时还可以使用python脚本对数据进行个性化的处理，并且支持定时任务。这个平台是我们当前LOG自动化的基础，我们可以在写完针对某个系统的针对性监控脚本以后，让它定时执行并通过POPO（内部IM）机器人推送检查结果，确认这个周期内的数据是否存在异常，例如每两小时一次的洗属性的监控，就可以从洗炼次数（是否有异常突增）、洗出结果等多个层次供QA和策划确认是否可能存在异常。但是目前的缺陷在于这个平台的运行会消耗大量服务器资源，因此对CPU时间存在要求，很难处理大批量数据，目前而言支持的项目有限。理想有效的LOG监控体系，应该符合以下的模型：

LOG监控模型

测试部目前应该正在调研开发更通用的log监控平台，届时各个项目应该都会有更加深入的支持。

对于QA而言，在有便捷工具的情况下，需要做的就是确保LOG的实用性。一般而言，LOG需求通常由策划和QA发起，策划会关注核心的参与数据，而QA的角度应该更加微观，需要关注到更细节的操作层面。符合有效性的LOG，我最常用的自检标准是，如果功能上线以后，有玩家反馈自己在这个玩法里丢了道具，你能否通过这个系统及关联系统的LOG整理去详实的数据去证实/证伪他的言论。在这个证明流程中，需要时间、人物、状态、操作、关键项变化前后状态等，这些都是各个系统LOG的基本组成要素。

这边还有另一个问题，例如战斗结算，产生的LOG量可能相当巨大，基于现实原因，我们可能没法记录下每次伤害的结算信息，那么当玩家反馈“某玩家的伤害/防御有异常，他们是不是利用了BUG？”，如果没有足够的信息量，我们进行判断时往往会陷入被动。所以这边我们引入了重要度分级的概念。以我前面提到的战斗结算LOG为例，对于一般玩家，我们每过一段时间记录一次玩家属性快照到数据库中，包括玩家在这个时间点身上的所有状态、所有属性。对于玩家反馈或者是系统监测到可能存在异常的玩家，这个频率可以在线实时提高。对于重点监测的玩家，在提高频率的同时，还会为其设置技能结算白名单，在各类结算方法处判断参与结算的玩家是否在白名单中，如果在的话便记录下本次技能结算的详细数据到LOG中以供查询。白名单可以随时调整。通过这样的方法，既保证了LOG数据量不会过大，又能做到精准监控。

2.舆论监控

舆论监控主要分为两块，一块是被动的由运营提交问题，一块是主动去各个渠道发现问题。

在运营提交问题愈发频繁的今天，如何处理运营问题本身也是一个问题。早期在运营BUG反馈群，运营可能在一个小时机关枪一样连续抛出十几个问题，其中有效的问题可能并不多，但是过多的问题会导致回应效率变低；早期我们曾做过一个运维BUG反馈平台，希望运维bug都提在这个平台上，我们方便处理和及时反馈。

但是在实践的过程中，运营迭代速度过快但流程没传承、大量外包运营无登陆权限、运营自己的网络访问限制等客观因素实际上阻碍了这个平台的有效性。

因此我们把POPO机器人和运营反馈BUG流程打通，运营提交BUG时增加一个关键词，我们就自动把提交内容收录到BUG反馈平台中，在处理完成后，由BUG反馈平台推送处理结果给运营，整个过程运营只需要接触POPO而无需接触其他平台，QA们有专门的平台处理线上问题，更加有条理性。

但是运维反馈bug依然存在一些问题，由于运营方面的多方位因素，对于拿不准的问题他们逐渐更偏向直接询问开发组，bug提交量近几年量级逐渐增加，除了提问类工单比例逐渐上升外，还有很多伪bug是玩家在诓客服想获取利益的；其中有些假bug往往处理起来需要耗费挺大的人力，有时候也挺为此头疼的……不过这倒是反向推动了不少系统log结构的完善，一方面足够完善、可读性强的LOG可以让运营人员自行筛选并解答玩家问题，另一方面也可以帮助我们拿到更多的事实依据，判别哪些问题是真实存在的BUG，避免后续人力的浪费。

至于另一方面，主动发现问题，曾经我们的习惯是版本发布后，由值班QA定期去贴吧、论坛、微博等渠道扫玩家言论，发现BUG或吐槽后给策划或技术开单处理。随着平台化的进步，现在的舆论监控主要由两部分组成，一部分是对游戏内的敏感言论做捕捉，另一部分是雷火渠道信息收集平台，主要用于监控各大平台（论坛、贴吧、taptap）的反馈，根据标题贴近BUG的程度计算风险系数并录入。

雷火渠道信息收集平台

虽然舆情监控的的确确帮我们发现了不少隐藏BUG及疑难BUG复现的线索，但是在运营过程中可以发现，绝大部分少数人利用的危害比较大的BUG一般都不会通过游戏内渠道或公开渠道进行传播，很多都是通过公会QQ/微信群或YY群进行小范围传播，并且这种套路逐渐常态化，因此项目组内有人可以深入游戏生态，打入玩家内部依然是很重要的工作，当然最根本的还是完善面向数据的主动防御机制。

3.性能监控

即便有压测等环节，线上也经常会出现各种性能方面问题的意外情况。深度参与性能监控的流程和体系，有助于QA更深入了解系统瓶颈，对后续测试的思路拓宽和厘清侧重点帮助是很大的。

我们游戏对线上性能的监控需求改进动力来源于群战及各类复杂的PVP玩法或其他玩法。早期这类活动出现过不少性能问题，并且当时的性能监控比较被动，一般是当服务器负载高于某个阈值时，在服务端抛错群里抛出警告，然后由服务端手动连入线上服后台进行profile确认问题，这种做法往往响应较慢，容易错过关键时机，且只能由高权限服务端手动操作，生成的报告比较晦涩，整体参与度和实用性都不强。

现在线上的性能监控则主要通过SA那边维护的两套工具postman及monitor进行，postman以可视化的形式展现了线上服在各个时间段的服务端性能数据，并且可以就某一个具体的时段具体分析profile，让QA也能参与到线上性能的监控里来，并且能更方便地在生产环境找到性能瓶颈。Monitor则直观展现了各服的CPU、内存等基础性能状态。可以看到这两套工具都具有高度可视化的特征，在收到出现问题的推送时能够更快地确认问题。

线上的性能监控工具

这里再提一个例子，天谕端游前不久出过这样一个情况，部分服一直反应服务器一到某个时间点就很卡，邮件响应速度慢，或者读取角色速度慢等。但是我们调取了这些服的性能数据与其他服比较，发现并无明显异常，在玩家反馈的时间点监控服务端各个进程的CPU占用率，发现也非常稳定，mysql慢查询日志中也只有每天的计费扫描，并不会导致线上这种情况的产生。最后在引擎日志中，发现很多玩家的SQL队列非常长，有些队列已经排到了70多秒；我们从日志平台调取了玩家的操作序列，在这个服和其他服进行对比，发现相同的单次操作，在这个服写入需要1s，在其他服只需要0.1s，于是定位可能是硬盘写入性能问题。联系SA后得知其在近期的确更换了服务器的硬盘，后排查是SSD raid存在问题导致了写入卡顿，第二天更换硬盘后服务器状态即恢复正常。

这次事件后，我们注意到性能监控的指标事实上还存在不少缺失，例如这次dbmgr还存在不少性能相关的指标目前对我们QA甚至对开发而言还依然处于黑盒的状态，我们只能通过watcher的方式查看的数据，过于被动。针对这次问题，除了常规的服务端监控手段外，我们还额外增加了对dbmgr的监控，把sql运行超过一定时间的日志抓取出来并通过POPO报警，后续已经规划通过kibana等平台做成图表，以更直观的形式表现出来。

由于标准不一，设备各异，客户端的线上性能监控目前我们没有采取什么手段，更多的还是在内部机器上进行测试。也希望有这方面实践的项目组可以交流一下经验。

其实挺多的线上性能监控，看似是服务端或者是SA的问题，QA在处理起来可能会有比较无力的感觉，但性能问题的最终指向是线上功能及玩家体验受损，这与QA的职责是强相关的，QA除了具体分析问题原因外，能做的事情还有很多，包括但不限于前期预警方案的设计，监控系统有效性的保证，上线后的执行，出问题后的行为与场景分析等。

03、风险控制

纵使监控做得再完备，第三方检查发现问题也总会存在延时。例如天谕端游在20年底出现的一起刷道具导致的回档事故，19：00问题出现，日志监控并未对这个活动写单独脚本，就算写了也是跟着统一配置半小时执行一次；舆论监控最早在19:20暴露问题，在此之前问题已经得到了大范围传播。因此如何控制风险、规避风险依然是重要的课题。

从游戏机制设计层面，老QA可能都知道几条耳熟能详的原则，比如：

1、多人玩法注意负载均衡，时间上分批、空间上分地

2、道具获取先扣除后增加、先设标记位后发奖

3、低门槛非绑道具谨慎投放，如果必须投放一定考虑工作室影响

4、活动投放道具尽量用宝箱道具，宝箱配置限定使用次数

……

类似的规则相信有经验的项目组都已经有挺多总结，遵守这些守则的确可以规避很多问题。但事实上根据实际的复杂情况，很多事故的产生并不是几条通用的守则可以覆盖的。因此要寻找更加通用的控制机制。

一种我认为比较可行并且在逐渐推广的是预测型控制机制，即当系统产生了策划配置的预期外的数值时，由游戏逻辑直接采取报警或切断措施。

举个例子，在天谕端游已经上线的系统内，副本首杀监测、数值结算异常监测便是报警类的风控机制。当新服某个副本第一次通关时，会收到报警信息；当玩家结算时发现某个属性过高或者打出了离谱的伤害时，服务端也会推送报警信息；当玩家在某个场景内保持无敌状态超过一定时间后，推送报警信息……

另一步正打算做的机制是根据物品投放的系统来限制投放总量。策划对每个运营活动或新玩法在一个周期内针对每个基础产出道具限定一个警告数目和预期最高上限，当玩家在这个周期内通过此渠道获得的这个道具超出配置的报警数目后，向功能关联人员推送报警信息，超出最高上限后则直接拦截，并生成一个道具恢复指令供运营核实无误后快速恢复拦截的道具。

从可行性层面上，对于MMORPG类游戏而言，玩家获得物品投放的渠道最终都会归结于进包、发邮件等有限的渠道，所以控制起来相对轻松，具有一定的可行性；目前这个方案还在实现初期，如何协调玩家获得道具记录在不同周期需求下的存储方式和程序的运行效率还是一个问题，不过预期内这个系统能实现的话应该会是一个很好的防御手段，像本文开头所讲的两个BUG的例子也可以在这个系统下得到规避。

在这次事件的复盘会上，以及后续测试部的月会上，很多人都提到了一个其他游戏的做法，即把多刷出来的资源扣成负数，后续玩家获得这些道具时将其补充。这个做法的确是处理起来挺有效的做法，但是依然存在一些问题：无追责的贷款可能会降低玩家的活动参与意愿，如果玩家已经通过这个玩法获得了既有的数值收益，那么后续仅仅是扣除这部分数值奖励对他的惩罚也无足轻重了；不过这种业界常用的做法依然具有挺广阔的适用场景，已经在项目内推广使用了。

04、结语

右移的最终目标，是希望技术层比业务层更快地获得异常反馈，以达到极速响应处理问题的效果；或是从业务实践层面出发反推开发层面，预先解决掉导致问题出现的种子。右移的实践除了表现在形式上的环节中QA自己的行动外，在内涵上更重要的是思维和氛围的营造，这部分的内容更多地会穿插在功能的设计期和开发期。质量保障从来不只是QA的工作，我们要做的是把保障质量的观念灌输到其他职能的脑海中，让他们主动来配合我们，让策划在设计时就有意识考虑到风险和备案，让技术更加注重代码上线后的各个维度的表现。有效右移体系的建设需要QA能够给出有说服力的架构体系思路或系统设计思维方式，且能够与项目的实际情况融合，这同时也可以帮助QA在组内构建更大的话语权和推动力，反推组内产品质量意识的提高。

当然，目前项目组的实践依然存在很多不足，希望能够与各位一起讨论交流，分享经验。

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！