从防范到防御异常场景处理机制终于闭环了

• 前言
• 为什么要做异常场景自动化监控？
• 怎么做？
• 做这件事情的意义!

前言

QA在异常场景的处理上，之前更多地侧重于防范，通过风险评估、异常测试等手段降低异常发生的概率。异常场景数据的自动化监控更多地侧重于防御，在异常发生时，可以迅速响应、及时处理减少损失。在异常处理机制中二者缺一不可，相互协同形成闭环。本篇文章以门店异常数据自动化监控机制为例，重点聊下异常防御方面正在做的一些事情及意义。

为什么要做异常场景自动化监控？

QA在日常中的事情大概包括需求评审过程中提出遗漏点，技术评审时指出开发设计方案的不合理点，多与开发产品沟通评估回归范围，在测试过程中确保测试场景覆盖面，多考虑异常情况等。在做到以上事情以外，可能还是会在一定程度上不可避免地漏掉一些场景，那么我们如何在上线完成后及时发现这些漏掉的问题呢？门店目前已有的问题发现形式主要有以下几种方式：

（1）店员反馈给运营，运营排查完后再反馈给产品，最终由产品反馈给技术，技术进行问题排查并解决；

（2）线上online问题反馈；

（3）开发业务报警代码，企业微信群中发业务报警；

（4）异常日志治理；

但以上发现问题的方式大多会经历比较长的时间，对于涉及到钱款的问题，比如券和红包的发放，如果在线上持续时间较长就会造成比较大的损失；而对于商品状态未正常流转的问题，也会导致商品售出时效变低，影响售卖。而且在收到反馈问题后，开发进行排查，分析问题原因，再进行修复，也是比较耗时的。甚至有时在收到问题反馈时，已经无法查到当时的日志，无法定位原因。综上所述，异常数据自动化监控就发挥了作用，能否及时发现线上异常数据，是非常重要的。

怎么做？

在及时发现问题这个痛点上门店是怎么做的呢？我们主要是通过接入中台的bcp系统来解决此痛点的。首先简单介绍一下bcp系统的能力，bcp系统是基于MQ消息内容，与业务代码解耦的方式进行业务校验，只要能够发出MQ消息，就能够做到业务校验，目前支持监听数据库变更的Binlog及业务的mq。

目前的校验规则包括aviator规则引擎开发模式和java规则引擎开发模式。

对于校验规则简单，且执行校验规则不依赖第三方数据源的场景，可以采用aviator规则引擎开发模式进行规则配置。

java规则引擎开发模式中校验规则编写需要继承AbstractJavaRuleExecuteEngine 实现 when(条件过滤)和then(业务数据校验)两个方法。当when方法返回true的时候，才执行then方法(业务数据校验逻辑)。

门店校验回收单取件状态一致性规则举例如下：

when中内容

从map中拿到 消息体中的内容，获取到变更前的状态，变更后的状态，ordersource进行简单的为空判断、值的判断

then中的内容

建立数据源链接

编写sql语句，执行sql语句，对查询结果进行校验

具体接入场景

接入之前，梳理总结出门店容易出现问题的场景如下：

（1）多场景并发导致的商品状态不对问题，商品状态不正确，无法正常销售、调拨等

（2）零售系统发放以旧换优券用户领券异常，系统无感知；

（3）回收单门店侧发货状态与中台侧状态不一致，无法正常发货；

（4）回收系统用户多领取回收加价券或多使用券，系统无感知；

（5）回收单状态卡单，实际商品已丢失或者是被盗，系统无感知；

（6）门店侧存的零售商品价格与商品侧存的价格不一致，导致店员和用户看到的商品价格不一致。

目前门店已接入场景校验规则20个，其中回收7个，零售11个，基建2个。

场景校验中主要采用了以下方式

（1）监听业务mq消息，采用aviator规则引擎开发模式，定义过滤规则条件及数据校验内容，无需编写校验逻辑代码；

（2）监听业务mq消息，编写校验逻辑代码，调用rpc接口查询数据并校验；

（3）监听数据库表变更的Binlog，经过配置的延时时间后，再次查询数据库表，查看进货单或者调拨单对应的商品状态是否发生变更；

在接入的这段时间内，共发现卡单数据671条，零售：6条，回收：664条。其中零售侧的6条异常数据，包括同售状态卡单的场景3个，调拨单返回库存与scp库存不一致场景1个，多个表中状态不一致场景1个，门店零售价格和商品侧零售价格不一致1个。

其中同售状态卡单的主要原因为并发场景，开发已纳入后续并发场景优化的规划中；

商品价格不一致的原因为门店发起调价，门店侧调价成功，商品在B2C卖场处于下单未支付状态，不支持门店发起调价，导致商品侧调价失败，最终门店零售价格和商品侧零售价格不一致；

回收侧的异常数据，主要是状态卡单，之前曾采用过每周将所有数据直接同步运营，经反馈，在每周反馈运营时，有些回收单状态已经流转，数据准确性不高，因此我们每周在给梳理反馈之前，先手动去转转交易工具箱查询回收单状态是否已流转，完成一层过滤再反馈给运营，保证数据准确性。经过一段时间的实行，后续逐步和运营沟通得知他们对于卡在60状态之前的回收单，是每周完成闭环处理，卡在60状态以后的回收单，是每个月跟进处理。了解后我们对于卡单数据做了不同状态的划分，便于运营同学处理跟进。

更进一步考虑，由于目前是手动统计过滤卡单数据，对于QA来说手动过滤会占用较多时间，考虑有没有一种更快速便捷的方式，释放QA，最终确定将bcp发出的异常报警按照不同的规则配置统计时间，自动化统计过滤，异常数据发给运营后，运营处理完成后将状态置为已解决，完成卡单数据记录的闭环，处理机制逐步完善。完善跟进回收卡单数据的过程如下图所示。bcp异常数据接入异常平台目前正在接入过程中。

做这件事情的意义!

（1）在回收和零售整体商品的流转上，提升了流转效率，减少库存积压；

（2）在人工成本上，虽然接入bcp需要耗费一些时间在梳理校验规则上，但在梳理的过程中，QA也更加了解功能的具体逻辑，在对业务的了解上，也更上一层楼；由于接入bcp的规则中已经梳理出校验异常点，在收到异常报警反馈给开发的时候，可以将问题大致的原因一起反馈，从而减少开发重新排查定位问题的时间；

（3）在发现异常上，可以及时发现隐含技术问题，及时防御，减少损失。

综上，门店通过抽离异常场景接入bcp系统可以获取正向收益。后续QA也会继续和开发一起抽离可接入场景，做到异常数据尽早发现，及时分析，尽快解决，建立起坚固的异常防御墙。

术话题。

作者：陈秀婷

关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于测试），更多干货实践，欢迎交流分享~