引言
互联网时代，万物互联，网络安全形势越来越严峻，安全是企业的基石，风控在企业中扮演着“警察”角色，运用各种技术和手段，保护企业内的用户利益不受侵害。
风控决策引是风控中台的入口，提供业务风险场景事件接入，可视化编排复杂决策，丰富的特征变量与场景识别服务等功能。相较于需要开发背景及算法背景才能使用的传统风控引擎，本文介绍的决策引擎构建完成后无需开发背景甚至无需算法建模背景，作为纯正的策略运营即可配置应用到业务的决策中，实时对抗黑产。
决策引擎分解
风险事件
风险事件对应一个风险领域，是针对特定业务事件领域的具体抽象，以方便策略运营人员管理领域下对抗规则使用的。
举例：假设要对裂变类营销场景防控，如分享当前内容到朋友圈即可获得 88 元精美礼品一份，那么风险领域可以大致划分为发起分享（发起频率/作弊）、接受分享（同人/群组/频率）、分享后领奖（频率/群组/归因群组），每一步对应的被风险特征不同，需要专有的策略部署防控。
决策流
如上，风控团队人员和业务团队人员充分沟通后，大致已经知道了业务玩法的风险点，即可以明确划分出“风险事件”。那么如何高效且稳定的去管理当前领域下的风险对抗策略，是对风控研发的一大挑战。
策略运营人员为了对抗黑产，每时每刻都需要变更防控手段，且时效性要高，即期望立即生效。那如何能够让生产改动安全且高效的部署到线上？早期团队为了快速迭代，使用 XML 模式更改，好处是扩展性高，坏处显而易见：只能研发代替策略人员修改决策流配置，策略人员不理解或者根本不太敢动 XML “代码”。
1 |
|
随着团队的扩大，有了专业的 UED 和前端开发小伙伴加入，可以支撑我们在视觉和操作上下功夫，参照业内的 BPMN 2.0 工作流设计规范，将枯燥复杂的 XML 代码 转换为决策流编排配置模式，大大增加了策略运营人员的对抗效率，也解放了后端研发人员，不用再去抠 XML 代码了而担心出错了。
1.策略组
“策略节点”是决策流程上最重要的一个节点，内部关联了大量的对抗黑产的规则，其中涉及了各个规则如何协作，决策结果如何输出等职责。在和黑产的对抗过程中，先辈们总结出了一套模式来快速部署规则，效果最大化的对抗黑产，同时也不会“误杀”好的用户。
1.1.策略模式
策略总共分成两种模式：评分卡、最坏匹配，如下我将详细为你介绍各个模式如何运作以及适合的场景。
评分卡
此处的评分卡并非指数据模型评分卡，而是专家评分卡，通俗一点讲就是依据专家经验，对命中不同规则加权得分，如果最终得分命中了拒绝区间分段，则需要拒绝。此类模式，对于早期缺少用户“黑标”，直接依赖专家经验，是一个不错的选择。
评分卡是一个概率学问题，越黑的用户会命中越多的规则，所得的分就越多，即表明风险越高。举例：黑产为了对抗风控，会找大量的代理 IP 或者修改 GPS 定位来扰乱风控系统检测，同时也有“猫池”等设备提供海量手就号。但是当下有不少正常用户都有 2 台手机，且因为工作原因，频繁多地飞行，即地理位置不停地变换，那么策略人员制定好的评分规则如下：
| 序号 | 规则 | 得分 |
|---|---|---|
| 1 | 是否异地 | 10 |
| 2 | 是否多设备登录 | 10 |
| 3 | 所有登录设备去重数大于等于 4 | 20 |
| 4 | 切换不同登录设备速度过快 | 30 |
| 5 | 账户提现异动 | 40 |
评分区间如下
| 通过 | 人审 | 拒绝 |
|---|---|---|
| [0, 20] | (20, 40] | (40,∞] |
可以看到，正常的用户只会命中 0，有多个设备的用户（2 到 3 个）基本上得分在 20，也不会造成打扰。切正常的用户就算频繁的出行各城市直接，也不会说上一秒在上海，下一秒在广州了，对抗黑产还是有迹可寻的！
最坏匹配
“最坏匹配”有点类似于流处理概念中的 anyMatch，即只要有任何规则命中，则立即拒绝。此种模式内包含的规则属于非常确定，一定是可解释的，如果命中，基本可以断定拒绝本次请求的。如：同一设备既发起邀请又接受邀请，属于同人诈骗，明显不符合活动规则，则可立即拒绝的。
选择最坏匹配模式要慎重，它是专家经验的凝聚，一定是在生产环境多次验证，召回和准确率较高，不会出现“误杀”的情况，否则会遭遇大量被误拒的客户客诉，严重甚至阻碍业务发展，品牌价值极大损坏。
1.2.策略装配
策略是当前风险场景下某个风险点的抽象，举例：在邀请风险场景下，可以有设备策略、手机号策略、群组策略等，策略包下是一个个规则，负责管理规则的生命周期。
规则
规则是风控决策流中最小“原子”单位，规则的构成如下：
| 左值 | 比较符 | 右值 |
|---|---|---|
| 变量（又叫特征，指标等） | >, <, =, >=, <=, 包含, 属于… | 常量/变量 |
举例：在设备策略包中包含如下规则：所有登录设备去重数大于等于 4，则对照如下
| 左值 | 比较符 | 右值 |
|---|---|---|
| 登录设备去重数 | >= | 4 |
规则组
单一的规则命中可能对用户的干扰度比较大，此时需要联合规则判定，即规则组，规则组可以编排与或计算逻辑：满足所有、满足一条、自定义，其中自定义支持复杂的条件表达式 1 || (2 && 3) || 4，满足不同规则组合需求。
2.名单
“名单节点”是决策流内一大重要功能，同时也是最危险的防御动作之一。
为什么需要名单？假设你是一个黑户，如果没有名单，每次都需要执行一遍决策流，这是对计算和成本的极大浪费，那么此时为了提升性能及成本考虑，直接将你打标拉黑，此时在决策流入口编排新增一个名单节点，你可简单理解为这是一个超大的“缓存”模块，那么加黑的用户会直接拒绝，而不需要再往下跑决策流，同理，判定为高价值低风险好的用户，也可直接加白，立即通过，无需等待，只有真正的纯新用户或“摇摆”的客户，才需要跑决策流判断风险。
黑白名单简单粗暴很好用，简单粗暴意味着容易出现问题，一不留神就会把自己“坑死”，一次随意添加黑名单数据可能会直接侵害大部分的正常用户，同样的，白名单的随意添加直接可能为恶意用户打开便捷之门。
那么这些名单是如何产生的？
黑名单
从历史的恶意数据中提取，设备、手机号、IP 等。同时结合第三方合作伙伴，共建黑名单库（毕竟人家已经沉淀很久了）。
白名单
最简单粗暴的手段就是看价值和风险四象限，高价值低风险的用户一定是我们的目标客户（非绝对，也可伪装），此时可以给这部分用户直接加白。
名单一定是有时效的，且名单内部一定是有壁垒的，可以理解为领域隔离，如何理解？即这个用户在当前场景是坏得，但是在别的场景又是好的，那么此时只需要在当前的细分领域隔离拉黑即可。时效性是为了解决那种懂得养号黑产，或者一开始伪装成高价值的黑产用户，风控程序需要定时去梳理重新计算哪些用户是可以加白加黑的，做到赏罚分明，尽量不冤枉、不溺爱任何人。
3.分支
决策流图需要“分支节点”来导流，数据节点（开始、名单、策略节点都算是数据节点）负责吐出计算后的数据，分支节点拿到数据后，依据条件表达式，导流到相应的后续节点。
决策流在走到分支节点后，依据分支上的条件排序，分别执行条件表达式，只要有一条满足条件，则往下执行。
4.Fork/Join
Fork & Join 是决策流编排中的高级概念节点，决策流实际上就是一个庞大的 DAG（有向无环图），如果每个路径都同步去执行一遍，太耗费时间，业务方留给风控决策的时间不会超过 200ms，但风控有涉及到大量的计算和 I/O 操作，此时可以配置 Fork/Join 节点并发执行流程再聚和，缩短路径时间。
决策流性能优化非常有挑战，这只是一个小的优化点，限于篇幅，后续会专门开一篇性能优化具体介绍。
稳定性
稳定性老生常谈了，何况是能掌握“生杀”大全的风控系统。风控对系统的稳定性建设高于策略的执行，即兜底策略是通过，在不影响正常用户体验的情况下，允许漏过一部分黑的用户进去，我们可以有多种手段在事后将黑户捞出来封禁（前提是离线响应足够快，各系统配合足够好，本身黑产是非常高效的）。
极致性能
业务留给风控策略执行的时间不会超过 200 ms，在短短的 200 ms 内风控要处理大量的计算逻辑，这是相悖的。
风控是我见过为数不多真正将并发实际用“飞起来”的系统，为了节省时间，大量的并行计算带超时设计，以空间换时间思想运用到了极致，提前算好放在那，等待决策的时候直接内存计算即可。对于风控研发来说最难的就是要考虑当前的实现是否能不高于超时时间，有较大的技术挑战。
灰度支持：策略运营友好
策略的上线是一个“高危”动作，如果运营在线下分析出错，那么可能导致生产大量好的用户被拦截，造成大量的客诉，这损失是惨重的，所以决策流在设计之初就应该要考虑新版本灰度上线等功能的支持，可以按照 0-100 流量逐步放量，将损失降至最小。
回滚降级
在出现生产问题时，优先观测当前有哪些生产变更，如果是决策流变更，需要支持版本回滚功能，确保第一时间能恢复问题。
针对大促或者大流量突刺进来时，需要依据特定的风险场景进行限流/熔断功能，参照业内开源的 sentinel 制定一整套防崩模式，确保系统稳定。
异动监控
监控是老生常谈了，但是真的很重要！试想如果不对某个场景下决策的拒绝结果做监控，万一线上因为某个改动导致大量拒绝，用户无法正常往下走，想想都很可怕！
总结
决策引擎是风控的大脑，风控能够高效的和黑产对抗，决策引擎是门面担当。
目前决策引擎是配置化编排，正在想智能、自动化的方向构建，帮助业务人员更好的部署规则和提效。同时我们也在思考，如何让业务能够快速，“无感知”的，或者尽量少侵入（低成本）的接入风控，也是一个挑战。黑产也是人，他们也在对抗中进化，会有越来越多的新式手段来挑战风控安全的壁垒，任重而道远！
往期精彩
欢迎关注公众号：咕咕鸡技术专栏
个人技术博客：https://jifuwei.github.io/ >
