当前位置:网站首页 > 黑客培训 > 正文

易盾SaaS系统资损防控体系建设

freebuffreebuf 2021-12-27 592 0

本文来源:wangyiyunyidun

背景

易盾业务主要分内容安全、业务安全和移动安全三部分,内容安全主要给客户提供反垃圾机器检测能力,文本、图片和音视频。并和人工审核、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

未来规划

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

横向扩展:接入更多子服务(目前接入子服务:反垃圾、反外挂、验证码)

纵向扩展:目前线上监控做的内容是针对我们的客户进行对账,同时我们有很多服务接入的外部供应商,这个部分目前是缺少监控的,也会造成资损问题。后续也会将供应商的监控纳入范围。

降噪,减少误报。

转载请注明来自网盾网络安全培训,本文标题:《易盾SaaS系统资损防控体系建设》

标签:内容安全业务安全

关于我

欢迎关注微信公众号

关于我们

网络安全培训,黑客培训,渗透培训,ctf,攻防

标签列表