随着货拉拉业务的迅猛发展,平台每时每刻都面临着黑产的攻击和挑战。为了保障业务安全和稳健地发展,风控作为抗击黑产的前线,负责各项业务的风险识别和阻断工作。同时,各类业务的接入以及风控策略的高强度迭代,也给风控的质量保障和交付效率带来了挑战。如何在保障质量的同时高效完成需求交付,是每个货拉拉风控测试人员的目标。
1. 风控需求上线的「苦难行军」
1.1 风控测试的职责
在货拉拉,测试的职责是参与需求全生命周期的质量保障工作,为产品质量保驾护航。通常情况下,测试主要保障代码变更的质量,在不引入新问题的同时,确保变更代码能合理的实现产品需求。
在 风控特征质量保障的探索和实践中,我们已经详细探讨过,货拉拉风控测试关于特征代码变更的质量保障。然而,对于风控测试,不能仅局限于代码变更的保障。由于风控系统需要灵活支持业务变更,风控需求往往只需调整配置即可实现新业务的接入和适配。然而,正是这种灵活配置的特性,使得风控识别效果高度依赖于数据质量和配置质量。如果上游调用风控的数据出现问题,或者风控配置出现错误,将导致风控系统出现误判或漏判,从而引发客户投诉、资金损失和舆情风险。
因此,为了确保风控需求的上线质量,即使在系统没有代码改动的情况下,风控测试团队仍需投入大量成本,确保风控配置的正确性和上游数据的准确性。
图:风控能力接入类需求上线,各方职责矩阵
此外,由于风控领域的专业性,在开发和测试过程中,业务开发和测试的工作经常因风控问题而受阻。风控测试团队也经常需要协助业务的开发和测试团队解决这些风控问题。
图:业务与风控测试的协作 gap
1.2 风控需求上线的质效问题
在业务系统接入风控能力的需求中,业务测试需要验证命中风控和未命中风控的业务表现;对于风控系统,则需确保业务消息能正常解析,业务数据准确且无质量问题。然而,由于风控系统的特性和风控领域的专业性,风控需求的上线过程如同「苦难行军」,即使是简单的业务接入需求,也需要投入大量的资源和成本:
业务测试难以独自构建命中风控的测试场景,需要风控测试支持
风控特征数据,源自上游原始数据的清洗和补全,上游测试难以了解风控特征补全逻辑,无法独立完成风控场景的测试。
风控系统难以保障上游数据的准确性,需要风控测试核对
风控效果依赖于风控策略的判定,而风控策略的准确性依赖于上游数据质量。由于风控系统本身不对上游数据质量进行合规性校验,需要人工进行核对。
风控产品难以独自保障配置的正确性,需要风控测试验证
风控系统处于交互链路的下游,验证风控配置需要从上游业务进行触发。
线上测试容易被风控系统误伤,需要风控测试协助
测试行为容易被风控系统误识别为黑产活动,导致账户功能受限,阻碍线上验证。
1.3 质效提升的思考与探索
在风控需求上线过程中,业务测试的诉求是确保在验证过程中,能够顺利测试命中风控的业务表现不受阻碍,上线后,正常功能验证不被风控系统阻断。风控产品的诉求是在保障数据质量的前提下,实现需求的快速上线;风控测试的诉求是保障风控数据质量,同时降低测试投入成本。
图:风控测试体系支持
在明确各方诉求后,为了在保障风控需求质量的同时降低投入成本、提高交付效率,需要解决以下问题:
风控场景构造难:提供风控场景生成工具和测试策略,支持根据唯一标识一键生成风控命中和未命中场景。提供一键式消息触发工具,摆脱对外部数据的依赖,降低配置验证成本。
数据核对成本高:在测试策略中增加数据核对规则,使得在测试风控场景时即可完成数据核对,减少人工核对成本。
线上验证易阻塞: 通过工具追踪能力,及时发现需要风控测试支持的需求。提供线上风控测试白名单和风控测试能力支持,避免验证过程被阻塞。
风控测试投入高: 优化风控需求上线流程,推行风控测试左移,使用工具替代人力,降低风控测试在风控对接需求上的投入成本。
2. 测试往前一点点,效率提升亿点点
2.1 风控场景测试的痛点
当业务请求到达风控系统后,风控系统会解析业务请求消息中的字段,并在风控决策引擎中对这些字段进行清洗和补全,转化为风控特征。最终,这些特征会被组合并进行条件判断,以匹配风控命中结果并返回给调用方。
图:风控命中的简易逻辑
因此,业务测试在验证风控场景时,常常会遇到以下问题,导致验证阻塞并产生额外的沟通协作成本:
场景测试前,业务测试不清楚会调用哪些风控接口以及命中哪些风控策略。
场景测试时,业务测试不知道如何构造能够命中风控的数据。
场景测试后,业务测试不清楚如何解除风控。
为了降低沟通成本并提升测试效率,我们开发了以下工具:
风控命中检索工具:帮助业务测试快速检索调用的风控接口和命中策略,降低测试沟通成本。
风控场景化构建工具:提高风控场景数据构建效率,简化测试过程。
2.2 风控命中检索,降低测试沟通成本
为了降低系统压力和存储成本,风控系统只会保存命中了风控策略的消息。因此,风控测试在协助业务测试定位触发风控的接口和场景时,往往需要在日志系统中进行检索和查询,这不仅效率低下,而且不直观。
考虑到测试环境的系统压力相对较小,我们可以在测试环境中为所有接口构建恒定命中条件的全流量置顶策略,将流经风控系统的所有流量进行记录和存档。当业务测试需要查询时,通过指定的标识,检索指定时间范围内的记录,即可快速获取风控命中信息。这种方法不仅提升了风控场景测试的协作效率,还提高了风控测试问题定位的效率。
图:全流量置顶策略留存记录
命中检索效果如下:
图:风控命中检索
2.3 风控场景生成工具,提升造数效率
通常情况下,业务测试需要关注的是业务命中风控后的表现。然而,由于风控系统的专业性和逻辑的复杂性,业务测试往往需要耗费大量时间来了解风控内部逻辑,以便正确构造测试数据。风控测试也需要耗费大量时间协助业务测试构建测试策略和分析定位问题,并且还需要核对上游请求数据的准确性。
为了解决这些问题,我们构建了风控场景生成工具,简化了风控场景测试和数据质量核对的过程:
数据合规校验: 业务测试可以选择期望命中的风控场景,填入如司机ID等唯一标识。场景化工具会自动检验当前司机是否满足风控条件,并给予恰当的提示。
特征信息注入: 当场景数据满足条件后,场景化工具会将如司机ID等唯一标识进行加工,并注入到风控黑名单库内,作为名单库特征信息。此时,业务测试执行测试场景即可正常命中风控;
数据质量核对: 风控测试会将造数特征、业务逻辑特征和参数校验特征一起加工成测试策略。当业务请求到达风控系统后,系统会根据正常的风控逻辑逐一校验这些特征,降低人工核对成本。
图:风控场景化工具流程
通过这些改进,我们大大提升了风控场景测试的效率和准确性,减少了业务测试和风控测试的协作成本。
2.4 风控需求测试先行
图:变更的质量保障
在风控需求上线流程中,风控测试践行了测试左移的理念。在开发阶段,风控测试团队开发风控场景生成工具和风控测试策略。而在测试阶段,这些工具能够赋能业务测试,使风控测试无需全程参与。这样不仅解决了业务测试在测试风控场景过程中遇到的阻塞问题,还节约了风控测试在风控需求上的投入成本,实现了双赢。
2.5 风控需求质量保障的局限
场景化工具的运用需要业务测试和开发团队主动识别调用风控的场景,并使用我们提供的工具和策略。因此,这种方法存在一定的局限性。如果业务研发未能识别到风控相关的改动,或者业务测试未能回归风控拦截场景,可能会导致数据质量问题被遗漏到线上。
为了解决这一问题,我们需要在测试环境中构建一套主动拦截数据质量问题的能力。这将确保即使在业务测试和开发团队未能识别到风控相关改动的情况下,数据质量问题也能被及时发现和解决。
图:数据错漏问题根因分析
3. 全域风控,数据质量的全局保障
在以往利用场景化工具进行数据质量核对的实践中,如果上游业务改动未能识别到对风控的影响,可能会导致风控接收到的数据质量出现问题。测试环境中仅对部分流量进行核对,缺乏主动拦截数据质量问题的手段和全量核对数据的方法。
为了解决这一问题,我们想到,将用于数据记录的全流量置顶策略与场景化测试策略中的数据核对部分结合,扩展为全域风控拦截策略。这样可以对所有流经风控系统的流量进行核对,实现全域风控拦截。
为什么不在系统功能层面保障数据质量?
数据质量问题由来已久,在未经治理的情况下盲目进行功能上的强制限制,可能会引发预期外的风险。
策略对数据的要求是动态变化的,如果从功能上进行限制,会对风控策略的灵活性造成影响。
风控系统已经有对数据质量问题进行监控和告警的能力,但监控和告警难以及时阻断问题的发生。
而通过全域风控拦截策略,我们能够更全面地核对数据质量,及时发现并解决潜在问题,确保风控系统的稳定性和可靠性。
3.1 全域风控拦截
全域风控拦截是在测试环境中创建全流量管控策略,管理经过风控系统的所有流量,并对这些流量进行字段核查,以捕获不符合风控接口要求的流量。通过返回风控拦截结果码,策略可以阻塞上游服务流程,同时利用拦截策略触发通知,使风控测试人员能够及时发现对接方字段的错误或遗漏,从而促使上游及时的进行修正和优化。这样,我们可以将过去的被动拦截转变为主动发现,避免将数据质量问题遗漏到线上。
图:全域拦截方案
整个全域风控拦截的过程分为三个环节:
全域风控策略的设定: 根据接口文档,风控测试将文档中的特征按照其重要性和业务属性进行分类,并在风控平台上进行配置,构建相应的全域拦截策略;
全域风控拦截的实施: 一旦策略生效,风控系统将接收上游流量,拦截不符合规定的流量,并将其通知给特征测试平台;
风控问题的跟踪和解决: 在发现不符合规定的流量后,风控测试将创建跟进单,并根据收集到的信息判断是否存在数据质量问题,及时跟踪和解决。
3.2 数据先期治理
在 风控特征质量保障的探索和实践中,我们已经详细介绍了货拉拉全域风控拦截的实施方案。然而,在实际执行过程中,数据质量的先期治理是其中的痛点和难点。
为什么要进行数据质量治理?
测试流量噪音过多:测试环境,由于造数工具、自动化测试、压力测试和接口调试等原因,导致流量噪音过多,影响数据质量;
历史字段缺失问题:部分上游系统存在历史字段缺失问题,盲目开启强制拦截会导致上游流程无法正常进行;
提前沟通与认知统一: 需要提前与上游开发和测试团队进行沟通,统一认知,确保全域风控拦截的顺利进行。
图:全域风控策略启用流程
通过数据质量治理,我们能够有效减少流量噪音,解决历史字段缺失问题,并确保各方对数据质量要求的统一认知,从而为全域风控拦截的顺利实施奠定坚实基础。
治理案例(下单接口流量治理)
图:数据治理案例
3.3 数据问题发掘
在进行数据先期治理后,全域风控常态化实践过程中,我们每天仍能拦截上千条流量。如何在这些繁杂的流量中发掘出真正的数据问题,是我们面临的一个显著挑战。
我们考虑到,造数工具、自动化测试、压力测试和接口调试产生的流量往往相似度较高,或者具有固定的标识。而正常的测试流量由于测试场景不同,相似度较低。因此,我们根据司机ID、用户ID等唯一标识,将相似度高的流量进行合并,从而降低人工核对的成本。
图:数据标注
此外,我们提供数据标注能力,将排查后具有噪音特征的流量进行标注,并将这些噪音特征添加到 Elasticsearch(ES)中。利用ES的分词检测能力,我们可以检测后续流量,并自动标注出已有特征的流量,从而降低发掘问题的成本。
图:分词检测匹配
通过这些措施,我们能够更高效地识别和处理数据问题,提升全域风控的效果和效率。
4. 风控不再成为线上验证卡点
货拉拉是从事同城/跨城货运、企业版物流服务、搬家、零担、跑腿、冷运、汽车租售及车后市场服务的互联网物流商城。作为货拉拉的测试团队,我们需要通过各种途径在平台上寻找系统隐藏的漏洞。然而,这种测试行为在线上环境中通常会被风控系统识别为黑产活动,从而限制测试账户的使用,导致测试行为难以顺利开展。
在货拉拉,我们可以通过将测试账户加入风控测试白名单来规避这种问题。然而,在过往的实践中,经常出现测试验证时才发现账户已被风控拦截的情况,问题定位和加白操作需要额外的沟通和协调成本。此外,加白账户也存在使用人员离职后未能及时回收的风险。
针对这些问题,风控测试团队提供了工具使用追踪和白名单管控的能力。这些措施不仅提升了线上验证的效率,还有效规避了白名单异常的风险。通过这些改进,我们能够更高效地进行测试,确保系统的安全性和稳定性。
4.1 工具使用追踪
在线下,我们提供了一系列风控场景生成工具,协助业务测试降本增效。因此,当业务测试使用这些工具时,我们认为在需求上线时需要获取风控测试的支持。
为此,我们对风控场景生成工具进行了拓展。当业务测试使用工具时,工具会将使用记录和使用人信息回调给风控测试平台,由平台进行记录。平台会定期汇总和合并这些记录,并推送工单给场景生成工具的使用人。使用人填写需求内容和上线时间后,平台会在需求上线前提醒工具使用人提前对账号进行加白。
图:工具使用追踪流程
风控测试支持:
通过这一流程,我们提前规避了上线过程中可能出现的风控拦截问题。
4.2 线上白名单管控
我们通过风控策略和履约系统的限制,确保测试账号没有真实的履约风险。然而,如果风控测试白名单内的账号属性被修改为非测试账号,或者账号持有人离职,可能会带来预期外的风险。为了规避这些风险,风控测试团队对风控线上白名单进行了定期巡检和严格管控。
图:线上白名单管控
5. 向前看长路漫漫亦灿灿
我们相信,风控测试的质效提升,源于智能化工具和跨团队协作的持续优化。过去,我们需要投入团队中三分之一的人力来验证配置类风控需求,并支持其他团队的风控相关测试工作。而现在,通过引入风控场景生成工具和全域风控拦截策略,我们大幅减少了对人工干预的依赖。自动化工具不仅提高了测试效率,还显著降低了沟通和协作成本,使风控测试团队能够将更多精力投入到高价值的需求测试工作中。回首看轻舟已过万重山,向前看长路漫漫亦灿灿。在风控测试的质效提升之路上,我们仍将继续前行:
智能: 引入 ai 进行智能链路分析,智能识别风控测试场景,推荐场景化测试工具。
高效: 持续优化分词识别能力,更精确的识别测试环境噪音流量,提高数据质量问题发现效率。
服务: 建立更加高效的跨团队协作机制,更智能的工具,服务业务测试、开发,提升风控需求的质量和交付效率。