风控命中日志和决策日志怎么设计 别只讲概念，真正容易出问题的是链路、状态和治理

风控命中日志为什么越记越乱？从命中明细、决策日志到误杀追查一次讲透

这篇不只讲“日志要结构化”，而是按真实风控项目拆：到底要记几层日志、每层记哪些字段、特征快照怎么取、同步和异步怎么分、投诉和误杀怎么靠日志追出来。
目标是你看完后，能自己设计出一套真正支撑申诉、复盘、回放、审计的风控日志体系。

🦅个人主页
🐼

一、先看一个真实问题：为什么很多风控系统“拦得住，但说不清”

假设一个用户投诉：

• 正常登录却被拦了
• 正常提现吗却进了人审

运营来找研发排查，如果你只能看到：

• 最终结果 =REJECT

那基本没法往下查。

你至少还要知道：

• 哪个场景触发的
• 哪条规则命中的
• 命中时的特征值是多少
• 最终是规则直接拒绝，还是多条规则叠加后转成高风险
• 后续是否触发了验证码、人审、白名单放行

所以风控日志和普通接口日志完全不是一个东西。

普通接口日志解决的是：

• 请求来没来
• 响应快不快

风控日志解决的是：

• 为什么会出这个风险决策
• 这次决策背后依赖了哪些事实
• 事后能不能重放和复盘

一句话总结：

风控日志本质上是“决策解释系统”，不是“打印几行请求信息”。

二、先把日志分层，不然后面不是缺字段就是一团 JSON

我比较推荐最少拆成 4 层。

2.1 请求日志

记录：

• 本次风控请求是谁发起的
• 是什么场景
• 基础上下文是什么

例如：

• request_id
• scene_code
• user_id
• device_id
• ip
• biz_order_id
• trace_id

这一层主要是“入口事实”。

2.2 命中明细日志

记录：

• 哪条规则命中了
• 具体命中了哪个条件
• 命中时的阈值和实际值

例如：

• 规则：login_fail_cnt_10m > 5
• 实际值：7
• 阈值：5

这一层主要解决“为什么命中”。

2.3 决策汇总日志

记录：

• 最终风险等级
• 最终处置动作
• 最终命中的规则集合
• 是否走了降级

这一层主要解决“最终为什么这样处理”。

2.4 处置执行日志

记录：

• 是否发验证码
• 是否落了人审
• 是否触发二次校验
• 是否被人工放行

这一层主要解决“决策之后真正执行了什么”。

很多系统做乱，就是把这四层全塞进一条日志里。

结果：

• 结构越来越臃肿
• 有的字段只在某些场景有值
• 检索和聚合分析都很难做

三、按表结构来讲，应该怎么设计

3.1 请求日志表

CREATETABLErisk_request_log(idBIGINTPRIMARYKEY,request_idVARCHAR(64)NOTNULL,trace_idVARCHAR(64),scene_codeVARCHAR(32)NOTNULL,biz_order_idVARCHAR(64),user_idVARCHAR(64),device_idVARCHAR(64),ipVARCHAR(64),channel_codeVARCHAR(32),request_timeDATETIMENOTNULL,ext_json JSON,created_atDATETIMENOTNULL);

这张表的价值是：

• 让你先把这次请求定位出来

3.2 命中明细日志表

CREATETABLErisk_rule_hit_detail(idBIGINTPRIMARYKEY,request_idVARCHAR(64)NOTNULL,scene_codeVARCHAR(32)NOTNULL,rule_idBIGINTNOTNULL,rule_codeVARCHAR(64)NOTNULL,condition_codeVARCHAR(64),feature_codeVARCHAR(64),feature_valueVARCHAR(256),threshold_valueVARCHAR(256),hit_resultTINYINTNOTNULL,hit_reasonVARCHAR(512),created_atDATETIMENOTNULL);

这张表的重点是：

• 不只记录“哪条规则命中”
• 还记录“为什么命中”

3.3 决策汇总日志表

CREATETABLErisk_decision_log(idBIGINTPRIMARYKEY,request_idVARCHAR(64)NOTNULL,scene_codeVARCHAR(32)NOTNULL,final_risk_levelVARCHAR(32),final_actionVARCHAR(32),hit_rule_countINT,hit_rule_codes JSON,feature_snapshot_refVARCHAR(128),degraded_flagTINYINTDEFAULT0,decision_versionVARCHAR(64),created_atDATETIMENOTNULL);

这里面比较关键的字段是：

• final_action
• hit_rule_codes
• feature_snapshot_ref
• decision_version

3.4 处置执行日志表

CREATETABLErisk_action_execute_log(idBIGINTPRIMARYKEY,request_idVARCHAR(64)NOTNULL,action_codeVARCHAR(64)NOTNULL,action_resultVARCHAR(32)NOTNULL,operator_typeVARCHAR(32),operator_idVARCHAR(64),action_timeDATETIMENOTNULL,ext_json JSON);

这张表很适合记录：

• 自动处置
• 人工审核
• 人工放行
• 人工驳回

四、特征快照怎么记：这是风控日志里最容易偷懒，也是最容易后悔的地方

4.1 为什么一定要有特征快照

因为风控判断依赖的值是会变的。

比如：

• 10:00 的时候login_fail_cnt_10m = 7
• 10:20 再去查，就不是 7 了

如果你只记：

• 命中了login_fail_cnt_10m > 5

却不记：

• 当时的值是 7

那你后面根本没法还原现场。

4.2 快照不要无脑全量

很多人一听“特征快照”，就想把所有上下文、所有特征全塞进去。

这样会有两个问题：

• 日志太大
• 存储成本太高

所以更稳的做法一般有两种。

方案 A：只存本次决策实际用到的关键特征

例如：

{"login_fail_cnt_10m":7,"device_user_cnt_30m":4,"ip_req_cnt_1m":26}

优点：

• 成本低
• 足够支持绝大多数复盘

方案 B：快照单独存储，日志里只存引用

例如：

• 日志表里存feature_snapshot_ref
• 大的 JSON 单独落对象存储 / Elasticsearch / ClickHouse 明细表

优点：

• 主表更轻
• 大字段不会拖累常规查询

我在项目里更常见的是：

• 决策主表只存引用
• 明细或对象存储保完整快照

五、同步写什么、异步写什么：别让日志拖慢主链路

这块很关键。

5.1 建议同步写的

• 请求日志
• 决策汇总日志

因为这两层是最核心的审计凭证，最好跟主流程同事务或同请求一起成功落地。

5.2 建议异步写的

• 命中明细日志
• 处置执行扩展日志
• 大字段特征快照

因为这些字段通常更多、更重，完全同步写会拖 RT。

5.3 一个比较稳的实践

主链路内：

• 写请求日志
• 算规则
• 写决策汇总日志

异步链路：

• 发 MQ
• 消费后写命中明细
• 写快照和扩展行为

这样做的好处是：

• 核心信息不丢
• 明细信息不拖慢主链路

六、日志到底支持哪些业务场景，这个要提前想清楚

如果你不知道日志最后要被谁用，就会写成“技术自己觉得有用”的样子。

我建议至少考虑 4 类使用方。

6.1 研发排障

他们最关心：

• request_id
• trace_id
• 哪条规则命中
• 有没有降级

6.2 运营复盘

他们最关心：

• 哪个场景拦截变多了
• 哪条规则最近命中率异常
• 哪类用户误伤明显

6.3 客服 / 申诉处理

他们最关心：

• 用户为什么被拦
• 有没有人工审核入口
• 是否存在历史放行记录

6.4 数据分析 / 回放平台

他们最关心：

• 是否有完整样本
• 是否有特征快照
• 是否能按规则 / 场景 / 人群做统计

如果一套日志同时覆盖不了这些场景，那它很可能只是“写了”，但没真正发挥价值。

七、查询和分析怎么做：OLTP 表和分析表不要混

线上日志天然既要：

• 快速查单个请求
• 也要做大范围聚合分析

所以我一般不建议只靠一套 MySQL 表硬扛。

7.1 在线查单请求

适合：

• MySQL / TiDB / PostgreSQL

用途：

• 输入request_id
• 立刻查出这次决策链路

7.2 大规模分析

适合：

• ClickHouse
• Elasticsearch
• Hive / Doris / StarRocks

用途：

• 哪条规则近 7 天误杀率变高
• 某场景挑战率有没有异常抬升
• 某版本上线前后命中率怎么变

线上常见做法是：

• 主日志先进事务库
• 再异步同步到分析存储

八、数据保留策略怎么定：不是所有日志都要永久热存

风控日志往往量很大。

如果你全都放在线热库里，成本会很快失控。

一个更实际的策略是：

8.1 热数据

例如保留：

• 最近 7 天 / 15 天

用于：

• 日常排障
• 最近申诉处理

8.2 温数据

例如保留：

• 最近 3 个月

用于：

• 运营分析
• 阶段复盘

8.3 冷数据

例如保留：

• 6 个月 / 1 年

用于：

• 审计
• 重大投诉追溯

不同层日志的保留期也不一样：

• 决策汇总日志可以更久
• 命中明细和大快照可以相对短一些

九、隐私和脱敏别漏掉，不然日志越全越危险

风控日志里很容易有敏感字段：

• 手机号
• 身份证
• 银行卡
• IP
• 设备标识

建议至少做：

• 展示脱敏
• 按角色控权限
• 导出审计
• 明细查询留痕

尤其是：

• 客服能不能看全字段
• 运营能不能导出原始快照

这些都要提前定好。

十、我在项目里会怎么落这套日志体系

如果让我从 0 到 1 搭，我一般会这么做：

10.1 先定 request_id 贯穿策略

所有表都必须能通过：

• request_id

串起来。

10.2 再定最小可复盘集

我会先保证下面这些一定有：

• 请求日志
• 决策汇总日志
• 命中规则明细
• 关键特征快照

10.3 再加异步扩展层

包括：

• 处置执行日志
• 人工审核操作日志
• 申诉反馈结果

10.4 最后再做分析同步

不要一开始就冲着“百万级报表”去设计，先保证单次决策能查清楚。

十一、常见坑位，我按真实排障问题给你总结

11.1 只记最终动作

结果：

• 用户问为什么被拦，回答不了

11.2 没记特征快照

结果：

• 过一小时再查，值已经变了

11.3 日志全塞一个 JSON

结果：

• 单次排障还凑合
• 大规模分析非常难

11.4 没有版本信息

结果：

• 规则升级后效果变了，却说不清到底是哪个版本造成的

11.5 主链路同步写太多

结果：

• 风控本身的日志系统反而把业务 RT 拖慢了

十二、面试里怎么讲，才像真做过风控日志系统

如果被问：

风控命中日志和决策日志怎么设计？

你可以按这个顺序答：

1. 先说分层
   请求日志、命中明细日志、决策汇总日志、处置执行日志拆开。

2. 再说快照
   决策依赖的关键特征一定要留快照，否则事后无法复盘。

3. 再说同步异步
   请求和决策日志同步落，明细和大快照异步写。

4. 再说查询和分析
   主库支持按 request_id 查单次请求，分析库支持规则命中率、误杀分析、回放样本提取。

5. 最后说治理
   要带版本号、traceId、权限控制和保留周期策略。

这样答，面试官能明显感受到你考虑过真实使用场景。

十三、结语

风控日志真正的价值，不是“写了多少字段”，而是：

• 用户投诉时能不能解释
• 运营复盘时能不能分析
• 规则升级时能不能回放
• 出现误杀时能不能追到根因

如果只记一个原则，我建议记这句：

风控平台最怕的不是拦不住，而是“拦住了却解释不清”，所以日志体系一定要为复盘和审计服务。

下篇预告

如果你愿意，我下一篇可以继续按这个粒度往下写：

• 风控规则回放平台：样本池、回放任务、结果对比怎么做
• 风控误杀分析：从样本归因到阈值调优怎么落地
• 风控灰度发布：策略版本、流量放量、回滚怎么设计

评论区告诉我你更想先看哪块，我继续往下拆。