复杂风控场景下，如何打造一款高效的规则引擎
| 本文转载自【美团安全应急响应中心】公众号，欢迎大家关注。
在互联网时代，安全已经成为企业的命脉。美团信息安全团队需要采用各种措施和手段来保障业务安全，从而确保美团平台上的用户和商户利益不会受到侵害。
本文主要介绍了美团在打造自有规则引擎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业务基于上述功能上还是实现了事件行为记录、多事件时序性累计和拦截行为的累计。目前在其业务下广泛使用并有效地识别了跨事件风险。
总结而言，做好业务定期应用回访和应用监控是非常有必要的。
美团自研的 OCTO 数据中心（简称 Watt）日均处理万亿级数据量，该系统具备较好的扩展能力及实时性，千台实例集群周运维成本低于10分钟。 本文将详细阐述 Watt 计算引擎的演进历程及架构设 ...