引言
網際網路時代，萬物互聯，網絡安全形勢越來越嚴峻，安全是企業的基石，風控在企業中扮演着“警察”角色，運用各種技術和手段，保護企業内的使用者利益不受侵害。
風控決策引是風控中台的入口，提供業務風險場景事件接入，可視化編排複雜決策，豐富的特征變量與場景識别服務等功能。相較于需要開發背景及算法背景才能使用的傳統風控引擎，本文介紹的決策引擎建構完成後無需開發背景甚至無需算法模組化背景，作為純正的政策營運即可配置應用到業務的決策中，實時對抗黑産。
決策引擎分解
風險事件
風險事件對應一個風險領域，是針對特定業務事件領域的具體抽象，以友善政策營運人員管理領域下對抗規則使用的。
舉例：假設要對裂變類營銷場景防控，如分享目前内容到朋友圈即可獲得 88 元精美禮品一份，那麼風險領域可以大緻劃分為發起分享（發起頻率/作弊）、接受分享（同人/群組/頻率）、分享後領獎（頻率/群組/歸因群組），每一步對應的被風險特征不同，需要專有的政策部署防控。
決策流
如上，風控團隊人員和業務團隊人員充分溝通後，大緻已經知道了業務玩法的風險點，即可以明确劃分出“風險事件”。那麼如何高效且穩定的去管理目前領域下的風險對抗政策，是對風控研發的一大挑戰。
政策營運人員為了對抗黑産，每時每刻都需要變更防控手段，且時效性要高，即期望立即生效。那如何能夠讓生産改動安全且高效的部署到線上？早期團隊為了快速疊代，使用 XML 模式更改，好處是擴充性高，壞處顯而易見：隻能研發代替政策人員修改決策流配置，政策人員不了解或者根本不太敢動 XML “代碼”。
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<process id="p001" desc="×××">
<start>
<condition to="split01"/>
</start>
...
<split id="split01" desc="×××">
<condition order="0" desc="REJECT" expr="1 != 1" to="end01"/>
<condition order="10" desc="ACCEPT" to="split02"/>
</split>
...
<end id="end01" desc="×××" assemble="×××"/>
</process>
随着團隊的擴大，有了專業的 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 制定一整套防崩模式，確定系統穩定。
異動監控
監控是老生常談了，但是真的很重要！試想如果不對某個場景下決策的拒絕結果做監控，萬一線上因為某個改動導緻大量拒絕，使用者無法正常往下走，想想都很可怕！
總結
往期精彩
- 性能優化必備——火焰圖
- 我是怎麼入行做風控的
- Flink 在風控場景實時特征落地實戰