#21天打卡产品经理的日常思考# 在互联网公司中，针对这类风险点的风控体系搭建通常分为两个阶段。

第一个阶段是通过运营人员的经验，在业务系统内设定合适的规则策略，根据经验和现状不断调整阈值，同时增加人工审核人员，通过人力去判断遭受风险的状况和损失。这种策略制定的正确性在上线初期相当高，效果显著，但随着黑灰产不断地尝试，阈值地范围能够被测试出来，若最终采用一刀切的策略对社交平台而言是非常不利的，会出现大量的误杀情况。

此外，还有一个隐患是大量的规则策略若始终存在业务系统内必然会出现业务系统反应延迟的情况。

一般来说，公司所自研的风控引擎分为两个模块，在线同步模块和离线异步模块，如果对在线同步这块的风控规则进行了加强和优化，会导致整个业务接口的执行链路更长，最终带来TPS和QPS这两个关键指标下降，很多公司在每次碰上风险损失后都会配置不同的策略放在风控系统，互联网公司员工流动性又相对较大，前人配置的策略逐步累加，却没有后人进行删减，有的公司在进行风控自查的时候甚至发现了针对同一活动风险场景配置了2000条策略。

策略、规则的堆积和风控引擎嵌入业务系统的方式，只会让性能急剧下降，除了不断买服务器这个方法，绝大多数公司会选择进入第二阶段。

第二个阶段是通过前端用户设备维度的设备指纹识别用户操作环境，通过旁路设置的风控引擎和配置好的专家规则配合，这个阶段能大大减轻人力成本的付出，同时减轻业务系统的负担，在保持整体响应速度的前提下，减少性能的损耗。

这种模式需要在用户端设置设备指纹，生成设备唯一标识，对用户的操作环境进行风险评分，识别用户操作环境是否存在多开、ROOT、HOOK、模拟器等，后端风控引擎根据前端设备指纹信息和专家策略规则在极短时间内完成策略的输出，处理风险点。

此外，旁路设置的风控引擎能够和业务系统保持各自的独立性，在业务系统宕机时主动发起提醒，帮助运营及运维人员审查。