链路级资损防控之资损字段防控实践|得物技术
一、背景
资损防控是业务稳定性保障的重要一环,资损防控的核心主要有三点:事前规避、事中发现和事后应急。在资损事前规避方面,商家业务从业务场景入手,进行各业务模块的资损场景的梳理,将最容易出现资损的场景梳理出来。但是这些资损场景的梳理是依赖人去梳理,非常依赖梳理者的个人经验和对业务、链路、系统架构的熟悉程度,这样的梳理方式一定会存在资损场景被遗漏的情况。我们希望能够在人为梳理的基础之上增加系统自动识别能力来对资损场景进行补齐。
因此,希望通过分析测试环境数据库写操作涉及的字段和数据,得到所有字段后,通过AI大模型判断字段是否存在资损风险的方式进行预标记,研发测试进行二次打标并和已有资损场景、资损字段结合,形成业务域资损字段,进而结合公司资损管理平台,精准测试平台能力建立一套基于资损字段->资损方法->调用接口->资损场景->资损布防->布防演练为一体的链路级资损防控方案,提升整体资损场景覆盖度,降低资损风险。
二、应用实践
资损字段梳理
人工梳理
资损字段的梳理主要通过两种方式,一种是通过判断业务数据库字段的数据错误是否会涉及到资损风险,对商家业务所有数据库字段进行资损风险的梳理,梳理主要参考以下几个维度:
-
一致性风险:信息、资金流不一致,信息实物流不一致,资金实物流不一致
-
计费类风险:
-
计算因子错误
-
应记未记:上游少传元数据
-
产出错误:下游产出,加工的计费因子,数据错误导致计费异常
-
传递错误:传递过程中计费因子传递,解析等错误导致计费异常
-
-
计算逻辑错误
-
计费相关配置错误导致计费错误
-
计费算法逻辑错误导致计费错误
-
系统&业务层面的逻辑错误导致应计费未计
-
-
-
营销风险:
-
权益配置类:发放规则、对象、次数、金额、有效时间配置错误
-
权益发放类:发放人群不符合、发放权益类型不符合、发放次数超限、发放数量超限或不足、发放金额超限或不足、发放时间不符合
-
权益核销类:核销金额和发放金额不一致,核销场景和发放场景不一致,核销时状态非法、已失效、取消,权益不在有效核销期,核销次数超限,如优惠券多次核销
-
AI识别
通过分析测试环境数据库写操作涉及的字段和数据,得到所有字段后,通过AI大模型判断字段是否存在资损风险的方式进行预标记,具体流程如下:
针对AI识别出来的资损字段,结合人工梳理的资损字段,在平台上进行最终的打标确认,形成明确的资损字段。
覆盖策略
被梳理出来的每一个资损字段,都可以当做是一个原子的资损场景,针对梳理出来的资损字段的覆盖,当前主要通过核对规则中对资损字段的核对来进行覆盖,因为核对规则的实现需要花费很大的精力进行规则编写和脚本编写,要实现资损字段的全量覆盖几乎是不可能的。资损字段梳理出来,如果没有对应的防控覆盖,就会有较大的风险敞口,因此需要有快速且低成本的方式对资损字段进行覆盖,结合精准测试平台已实现的链路推荐能力,可以从资损字段推荐资损方法、资损接口,通过对资损接口进行自动化覆盖,实现对资损字段的覆盖,形成资损字段识别-资损接口梳理-资损场景达标的闭环,降低线上资损风险。
资损链路推导
借助精准测试平台能力,解析代码中资损字段对应的MyBatis文件找到对应代码模型,自动生成模型字段对应的get/set方法,并为get/set方法设置资损注解,之后使用资损字段生成的get/set方法结合方法调用链推荐资损接口,平台具体的方案图如下:
- 建立DB资损字段与代码模型字段关系映射
- 推荐出对应的资损字段
- 推荐出对应的资损接口
通过精准测试平台进行资损链路推荐,识别出全部资损字段对应的资损方法和资损接口。
资损链路覆盖
识别出某个业务域资损链路之后,针对涉及资损每个应用,识别出来对应的资损链路接口,进行100%补齐,数据格式可以参考如下:
资损用例专用计划
在每个应用进行资损链路推荐时,推荐出来的资损接口对应的资损用例会自动添加到资损用例测试计划中,形成业务域的资损用例测试计划。
资损用例测试计划执行
结合集成流水线,资损用例专用计划集成到冒烟阶段集成流水线。
在每次冒烟阶段流水线执行时,自动执行资损用例测试计划。
在资损用例执行失败时,需要对失败case进行排查定位,最终要是整个测试计划的通过率达到100%。
资损用例发现问题
- 在546迭代中,通过资损用例的执行结果排查,发现4+个资损相关缺陷。
- 在547迭代中,通过资损用例的执行结果排查,发现1+个资损相关缺陷。
三、实践成果
通过链路级资损防控,最终实现了以下的收益:
-
从数据库字段出发,串联资损字段->资损方法->调用接口->资损场景,形成一体化的资损链路大图,针对每个链路可度量、可防控,进行更精细化的资损防控建设。
-
通过资损链路的推导,对梳理出来的资损字段进行了近100%的覆盖,形成了线下资损场景的全量覆盖,使得每次代码变更都可在线下进行资损防控,提前规避线上资损风险。
-
对比资损场景梳理的资损方法、资损接口,通过资损字段推导出来的资损方法、资损接口有非常明显的提升。其中,资损方法增加了1200+%,资损接口增加了400+%,使得业务全域的资损场景更全面,形成了可复用的精细化资损防控体系。
四、未来计划
通过资损字段识别,能够快速的进行资损场景的扩展,帮助业务进行资损场景的查漏补缺,而结合资损字段,依然有很多防控场景可以思考和实践。
-
结合资损字段,以字段规则覆盖(资损需求规则覆盖率)+字段调用链路接口自动化覆盖(资损链路覆盖率)双重覆盖方式形成资损覆盖的有效度量模型。
-
对资损链路,进行对应的自动化case覆盖率,自动化case成功率,代码行覆盖率统计等相关的质量强化。
-
资损接口代码自动进行打标存档,在需求开发、技术优化时,帮助业务进行资损场景提前识别,降低资损需求判断的经验依赖。
-
针对迭代需求,如果需求变更涉及到资损链路,可以对需求进行资损需求打标,进行资损需求的开发SOP管理。
-
绘制公司资损链路大图,进行全流程资损场景识别、资损链路覆盖、资损覆盖度量。
*文/ 刘湛
本文属得物技术原创,更多精彩文章请看:得物技术
未经得物技术许可严禁转载,否则依法追究法律责任!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
58HBase云原生探索与实践
一、背景介绍 58大数据团队在计算方面的在离线混部项目已经取得了很好的效果,后续规划将大数据组件与云技术进行逐步的融合,同时在过去几年,58大数据团队已经实施了很多高效的降本增效策略(数据EC、高效压缩、治理优化等等),也取得了不错的成果,2024上半年考虑结合云技术对HBase集群进行云化改造,进一步降低业务成本,减少运营维护成本。 1.1 HBase云化背景 在58的业务场景中,HBase扮演重要角色。例如帖子信息、用户信息等公司基础信息会定期离线同步到HBase中,为各个业务线提供随机查询及更深层次的数据分析。同时各个业务线可以将自己的数据存储在HBase中进行批量查询,可用于用户画像、趋势分析、推荐业务、搜索业务、时序数据存储等场景。整体架构如下图所示: 随着业务不断的增多,HBase集群在长期的运营过程中,发现了很多问题,主要有 1.)业务类型多样,但是整体规格统一, 无法最大化利用资源, 资源浪费。 2.)业务集群较多,业务分组混乱,维护和管控复杂, 运营成本高,扩展性差。 3.)集群升级版本迭代比较麻烦,涉及到环节较多, 迭代和维护成本高。 结合以上问题,考虑可通过云化部...
- 下一篇
遇到 MySQL 死锁问题如何解决?
终于来到死锁检查线程的第三步,可以解决死锁了。 > 作者:操盛春,爱可生技术专家,公众号『一树一溪』作者,专注于研究 MySQL 和 OceanBase 源码。 > >爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 > 本文基于 MySQL 8.0.32 源码,存储引擎为 InnoDB。 1. 选择死锁受害事务 前面介绍了死锁线程做的准备工作,以及发现死锁的过程。现在,是时候解决死锁了。 解决死锁最重要的事情,就是决定回滚死锁环中哪个事务,也就是选择哪个事务作为死锁受害事务。 选择死锁受害事务之前,还要做一件比较重要的小事,就是按照死锁环中各事务进入锁等待状态的时间从先到后进行排序。排序之后的事务,会存放到一个数组里,我们称之为死锁数组。 之所以要这么做,是为了根据其它条件无法选出哪个事务作为死锁受害事务的情况下,选择最晚进入锁等待状态的事务作为死锁受害事务。 给死锁环中各事务排序之后,就可以基于死锁数组来选择死锁受害事务了。 这个过程当然又要遍历死锁数组了,同样,每次取死锁数组中的一个事务。 第 1 轮循环有点特殊,直接把取到的事...
相关文章
文章评论
共有0条评论来说两句吧...