复杂风控场景下，如何打造一款高效的规则引擎

| 在互联网时代，安全已经成为企业的命脉。美团信息安全团队须要采用各类措施和手段来保障业务安全，从而确保美团平台上的用户和商户利益不会受到侵害。

本文主要介绍了美团在打造自有规则引擎Zeus（中文名“宙斯”）的过程当中，信息安全团队遇到的挑战以及对应的解决方案，并分享了不少踩过的坑，同时还有一些思考和总结。但愿对从事安全领域相关工做的同窗可以有所启发或者帮助。

背景

美团App天天都面临着各种的欺诈、盗号、做弊、套现以及营销活动被恶意刷单、恶意抢占资源等风险。而业务安全团队采用的主要措施和手段就是在业务请求中识别出谁、在什么时间、经过什么方式、作了什么事。这个识别逻辑的制定过程叫作策略的生产。同时，还要对已经完成生产的策略进行快速的验证和落地，以防止风险变化后策略失效。从发现风险通过策略生产、验证，再到最终的落地部署，全流程的处理速度和效果将决定整个业务的成败。

在业务发展初期，咱们能够经过硬编码的方式将风控逻辑部署在业务逻辑中实现，但美团的业务比较复杂，从最初的团购形式，通过与大众点评、摩拜、猫眼等业务的融合，发展到涵盖餐饮、到店、猫眼、外卖、金融、酒店、旅游、大交通等多个垂直领域。随着业务的快速发展，适用于初期的硬编码方式出现了策略分散没法管理、逻辑同业务强耦合、策略更新迭代率受限于开发、对接成本高等多种问题。此时，咱们须要有一套可配置化的规则管理平台，进而实现风控策略与业务解耦、快速部署、验证。

但规则引擎的建设初期，会面临着各类困难和挑战，主要包括如下几个方面：

• 在业务层面：垂直领域多，包含几乎全部的吃喝玩乐服务。美团细分业务多达百个。服务用户角色多（用户、商户、供应商、渠道商），交易频率高，日订单量大。
• 在风险层面：存在用户做弊、商家刷单、帐号盗用冒用、支付和信贷等多种风险。
• 在企业外部环境层面：黑产已造成自下而上的产业链，攻击方式升级比较快速。

针对以上这些挑战，咱们打造了自有的规则引擎 Zeus（中文“宙斯”，来源于“宙斯盾”做战系统的启发，指望规则引擎平台能同“宙斯盾”同样成为先进的中央做战决策系统，实现对风险的精准、高效打击）。

下面，咱们就来具体介绍一下，美团信息安全团队在系统构建过程当中面临的挑战以及对应的解决方案。

挑战与方案

1. 业务多-接入成本高

规则引擎最先只是业务系统中的一个函数，逐步演化成了独立的服务。而这个独立服务与业务后台的交互是单点方式，即业务后台在关键动做节点前调用规则引擎，判断“有没有风险”。但这样每次新增长一个业务或新出现一个风险场景时，规则引擎和业务都要从新进行对接联调。频繁地调整给上下游团队都带来了不小的负担，并且在频繁的更改中，系统质量也难以保证。如何便捷、快速地实现业务接入是系统设计的核心目标之一。

在接入成本上，一次性集中接入每每是最便捷的方式。所以咱们选择在每一个业务都会通用节点接入规则引擎，例如：用户中心、商户中心、订单中心、收银台等均为各种业务的通用节点，规则引擎同这些通用节点对接，业务在调用通用节点时，通用节点调用规则引擎便可完成业务的接入。

随着美团业务和场景种类的增多，如今也存在不通过通用节点的业务。所以，咱们须要提供通用的接入接口，目前业务侧直接调用一个独立服务接口便可得到风控判断。

2. 风险点多-逻辑复杂、逻辑复用

风险点多且业务多，进一步增长了场景、策略逻辑的复杂度。表达式语言可支持的逻辑计算范围有限，复杂的逻辑若仍经过硬编码实现，会存在效率低、不易复用等问题。

受模块化思惟启发，咱们将复杂的逻辑封装成模版，实现配置化，并支持逻辑复用。这样就大大提高了规则引擎可实现的逻辑范围。目前，咱们已经建设的几类经常使用的封装逻辑以下：

1. 扩展函数：主要用于数据格式的提取和处理，好比字符串、数组等格式转换、数据提取等。经过扩展函数功能，对业务侧数据格式要求大大下降，也下降了业务侧数据处理的负担。
2. 累计因子：在业务中会高频使用到与累计相关的逻辑。例如，在登录、下单、支付等事件须要同IP的UserID进行计数计算，计算结果做为特征引用在规则中。规则引擎引入了内部研发的高效事件计数服务，实现累计通用逻辑的封装，好比支持累计周期、计数/求和/最近几回、累计值等计算逻辑配置化等等。
3. 决策表因子：部分业务中须要引擎处理的判断条件较多，各条件又相互组合，存在多种决策方案的状况，这就须要用精确、简洁的方式来描述这类复杂逻辑。在低频使用时，咱们能够经过硬编码的case-when、if-else等语句实现，但在实时性和配置化上不尽人意。最终，咱们经过决策表将多个独立的条件和多个动做直接地联系、清晰地表示出来，并实现了逻辑的封装。
4. 名单库因子：与名单库联动过程当中，将查询名单的逻辑进行封装。
5. 工具因子：将一堆规则进行打包造成大的逻辑集合，并对组成的规则设置评分。在执行时输出评分结果并实现跨场景、跨业务应用，同时将大逻辑进行“黑盒”处理，简化逻辑复用时的配置、沟通成本。

风险点多的另外一个挑战点是在多业务中会存在同质性，即制定的风险策略是可复用的。当一百条规则须要复用在几十个场景中，逐个配置的效率过低，不只一致性难以保障，后续的修改也是问题。同时又衍变出部分复用、部分差别化，让业务直接复用场景行不通。所以，咱们引入【规则组】的概念，将规则聚类管理。好比众包识别规则组、虚假设备规则组、涉黄内容识别规则组等。业务在应用时，可在本身的场景中进行差别化的应用。

3. 风险变化快、长期对抗-效果验证速度

当外部风险变化时，风控的对抗也须要及时响应，这是一个争夺“主导权”的比赛。风控经过对不一样阶段的组合打击，实现策略的健壮性，包括用于识别有没有风险的基础对抗阶段、引导节奏混淆视听的“短平快”阶段、诱敌深刻的“高精尖”阶段。对应系统须要支持不一样阶段的策略配置、迭代和验证需求。而在策略迭代和部署阶段，须要特别注意因配置错误致使的误命中问题。

参考开发环境分类：测试环境、预发布环境和生产环境。规则引擎在规则的部署和迭代上，可经过标记、双跑和回溯功能，咱们经过应用实时线上流量和历史数据来验证策略的有效性。

• 标记：规则在场景中的状态，标记状态的规则逻辑将灰度执行，即：与生效规则相似会实时执行，但决策信息不实时返回给上游业务方，不影响决策。同时用户可在实时日志查询中查看标记规则的命中状况。
• 双跑：规则在场景中的状态，双跑状态的规则逻辑将灰度执行，但仅会出如今修改生效规则、因子（因子修改致使引用规则的逻辑执行变化）时，才会存在的状态。
• 回溯：规则在场景中的状态，回溯状态的规则逻辑将灰度执行，但仅使用回放的历史数据。

经过这些功能，能够下降策略迭代的风险，缩短策略部署上线的时间周期。

思路总结

在确认清楚挑战和解决方案以后，规则引擎的总体建设思路就已经造成了。现今，规则引擎随着业务的快速扩张，由一个内部系统逐渐发展为服务多个风控团队的公共平台。

从初期主要围绕风控防控痛点进行搭建的表达式服务包，升级到配置化平台，在配置效率和执行效率也获得了很大的提高。同时，随着人工智能技术的应用和风控对抗进入白热化，规则引擎也将从配置化快速迭代至自动化、智能化。

1. 肯定核心快速论证、快速落地

在系统建设中，进行了充分的论证后就须要快速落地，避免因长项目周期需求发生裂变而致使不可控。在初期，咱们已经创建了aviator表达式服务包并稳定服务。所以，配置化平台搭建时仍基于表达式语言，引入场景、规则、因子、决策等概念搭建，将策略的执行分为执行层和计算层。

执行层：经过场景得到一堆规则集合，规则执行完成后将其结果和对应的决策返回。

结果和：在规则执行时会进行其构成因子计算。

2. 根据角色，进行定向提效

规则引擎搭建的初衷之一是提高风控对抗的总体效率。在对抗过程当中，咱们须要各类角色配合，例如开发建设系统、策略制定者、策略使用者和风险用户等，所以须要针对各种角色定向开展提效工做。

（1）风险用户处理提效（风险用户）

业务已经能够实时得到风控的决策，但发现风险用户会在不少场景下重复攻击。对这类用户的处理，除了对当次行为阻断，还要阻断其将来的行为，所以就有名单管理的诉求。咱们经过与名单库的联动，提高该类用户的处理效率。

例如：在美团金融项目场景下，严重逾期的用户会加入禁贷名单，再次申贷时取消其贷款资格。

（2）业务接入提效（业务方）

除了上面介绍的统一接入外，还有一种常见的状况：业务没法在发起请求时就将执行所须要的所有参数准备好，此时就须要引擎能主动获取外部数据。针对这类状况，规则引擎经过数据接口的方式实现了外部数据的补充，在策略执行时根据计算须要动态获取相关的参数。在实现与外部数据联动的功能后，大大下降了使用规则引擎业务方数据准备阶段的压力，从所有参数准备简化为仅提供核心参数便可，剩余参数按需引擎自行调度便可。

（3）策略管理提效（产品）

策略产品是规则引擎的主要用户，主要的工做流程是围绕策略管理、分析、验证进行提效。如何管理大量的规则和应用场景？怎样快速验证策略有效性、评估误伤率？客诉反馈问题，如何快速还原规则命中状况？针对这些维度，咱们分别提供不一样的产品功能进行提效。

• 在策略管理层面，可经过规则组方式、因子工具等，进行同类规则集合的管理、打包和复用。
• 在规则分析层面，可经过实时查询规则的执行详细数据和将规则执行流程进行回放提高分析效率。
• 在策略验证层面，提供标记、双跑和回溯提高策略验证速度。

（4）工程效率提效（工程师）

复杂的逻辑且具备通用性就能够对特征逻辑封装，避免工程师重复进行逻辑开发工做，释放出的开发资源能够进行其它维度的提效。

（5）算法/模型接入提效（算法工程师）

当对抗升级时，策略的产生者由人变为算法/模型。而机器的生产效率远远高于人，人工搬运算法/模型会成为迭代效率的瓶颈，怎样跟算法、模型平台进行快速联动呢？最简单、快速的方式就是使用引擎提供的外部数据联动方式，将模型结果包装成数据接口使用。但在实践过程当中，咱们发现模型的出入参数较多且存在变化，总体的配置化效率低，模型应用和迭代频率受限制。公司内部提供的深度学习仍是算法工程平台，目前主攻计算、训练等场景，在上下游应用提供标准化的数据产出，但没法同相似引擎的平台对接。

所以，仅聚焦在引擎与算法平台的联动上，可经过建设调度模块实现：1.训练样本预处理-->2.算法平台对接-->3.自动化生成接口-->4.自动注册接口/策略至引擎-->5.评估任务启动-->6.评估结果处理（策略上下线、样本数据沉淀）-->1.训练样本预处理的闭环流程。

3. 发现问题、横向扩展、兼容更多场景

随着引擎在多业务场景的应用，咱们发现几个实时引擎很差处理的场景。好比拉新场景，须要结合“注册+登录+交易”等多种行为来判断是否有“薅羊毛”等黑灰产行为，须要将不少事件放到一块儿去综合断定。当发现风险时，或在当前时间点漏过的变异风险在发现以后，须要对历史数据进行回捞，这些在实时引擎中都不太好实现。当前已有的异步引擎也没法很好地进行覆盖。为了不作“重复造轮子”的事情，团队充分地讨论了实时、异步和离线引擎的定位和服务边界。

在实时引擎已经覆盖的逻辑基础上，咱们引入新的封装逻辑-个体因子，全局因子实现SQL语句的配置化管理，进而实现批量累计、聚合特征的计算，好比：近一年某商家的平均下单金额，近30天商户大盘下单均值，标准差等批数据的复杂逻辑。并基于Spark和实时引擎底层，实现多流和批数据的处理，解决上述场景没法处理的一些问题。

4. 业务实践结果

交易安全

策略产品在平常工做中，经过对业务分析发现风险、挖掘风险特征并应用在策略中。经过Zeus实现策略的部署和应用，大大下降了业务风险，提高风险防控效率。例如：在某业务地推场景中发现B、C端联合刷单风险，以返利、送赠品收到诱骗下单。

金融安全

金融风控主要有反欺诈和信用安全。反欺诈同业务安全在策略形态上相同，都是判断有无风险，在决策结果上是经过和拒绝。所以，经过普通决策便可知足业务需求。

但信用安全会比前二者复杂一些，在决策上，除了经过和拒绝外，对于经过的请求要进行分层实现金融的差别化订价。所以，须要在规则引擎中引入更多功能，来知足业务需求。主要包括：

• 路由场景：可支持多层，决策流模式，即一堆规则的集合，支持按照逻辑进行分流，知足指定条件能够指定走向在每一个节点进行条件设置，实现最终流向。例如：对于某分期场景用户申请一笔贷款，须要通过欺诈识别、信用评估后方可给出最终的额度、订价。
• 决策衍生参数：适用于复杂的多级路由决策场景Key-Value型数据，在决策中指定衍生参数信息从而在路由场景中产生全局传递变量，好比：流转过不一样的场景须要将用户进行等级分类。
• 决策附加信息：适用于复杂决策场景Key-Value型数据，在决策中指定附加信息从而实现更多决策信息的计算及返回，好比：加入风控名单库，加入什么风险类型、风险等级、名单类型。

将来发展与思考

目前规则引擎正处于配置化阶段，正在向自动化、智能化的阶段发展，从而不断提高策略的管理和迭代的速度。但业务间的智能化诉求和进程不一样，平台能够提供更多集成托管服务，从而提高各业务的智能化覆盖度。

其次，引擎仍然存在没法处理的几个问题：

一些长时间周期特征没法快速应用的问题，例如近一年的时间周期。如何将离线引擎和实时引擎在特征计算上组合，实现特征的快速生产、验证和应用，从而扩展引擎的计算能力范围、提高风控业务的对抗效率。

当前引擎的接入对非复杂逻辑需求的业务就比较重。而接入成本是各业务接入时重点评估的因素，如何实现快速、低成本的业务接入（包括技术接入和人员操做接入），考虑提供模块化的引擎计算服务能力适用于各种业务诉求，实现按需接入，比较“臃肿”的全局接入会更快速和便捷。但这种在引擎侧怎样更好地管理这些模块，也是一个挑战。

最后，业务流量和策略的增加速度仍在高速增加，引擎的稳定性和策略管理效率也须要持续提高。

踩过的坑

1. 如何实现产品功能高聚合架构上低耦合

规则引擎建设时兼容各种业务场景，具有了极高的灵活性，同时自身也相对复杂。从顶层的路由场景到底层的参数（路由场景-场景-规则组-规则-决策-因子-参数-数据接口-参数）每个节点、节点间都是由用户配置的，在产品上指望用户的操做流程是连贯的，在一个操做流程中解决尽可能多的问题。系统架构上，包括配置层、执行层、计算层、数据获取层等，各层之间相互依赖，对最终引擎的输出结果负责，底层上须要尽可能的解耦合，才将下降单模块对引擎的影响。但在实践中，随着业务诉求的增多，慢慢就出现来产品上的低耦合、架构上的高耦合状况。

例如：在用户修改生产策略时的强制更新流程优化项目中 ，就涉及了这个问题。在产品功能上用户修改策略-->双版本策略并行执行-->两版本数据核验-->修改完成；但在系统架构上，上述的产品流程就产生了系统架构高耦合，即生产修改双版本问题，配置层、执行层、计算层高度耦合。项目一期上线后在性能上、后续功能扩展性上都有瓶颈。随后，技术项目优化配置层的缓存模式，采用增量更新方式。产品功能上增长用户进入修改模式后修改。从新立项后，实现了用户修改流程闭环、系统架构上仅配置层兼容双版本，执行层和计算层无耦合。

所以，在产品功能设计上除了用户闭环操做外，还须要考虑是否低耦合。在技术优化时须要前瞻性的开展去耦合项目。

2. 如何平衡系统复杂度与业务需求

随着接入业务的增多，又须要兼容新业务定制化需求，就面临这一个问题：定制化的功能不具备通用性，大量定制功能将加剧平台的复杂度。这个问题一直困扰引擎建设团。，目前，咱们采用的也许不是最优但比较有效的办法。主要经过定、判、看Gap，将业务需求转化为系统模块升级功能和非系统功能：

• 功：从新定义“定制和通用”。在现实中有些定制化需求实际上是业务速度已经远远领先于其它业务，全部需求看上去是定制化，其实是将来可预见性的问题。
• 未：将业务需求进行分类，判断需求是针对主干流程仍是分支节点。
• 看Gap：需求同当前建设状况比对差距。

对于系统模块升级功能，可逐个完成。对于非系统功能，可经过提供公共对接服务的外挂来实现。

3. 特别须要“防呆”设计

人工操做会存在各种误操做引发的风险问题，在产品设计上，用户操做简洁的初衷是好的，但须要增长防止错误发生的限制方法。在实践中这些“防呆”设置大大下降了人工误操做Case，例如：

• 业务高峰期封版--->禁止业务高峰期时变动策略。
• 下降无逻辑验证的误伤状况-->策略上线前，强制标记验证执行是否符合业务预期；修改生产上应用的策略，强制双跑验证修改后的逻辑执行是否符合业务预期。
• 下降逻辑配置错误概率-->策略部署时强制测试逻辑正确性。
• 惯性操做-->验证数据结果强制回填等。

4. 产品功能最佳实践的意外惊喜

要认可一个事实就是，最了解功能使用的可能不是规则引擎的产品经理。在规则引擎的建设中出现了这样的”惊喜”，例如：

1. 规则组功能建设初期目标是实现规则的高效管理、复用。在A业务场景基于规则组除实现规则的高效管理、复用外，还实现了决策计算。但这种用法在随着其业务的发展复杂度增长，已经再也不利于策略高效管理，目前还在寻找更优的解决方案。
2. 累计因子的功能是将对多条请求进行计数或求和逻辑进行封装。B业务基于上述功能上仍是实现了事件行为记录、多事件时序性累计和拦截行为的累计。目前在其业务下普遍使用并有效地识别了跨事件风险。

总结而言，作好业务按期应用回访和应用监控是很是有必要的。

招聘信息

美团信息安所有正在招聘实习生，业务方向包括：安全后端开发机器学习算法天然语言处理风控策略数据开发Web前端测试开发产品经理产品运营安全与隐私合规等。工做地点：北京/上海。欢迎感兴趣的同窗发送简历至：tech@meituan.com（邮件标题注明：美团信息安全团队）

阅读更多技术文章，请扫码关注微信公众号-美团技术团队！