背景
易盾业务主要分内容安全、业务安全和移动安全三部分,内容安全主要给客户提供反垃圾机器检测能力,文本、图片和音视频。并和人工审核、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系统资损防控体系建设》
- 上一篇: 谁动了我的打印机?
- 下一篇: 内网穿透实例练习:setoolKit+花生壳 >钓鱼网站