[[173485]]

上一篇《搭建風控系統道路上踩過的坑01--信息采集》我們介紹了第一點，如何去獲取足夠多的數據，而接下來的事情就是要創建一個機制去靈活的處理這些信息，為自動分析捕捉風險事件提供基礎原料，進而借助規則引擎從中分析出風險事件。

在開始前，我們還是回顧下業務風控主要做的四件事：

[[173486]]

1.拿到足夠多的數據

2.做足夠靈活的分析平臺去分析數據

3.產出風險事件進行阻攔風險

4.量化風險攔截的價值和不斷分析案例進行策略優化

接下來，同樣的有三件事情需要考慮：

1.讓分析人員可以快速的查詢原始日志

日志并不是簡單的存下來，從風控分析的需求來看，通過IP、用戶名、設備等維度在一個較長的跨度中搜索信息是非常高頻的行為，同時還存在在特定類型日志，比如在訂單日志或者支付日志中按特定條件搜索的需求。

而這些主要是為了能夠讓分析人員可以快速的還原風險CASE，例如從客服那邊得到了一個被盜的案例，那么現在需要從日志中查詢被盜時間段內這個用戶做了什么，這個過程如果有一個界面可以去做查詢，顯然比讓分析人員用grep在一大堆文件中查詢要快的多，并且學習門檻也要低得多。

如果在日志做過標準化的前提下，也可以進行后續的業務語言轉譯，將晦澀難懂的日志字段轉化為普通員工都能看得懂的業務語言，也能極大的提升分析師在還原CASE時閱讀日志的速度。

2.實時或定時的計算加工消息成變量&檔案

例如在分析某個帳號被盜CASE的時候，往往需要把被盜期間登錄的IP地址和用戶歷史常用的IP地址進行比對，即使我們現在可以快速的對原始日志進行查詢，篩選一個用戶的所有歷史登錄IP并察看被盜IP在歷史中出現的比例也是一個非常耗時的工作。

再比如我們的風控引擎在自動判斷用戶當前登錄IP是否為常用IP時，如果每次都去原始日志里面查詢聚合做計算也是一個非常“貴”的行為。

那么，如果能預定義這些變量并提前計算好，就能為規則引擎和人工節省大量的時間了，而根據這些變量性質的不同，采取的計算方式也是不同的。不過還好我們有一個標準可以去辨別：頻繁、對時效敏感的利用實時計算(比如訪問頻率、時間間隔);而相對不頻繁、對時效不敏感的利用定時計算(比如用戶的常用IP、設備，即使少算短期內的登錄記錄，也不會受到太大影響)。

3.選擇規則引擎將人工策略自動運行

一個設計優雅的規則引擎是把分析師的經驗決策和數據最終轉化為風險輸出的核心模塊，首先說為什么需要規則引擎而不是選擇硬編碼邏輯——

筆者無數次遇到過這種場景，一個上午剛剛上線的策略，沒過1個小時，攻擊者或者欺詐者就已經試出繞過策略的方法了，如果你的風險控制邏輯是硬編碼，那么恭喜你，再走一遍開發測試發布流程。

快速響應是安全的生命線，無法想象還有比被攻擊者胖揍48小時然后才反應過來去擋臉更讓人沮喪的事情了。

所以策略引擎必須能把策略邏輯從業務邏輯中解藕出來，讓防御者可以靈活配置規則在靜默模式下驗證和實時上線生效，并可以去隨時調整。

類似的開源框架有很多，各有優劣，但如果需要降低學習曲線，必須進行一層包裝(這里又是一個比較大的話題，就先略過了)。

坑位標注：

1.Sharding會影響到你的策略

為了支持并發和性能，通常在利用集群計算變量的時候我們會用到sharding。

sharding方式會按IP把數據分配到不同的運算單元中去處理，在讀取結果的時候按IP去集群中的某臺機器中去拿數據，以大幅提升并發處理讀取計算結果的能力。

那么，現在如果我想去按某個USER去拿數據的時候，就會發現一個用戶在不同IP下的信息被保存在不同的服務器上了，所以單一的Sharding分配肯定是不合理的，這點必須要注意。

2.策略中用到的變量，能不用現場算的就不用

有些簡易的策略引擎設計中用到的變量都是到數據庫里現場算的，雖然可以極大的提升靈活性(新的變量不需要考慮歷史數據回補)，但會極大的影響穩定性和響應時長，尤其在業務請求爆發的時候幾乎都會出現宕機無響應的問題。

要知道業務研發對安全的結果并不是那么敏感，但如果出現了問題導致應用不穩定給人添麻煩，被拋棄可能就是早晚的事情，所以變量一定要盡量做到提前計算，并且設立緩存機制。

3.對風險分析要用到的計算資源有充分的認識

毫不夸張的說，合格的風險分析要做的實時、準實時計算量要大過應用內所有計算的總和甚至超過幾倍。

其實這也很好理解，比如一個典型登錄場景，業務要做的邏輯最主要的就是檢查密碼和帳號的身份是否吻合，而風控要把這登錄用戶的歷史檔案全部拉出來看個遍，然后根據風控策略來決定是否放行。所以在規劃風險分析要用到的資源時請不要吝嗇，按業務5X甚至10X的標準來評估風險分析的資源需求。

如果說信息采集主要看的是安全產品經理的溝通協調能力，設計風險分析功能更多的就是考驗安全產品經理的邏輯思維能力。

到了這樣一個階段，外部冗雜的溝通協調已經結束，但如何最大化利用前期打下的基礎，需要對風險問題的分析、決策過程有一個非常清晰的認識，這里也有一個比較好的標準來去檢驗：

分析平臺設計的差，那么就只有設計者自己會用;

設計的好，你會發現處理投訴的客服、分析師都會很樂意來用你的分析平臺為他們解決問題。

結語

下一篇我們會繼續介紹如何把分析出的風險結果自動快速的進行阻斷，歡迎繼續支持我們。如果你在這方面遇到了難點，歡迎留言和我們溝通交流，如果對接下來的內容感興趣，請分享鼓勵一下小編，我們會盡快給出后續的章節。

作者介紹

劉明 豈安科技聯合創始人，首席產品技術官

超過6年的風控和產品相關經驗，曾就職網易，負責《魔獸世界》中國區賬戶體系安全。現帶領豈安互聯網業務風控團隊為客戶提供包括了明星產品Warden和RED.Q的風控服務。