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

	背景 易盾业务主要分内容安全、业务安全和移动安全三部分，内容安全主要给客户提供反垃圾机器检测能力 文本 图片和音视频。并和人工审核、SAAS审核系统组合成全家桶。业务安全主要是提供认证类的服务包括验证码 号码日志 信息认证。移动安全是通过加固和其他手段保护客户的应用 防止被逆向破解。 结算业务是易盾最重要的基础服务，承担着易盾的资金管理工作，随着易盾用户量的高速增长 结算业务承担的 责任越重风险也越大。自然而然，对于我们测试同学也提出更高的要求。在我们搭建这套体系前 回归手段比较 传统 自动化用例维护成本较高，覆盖不够全面。也没有完备的线上监控 缺乏自我发现的能力 有较大的资损风 险并且故障发生到发现的时间很长，导致故障的影响面扩大用户的信任度降低。 1.1、结算流程介绍 以反垃圾的结算流程为例： 首先图片、文本、音频和视频等业务服务检测完成以后会通过各自的storage模块将检测量或者审核量发送给 kafkabill-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 未来规划 未来的规划主要分为三个方向 横向扩展：接入更多子服务（目前接入子服务：反垃圾、反外挂、验证码） 纵向扩展：目前线上监控做的内容是针对我们的客户进行对账 同时我们有很多服务接入的外部供应商 这个部分目前是缺少监控的，也会造成资损问题。后续也会将供应商的监控纳入范围。 降噪，减少误报。