前言
为什么要做异常场景自动化监控?
怎么做?
做这件事情的意义!
前言
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异常数据接入异常平台目前正在接入过程中。
![图片](https://eyangzhen.com/wp-content/themes/justnews/themer/assets/images/lazy.png)
做这件事情的意义!
(1)在回收和零售整体商品的流转上,提升了流转效率,减少库存积压;
(2)在人工成本上,虽然接入bcp需要耗费一些时间在梳理校验规则上,但在梳理的过程中,QA也更加了解功能的具体逻辑,在对业务的了解上,也更上一层楼;由于接入bcp的规则中已经梳理出校验异常点,在收到异常报警反馈给开发的时候,可以将问题大致的原因一起反馈,从而减少开发重新排查定位问题的时间;
(3)在发现异常上,可以及时发现隐含技术问题,及时防御,减少损失。
综上,门店通过抽离异常场景接入bcp系统可以获取正向收益。后续QA也会继续和开发一起抽离可接入场景,做到异常数据尽早发现,及时分析,尽快解决,建立起坚固的异常防御墙。
声明:文中观点不代表本站立场。本文传送门:https://eyangzhen.com/419305.html