除了技术，无它

439篇博客

编辑推荐

网易数帆开源API网关与容器云项目，让云原生生产落地“多快好

网易汪源：统一负载与多云环境的“开放姿态”，才是云原生

网易数帆如何用 Kubernetes“原语”搞定云原生中间件

快手打新挤爆券商系统，网易数帆推出券商稳定性保障方案

探索智慧校园新模式，网易有数在教育行业的实践分享

金融行业大数据治理之路——数据模型篇

网易严选风控实践（上）-打造现代化的风控体系

达芬奇密码2018-08-02 10:55

最近一段时间，公司许多产品的风控团队跟我们做了很多技术上的交流，大家对严选的风控体系很有兴趣。因此，我们打算在KS平台上给同学们介绍下这一年来严选风控体系的建立过程，抛砖引玉，期待引来大家的建议。

严选的风控体系最近半年的变化非常巨大。初期我们只是做了简单的下单频率控制，能满足部分业务场景，但是随着严选的迅速发展，灰产用户引发的资损情况变得越来越严峻。

图1 灰产用户卖严选券

到了今年7月份的时候我们开始腾出手来设计严选的风控体系。我们先后与美团，支付宝，阿里巴巴，京东等风控团队做了大量的技术交流，结合我们的情况确立了严选风控体系的建设目标：

1. 主动。立足于大数据，利用算法模型主动发现异常特征，提前识别。

2. 快速。严选大量的核心业务会同步依赖风控接口，因此我们认为风控接口的latency超过100ms，就没什么价值。核心风控接口(下单控制等)延迟的及格线应该是50ms。才能尽量降低对业务的影响。

3. 灵敏。用户的异常行为需要能实时反馈。当用户出现异常行为时（比如用户鼠标以匀速的状态在移动），所有风控模型都需要立刻重新评估他的信誉情况。并在毫秒级时间完成重新评估，从而保证能立刻拦截他之后可能的违规行为。

4. 灵活。风控与业务逻辑，运营策略等联系非常紧密。风控的策略需要能够做到随时变更，随时生效，与严选业务共同呼吸。

我们的目标是构建符合以上设计目标的现代化风控体系。

严选的风控体系架构

我们把严选的风控体系建设分成4个部分：团队建设，构建以数据为核心的风险识别与分析系统，高性能的异常行为拦截系统，黑科技。在这个体系中，风控的策略，模型，规则，拦截等是高举高打的正规作战方式；而黑科技则是剑走偏锋，谋奇效的方法。

图2 严选风控体系

上图是严选风控体系的一个简单示意图，围绕着风险控制的各个阶段，我们把工作简单划分成了3部分：风险识别，异常拦截，业务支持。风控系统架构是整个建设工作中最为简单，直白的一部分，最为关键和复杂的工作是把架构落地，产生价值。由于文字表达能力和篇幅的限制，我就不具体展开说明我们把上述架构落地的详细过程了。我们稍微介绍下我们系统是如何来实现风控：主动，快速，灵敏，灵活这4个设计目标的。

业务目标指导团队建设。为了完成以上4个设计目标，我们组建了包括模型研发，数据分析，系统研发，风控业务等角色的6人组小规模战斗团队，团队中大部分同学一人兼多角色，确保大家能充分理解各个模块的功能，减少角色之间的沟通，理解成本，提升战斗力和工作效率。

图3 严选风控两级防护模型--护城河+城墙

在开始之前，我先简单说明一下我们的风控模型之间的相互关系——我们把它们具像为护城河+城墙的防护关系。用户在过护城河的时候要被检查一下基础信誉，如有异常则会被拒绝入内，当用户尝试使用可能引发严选资损的业务时，还需要再次确认下是否有足够的信誉来进入对应的城门。如不满足，也会被拒绝在外。

主动 & 灵敏

风控业务本质上是基于大数据的一个数据产品。我们要实现主动和灵敏这两个设计目标，就需要把数据作为风控体系的核心，把思考点落在如何来玩好这些数据。幸福的是，我们底层的基础设施已经非常完备。严选的离线数据计算系统和实时数据计算系统(ATOM)等基础设施在今年9月份构建完毕。

怎么做到对风险的主动和灵敏？我觉得第一个重要的是要明确，我们系统要对什么风险主动，要对什么风险灵敏？对于严选业务而言，我认为是：资产损失。严选风控定义的资产损失包括两个部分：公司资产损失和用户资产损失。严选风控的首要目标是保护这两者，减少他们的损失。

攻与防是风控的基调。我们听到了很多攻防双方见招拆招的例子，包括我们自己也积累了大量的这种例子。但我认为见招拆招其实是一种很被动的情况，防守一方一旦疲于应付，就会面临道高一尺，魔高一丈的局面。

我们的策略是避免沉迷在各种攻防细节中，主动构建安全的城墙和护城河。我们对每一个严选用户，他们使用的设备，使用的手机号，IP等建立了信誉度模型。模型为会每一个用户单独打分，评估他们的信誉情况，这套基础的信誉评估体系就是严选业务的护城河。当用户需要使用严选时，他首先需要走过这条护城河上的桥，通过的凭证就是他的信誉。

当用户走过护城河时，他面临的是一道城墙。严选风控系统为每个业务在城墙上单独开了一扇门，每扇门都会有单独的算法模型来评估用户的情况。当然，用户对护城河与城墙的存在正常情况下是不感知的，只有当他被拦截在外时才会发现：咦，你们怎么知道我要来干坏事？

我们通过护城河与城墙来构建用户与严选业务系统之间的安全距离。模型研发的同学大部分时候的工作都是在加固这两道防线。

我们的模型系统在7月份发布了第一版，按T+1的时效更新。由于模型依赖的交易数据，访问数据等都是T+1生成的，从而导致模型本身的时效不足，对用户异常行为的反应不够灵敏。这是一个致命的问题，严选负责实时计算的团队在今年8月份开展了严选DataHub项目。目标是把严选的核心数据源：MySQL，DDB，MongoDB，日志等所有数据实时化，在次之前，我们的实时计算平台只能把日志部分的数据实时化，而MySQL，DDB，MongoDB等产生的数据只能T+1通过sqoop导入到猛犸的方式来获取。

日志。我们简单的利用了flume+kafka的收集方案，通过严选DataHub数据交换服务可以方便的把严选产生的日志数据实时的接入实时计算平台。

MySQL & DDB。严选DataHub服务将自己伪装为MySQL数据库的镜像库（我们修改了开源服务canal来实现这个特性），利用MySQL主从同步协议，实时的获取了MySQL的binlog。同时通过一定的规则，将每张数据库表的实时变更消息以毫秒级的延迟映射到实时通道。完成这个项目后，我们风控依赖的关键数据库数据就足够灵敏了。

MongoDB。严选DataHub研发了MongoDB的OPLog实时获取，分析，解析与入HIVE库的服务。确保MongoDB产生的业务数据也能在严选实时平台上以毫秒级的延迟被访问到。

严选DataHub项目完成后，风控模型系统开始重构，完成了基于实时数据的模型，确保了整个风控系统的灵敏度。只要用户产生了异常行为，他的护城河通行证，城墙通行证上的信誉度都会在毫秒级内完成重新评估。在他干坏事之间就拦截他。

快速

风控系统对业务要做到有效支撑，非常关键的是系统的整体性能。我们的目标是关键业务的风控接口需要在50ms内完成，时效容忍度较高的业务需要在200ms内完成。我们知道风控系统决定是否拦截某个用户行为（比如下单），会有大量的规则需要计算，部分还可能有同步的模型计算，要完成这样的目标挑战不小。

我们的设计思路很简单，计算提前。严选的风控系统在用户一开始访问严选时，就在监控与计算他的行为，我们称为全链路监控与全链路计算。

用户每行动一步，实时平台上的风控任务就会开始调整他护城河的通行证以及所有业务的通行证的信誉值，并执行相应的规则引擎来判定他是否可以通过。也就是说，用户刚到严选门口浏览时，护城河门口与各个城墙门口都已经算好了他是否可以通过，并且这个通过的决策是时刻根据他的具体行为实时在调整的。比如，用户一开始用在淘宝买了一个全新的帐号，然后用了一个灰产专用虚拟机登录了下，当他尝试使用免单券去下单前，在下单业务的城墙门口已经张贴了一条告示：用户XXX违规使用异常的CPU架构，禁止使用免单券。城墙门口的守卫只需要根据他的名字去查下告示就行，O(1)的时间复杂度，可以确保查询足够快，不会导致城墙门口堆积了要办事的人群。

提前计算，全链路监控是确保整套风控系统对外接口高性能的关键。

灵活

严选风控面对的是频繁变化的业务场景，风控系统要有足够的能力应对这种变化，做到与严选共同呼吸。

因此，我们从架构上把风险识别与拦截做了拆分，风险的识别相对稳定，而风险的拦截规则是会频繁变更的。所以提高系统灵活性的关键是提高严选风控规则引擎的灵活性。我们采用了可视化的方式来编辑风险拦截的规则，可以确保风控的规则管理人员能在10分钟内完成拦截规则的变更。

一般公司会采用Drools规则引擎来描述和执行风控规则，Drools虽然使用方便，但表达能力和灵活度都比较差，因此我们采用了相对不一样的方式来描述风控规则。严选采用Groovy脚本语言和Drools规则系统相结合的方式来作为严选的规则引擎。

Groovy脚本语言提供了非常强大的表达能力。ATOM实时计算平台提供了对这两个规则引擎的支持。