知物由学 | 易盾SaaS系统资损防控体系建设

背景

易盾业务主要分内容安全、业务安全和移动安全三部分，内容安全主要给客户提供反垃圾机器检测能力，文本、图片和音视频。并和人工审核、SAAS审核系统组合成全家桶。业务安全主要是提供认证类的服务，包括验证码，号码日志，信息认证。移动安全是通过加固和其他手段保护客户的应用，防止被逆向破解。

结算业务是易盾最重要的基础服务，承担着易盾的资金管理工作，随着易盾用户量的高速增长，结算业务承担的责任越重，风险也越大。自然而然，对于我们测试同学也提出更高的要求。在我们搭建这套体系前，回归手段比较传统，自动化用例维护成本较高，覆盖不够全面。也没有完备的线上监控，缺乏自我发现的能力，有较大的资损风险，并且故障发生到发现的时间很长，导致故障的影响面扩大，用户的信任度降低。

1.1、结算流程介绍

以反垃圾的结算流程为例：

首先图片、文本、音频和视频等业务服务检测完成以后会通过各自的storage模块将检测量或者审核量发送给kafka，bill-collect模块收到消息后会根据业务配置以及套餐信息计算并写入到redis，随后统计任务会将上个时间段存在redis的数据持久化入库，最终由多个结算任务对前一天持久化的数据进行结算。任何一个环节出问题都会影响最终的结算结果。

1.2、痛点分析

结算的痛点一直是团队心病，内部沟通过后将痛点总结为以下三点：

下面我们会针对这三个问题各个击破。

测试工具改进

2.1、痛点分析

上面大致介绍了一下结算的流程，整个流程涉及到多个的模块、中间件以及定时任务。对日常的测试以及回归造成了不小的困扰。首当其冲的就是影响测试进度，正常的测试流程一般是今天我先发一批数据，然后算一下大概要扣多少钱，明天来对一下扣费是否符合预期。如果测试过程中发现了一个代码Bug，反馈给开发改完。再发一波数据，后天再来对一下。一个需求测试测试周期被拉得比较长。碰到多个结算相关的需求凑在一起测试，环境又只有一套，可能出现你发完数据以后，第二天来发现测试分支被发走了，那么昨天的数据相当于白发了。整个测试效率都非常低。

2.2、改进方案

需求测试效率低的根因是链路长和结算数据复杂度，因此我们的解决方案是构造不同阶段、不同时间段的数据。并且将任务触发和数据构造功能集成到一起，大大节约了测试所需时间。

2.3、功能展示

回归方案优化

3.1、历史手段

原有的回归方案是全链路的回归方案的，在gotest上面创建两个执行集，一个每天定时往某个产品发送指定量的文本、图片、视频和音频等数据，另外一个是校验结果执行集，根据指定发送的量计算一个预估值，定时去校验前一天的计费数据是否符合预估值。经过一段时间的验证以后发现这种方案很不稳定，执行集经常报警。原因是这种全流程验证的手段不灵活，数据多发或者少发一条都会导致实际结果不符合预估值，再者测试环境用的人比较多，任意一个依赖的模块挂掉都会影响最终的结果。并且由于业务增值服务配置项特别多，传统的方案每次新增用例也要在配置上花很多时间。

3.2、改进方案

因为构造数据的工具是现成的了，我们的回归方案能不能基于现成的功能去做。通过实践证明这个方案是可行的，通过结算工具直接构造结算数据，新的回归方案只对结算模块进行验证，可能有同学有疑问？你的回归方案只保障了结算模块的逻辑，如何保障全链路没有问题呢。我这里先卖个关子，我们后面再讲。

3.3、功能展示

线上监控建设

4.1、线上问题分析

工欲善其事必先利其器，想要解决问题，就需要先分析问题，团队内部首先将近三年结算相关的线上问题捞出来，然后根据这些问题产生的原因，将问题进行分类，根据是否存在资损风险大致分为两类，有资损风险的和没资损风险的。然后再将有资损风险的进行细分类，一共分为三种：数据统计、套餐结算、配置转换。我们的目标就先覆盖这三类问题。

4.2、线上案例举例

4.2.1、案例一

问题现象：文档解决方案结算数据偏多

问题原因：经排查发现是因为kafka数据重复消费导致的，kafka client每次会批量拉取max-poll-records的数据下来处理，如果在max.poll.interval.ms时间内未处理完，kafka会认为client挂了并移除掉，然后触发reblance，这时候如果超时的client未提交offset，则可能导致数据重复消费

4.2.2、案例二

问题现象：新增音频检测场景计费偏多

问题原因：结算代码对新增的音频场景计算错误，应该是按照分钟去计算（数据量/60 * 单价），实际上是按次去计算（数据量*单价）。导致计算结果偏大。

4.3、线上监控设计目标

4.4、方案设计

通过历史bug的回溯，我们总结出了绝大部分问题产生的原因，那么基于此，我们设计了一套全流程对账的方案，方案的核心在于：

1、独立维护一套业务配置映射计费系数

2、使用和结算流程不一样的数据源

3、设计一套类似的结算方法

通过这种方法就能保证，这个三个地方任何一个点出问题，最后的结果都会有差异，从而起到监控的作用

4.5、优化迭代

最初设计的方案肯定是不完美的，覆盖的场景有限并且计算结果和真实的结果有一定误差，因此需要不断去优化，如何去优化呢？目前我们的迭代方案是 添加更多的产品监控->找出有误差的产品->分析误差的原因->优化误差，误差的原因和我们的方案设计一样，分为三种，分别是配置问题、算法问题和数据源问题。

以我们已经解决过的几个问题为例：

1、配置问题：原始的方案是添加监控的时候读一次配置，后来配置发送变化没有同步，导致最终结果对不上。优化接入业务jar包，监听配置变更，配置持久化入库。

2、算法优化

3、数据源优化：图片检测gif图时，是根据真实检测数去计费，这个检测数没有存到业务方的数据库，真实计费用的这个检测数，导致数据源查出来的数据偏小，已经提需求给开发同学优化。

总结

对以上内容进行一个总结：

1、测试工具提效：
支持各种阶段数据构造
定时同步最新计费场景
提供对外API供其他业务部门调用
2、回归任务优化：
只对结算模块进行回归
通过代码覆盖率评估回归用例完备性
3、线上监控系统建设：
每日对客户结算数据就行对账
支持历史数据回溯
异常客户报警

收益以及产出

线上对账系统上线一个季度后累计发现两个线上BUG，一个故障。
【线上监控报警】结算归档数据结算出错
【线上BUG】包量套餐超量扣费场景归档数据计算不对
【故障】点播音视频数据漏结算问题复盘

测试工具以及回归用例提效明显
手工测试效率
2d->4h
自动化用例新增&维护成本
4h->0.5h

未来规划

未来的规划主要分为三个方向

横向扩展：接入更多子服务（目前接入子服务：反垃圾、反外挂、验证码）
纵向扩展：目前线上监控做的内容是针对我们的客户进行对账，同时我们有很多服务接入的外部供应商，这个部分目前是缺少监控的，也会造成资损问题。后续也会将供应商的监控纳入范围。
降噪，减少误报