上一章《搭建風控系統道路上踩過的坑01–資訊採集》我們介紹了第一點，如何去獲取足夠多的資料，而接下來的事情就是要建立一個機制去靈活的處理這些資訊，為自動分析捕捉風險事件提供基礎原料，進而藉助規則引擎從中分析出風險事件。
在開始前，我們還是回顧下業務風控主要做四件事：
1、拿到足夠多的資料
2、做足夠靈活的分析平臺去分析資料
3、產出風險事件進行阻攔風險
4、量化風險攔截的價值和不斷分析案例進行策略優化
接下來，同樣的有三件事情需要考慮：
一、讓分析人員可以快速的查詢原始日誌
日誌並不是簡單的存下來，從風控分析的需求來看，通過IP、使用者名稱、裝置等維度在一個較長的跨度中搜尋資訊是非常高頻的行為，同時還存在在特定型別日誌，比如在訂單日誌或者支付日誌中按特定條件搜尋的需求。
而這些主要是為了能夠讓分析人員可以快速的還原風險CASE，例如從客服那邊得到了一個被盜的案例，那麼現在需要從日誌中查詢被盜時間段內這個使用者做了什麼，這個過程如果有一個介面可以去做查詢，顯然比讓分析人員用grep在一大堆檔案中查詢要快的多，並且學習門檻也要低得多。
如果在日誌做過標準化的前提下，也可以進行後續的業務語言轉譯，將晦澀難懂的日誌欄位轉化為普通員工都能看得懂的業務語言，也能極大的提升分析師在還原CASE時閱讀日誌的速度。
二、實時或定時的計算加工訊息成變數&檔案
例如在分析某個帳號被盜CASE的時候，往往需要把被盜期間登入的IP地址和使用者歷史常用的IP地址進行比對，即使我們現在可以快速的對原始日誌進行查詢，篩選一個使用者的所有歷史登入IP並察看被盜IP在歷史中出現的比例也是一個非常耗時的工作。
再比如我們的風控引擎在自動判斷使用者當前登入IP是否為常用IP時，如果每次都去原始日誌裡面查詢聚合做計算也是一個非常“貴”的行為。
那麼，如果能預定義這些變數並提前計算好，就能為規則引擎和人工節省大量的時間了，而根據這些變數性質的不同，採取的計算方式也是不同的。不過還好我們有一個標準可以去辨別：頻繁、對時效敏感的利用實時計算（比如訪問頻率、時間間隔）；而相對不頻繁、對時效不敏感的利用定時計算（比如使用者的常用IP、裝置，即使少算短期內的登入記錄，也不會受到太大影響）。
三、選擇規則引擎將人工策略自動執行
一個設計優雅的規則引擎是把分析師的經驗決策和資料最終轉化為風險輸出的核心模組，首先說為什麼需要規則引擎而不是選擇硬編碼邏輯——
筆者無數次遇到過這種場景，一個上午剛剛上線的策略，沒過1個小時，攻擊者或者欺詐者就已經試出繞過策略的方法了，如果你的風險控制邏輯是硬編碼，那麼恭喜你，再走一遍開發測試釋出流程。
快速響應是安全的生命線，無法想象還有比被攻擊者胖揍48小時然後才反應過來去擋臉更讓人沮喪的事情了。
所以策略引擎必須能把策略邏輯從業務邏輯中解藕出來，讓防禦者可以靈活配置規則在靜默模式下驗證和實時上線生效，並可以去隨時調整。
類似的開源框架有很多，各有優劣，但如果需要降低學習曲線，必須進行一層包裝（這裡又是一個比較大的話題，就先略過了）。
坑位標註：
1、Sharding會影響到你的策略
為了支援併發和效能，通常在利用叢集計算變數的時候我們會用到sharding。
sharding方式會按IP把資料分配到不同的運算單元中去處理，在讀取結果的時候按IP去叢集中的某臺機器中去拿資料，以大幅提升併發處理讀取計算結果的能力。
那麼，現在如果我想去按某個USER去拿資料的時候，就會發現一個使用者在不同IP下的資訊被儲存在不同的伺服器上了，所以單一的Sharding分配肯定是不合理的，這點必須要注意。
2、策略中用到的變數，能不用現場算的就不用
有些簡易的策略引擎設計中用到的變數都是到資料庫裡現場算的，雖然可以極大的提升靈活性（新的變數不需要考慮歷史資料回補），但會極大的影響穩定性和響應時長，尤其在業務請求爆發的時候幾乎都會出現當機無響應的問題。
要知道業務研發對安全的結果並不是那麼敏感，但如果出現了問題導致應用不穩定給人添麻煩，被拋棄可能就是早晚的事情，所以變數一定要儘量做到提前計算，並且設立快取機制。
3、對風險分析要用到的計算資源有充分的認識
毫不誇張的說，合格的風險分析要做的實時、準實時計算量要大過應用內所有計算的總和甚至超過幾倍。
其實這也很好理解，比如一個典型登入場景，業務要做的邏輯最主要的就是檢查密碼和帳號的身份是否吻合，而風控要把這登入使用者的歷史檔案全部拉出來看個遍，然後根據風控策略來決定是否放行。所以在規劃風險分析要用到的資源時請不要吝嗇，按業務5X甚至10X的標準來評估風險分析的資源需求。
如果說資訊採集主要看的是安全產品經理的溝通協調能力，設計風險分析功能更多的就是考驗安全產品經理的邏輯思維能力。
到了這樣一個階段，外部冗雜的溝通協調已經結束，但如何最大化利用前期打下的基礎，需要對風險問題的分析、決策過程有一個非常清晰的認識，這裡也有一個比較好的標準來去檢驗：
分析平臺設計的差，那麼就只有設計者自己會用；
設計的好，你會發現處理投訴的客服、分析師都會很樂意來用你的分析平臺為他們解決問題。
作者介紹
劉明 豈安科技聯合創始人，首席產品技術官
超過6年的風控和產品相關經驗，曾就職網易，負責《魔獸世界》中國區賬戶體系安全。現帶領豈安網際網路業務風控團隊為客戶提供包括了明星產品Warden和RED.Q的風控服務。