摘要：所以，把本人踩過的一些坑在這里分享出來，讓準備搭建風控的人心里有個數(shù)。這種配合周期非常長，但可以按照標準來拿到高質(zhì)量的信息，所以是比較常見的風控系統(tǒng)搭建方式。

從業(yè)近10年，大大小小參與了3家公司不同領(lǐng)域的風控系統(tǒng)的設(shè)計，從前到后把風控系統(tǒng)所有環(huán)節(jié)都細細的琢磨過，然而至今仍然感覺剛剛一只腳踏進門而已。

大多數(shù)人做的產(chǎn)品都是目的明確的，比如訂單支付、賬戶體系要做什么一開始就知道了，而且也有很多的競品可以去參考；風控系統(tǒng)卻完全不一樣——未來要面對什么問題不可能完全了解，做每個功能都謹小慎微，因為一個不注意走錯了方向，可能就會在未來的某個階段要全盤推翻。

而對于研發(fā)資源緊缺的安全需求來看，往往會在某個時間把自己擺到一個非常尷尬的境地，問題解決不了，改造又面臨大量的時間和溝通成本。

所以，把本人踩過的一些坑在這里分享出來，讓準備搭建風控的人心里有個數(shù)。

業(yè)務(wù)風控主要做四件事：

拿到足夠多的數(shù)據(jù)

做足夠靈活的分析平臺去分析數(shù)據(jù)

產(chǎn)出風險事件進行阻攔風險

量化風險攔截的價值和不斷分析案例進行策略優(yōu)化

拿數(shù)據(jù)這件事幾乎是決定風控系統(tǒng)成敗的核心，由于篇幅問題我們先主要說這點，主要有三件事要考慮：

1 拿到的數(shù)據(jù)越詳細越好：

拿賬號安全這件事來舉例子，如果能拿到基礎(chǔ)的登陸注冊數(shù)據(jù)，就可以從頻率、登陸注冊特征來進行分析；

如果可以進一步拿到登陸注冊行為的上下文，比如登陸前訪問了哪些頁面，登陸后去訪問了什么，就可以從訪問行為軌跡來增加更多的分析維度，例如頁面停留時間，是否有訪問到必訪問的頁面等；

如果還可以拿到用戶的操作行為數(shù)據(jù)，比如鼠標移動的軌跡，鍵盤輸入，那么可以進一步的從操作過程來增加分析維度，比如是不是輸入密碼的時候有過多次輸入刪除？是不是直接復(fù)制粘貼的賬號密碼？

2建立標準的日志格式：

確認好能拿到哪些數(shù)據(jù)以后，就要開始建立標準的日志格式。
常見的登陸、注冊、下單、密碼修改、綁定憑證修改等等都要給出一個標準的日志格式，而且要充分考慮到字段命名的統(tǒng)一，比如密碼、用戶名字段的名稱如果在不同的日志中叫法不統(tǒng)一，在后續(xù)分析和指定策略的時候都會遇到不小的麻煩。

3拿到的數(shù)據(jù)質(zhì)量：

必要的字段是否都能拿到？

往往風控關(guān)心的信息比如IP地址、UserAgent、referer這些信息業(yè)務(wù)都是不關(guān)心的，但這些信息的缺失可能造成很多策略沒法做，所以在采集信息開始的時候就要有個明確的信息列表，一旦妥協(xié)了后面再去返工讓研發(fā)加是會遭白眼的。

數(shù)據(jù)信息拿的是否準確？

比較常見的是需要用戶的訪問IP，結(jié)果拿到的IP地址是內(nèi)網(wǎng)的服務(wù)器IP；或者是想要用戶名，結(jié)果傳遞過來的是UID。這點需要大量的前期溝通確認工作，一旦上線了以后發(fā)現(xiàn)數(shù)據(jù)不對再改也同樣要遭白眼。

拿數(shù)據(jù)有主動方式和被動方式兩種：

1主動方式

主動方式是自己去數(shù)據(jù)庫、日志里面去讀。
這種方式實時性比較差，而且基本有什么拿什么，想加信息是比較難的，但不需要研發(fā)配合太多事情，適合喜歡自己動手豐衣足食的場景。
當然有些比較成熟的公司有自己的消息總線，風控可以去實時的訂閱信息然后作為數(shù)據(jù)源進行分析，但這種通常為少數(shù)；

2被動方式

被動方式就是提供接口給研發(fā)，讓業(yè)務(wù)把消息按格式標準噴過來。
這種配合周期非常長，但可以按照標準來拿到高質(zhì)量的信息，所以是比較常見的風控系統(tǒng)搭建方式。

1號坑：

如果拿消息是多數(shù)據(jù)源的時候，必須要考慮到消息的時間序問題：
比如登陸日志是公共服務(wù)發(fā)過來的，網(wǎng)頁訪問是拿的access_log，用戶操作行為數(shù)據(jù)是頁面JS或者SDK發(fā)過來的，那么這三者的時間是不一致的。
這就必須要在確認所有的消息到位之后再進行分析判斷。否則，如果實時策略考慮了登陸的時候必須有頁面鍵盤點擊，而兩個數(shù)據(jù)到位的時間不一致，就可能出現(xiàn)大量的誤封造成事故。

2號坑：

對采集回來的數(shù)據(jù)必須定期的對數(shù)據(jù)質(zhì)量進行監(jiān)控——
已經(jīng)采集到的數(shù)據(jù)可能因為技術(shù)架構(gòu)調(diào)整，代碼更新等各類奇葩原因造成采集回來的數(shù)據(jù)不準了，如果無法及時發(fā)現(xiàn)可能造成后面一系列分析過程都出現(xiàn)錯誤。

3號坑：

采集點盡量選擇穩(wěn)定的業(yè)務(wù)點，比如采集登陸日志，一次性在公共服務(wù)采集好，后面出現(xiàn)問題只要找一個點。
如果是去前端從WEB、移動端等各個調(diào)用登陸服務(wù)的點去采集，出了問題要改動的工作就會成倍增加，還有可能出現(xiàn)新業(yè)務(wù)點的日志無法覆蓋的情況。

4號坑：

關(guān)于技術(shù)選型：
消息隊列是必須的，用restful只能處理業(yè)務(wù)日志比如登陸這種1秒最多幾次的類型，如果后期要去采集頁面訪問行為這種一秒上千的消息就必須要用到隊列.
開源的可以考慮RabbitMQ或者Kafka,穩(wěn)定性都還不錯。

5號坑：

關(guān)于日志存儲：
ELK是不錯的選擇，為后續(xù)的分析平臺提供基本的查詢功能。
信息采集往往是實施風控的最難的一個環(huán)節(jié)，但也是最重要的環(huán)節(jié)，覆蓋、質(zhì)量、時效都決定了項目的成敗。

在獲取足夠多的數(shù)據(jù)之后，接下來的事情就是要創(chuàng)建一個機制去靈活的處理這些信息，為自動分析捕捉風險事件提供基礎(chǔ)原料，進而借助規(guī)則引擎從中分析出風險事件。
接下來，同樣的有三件事情需要考慮：

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

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

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

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

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

例如在分析某個帳號被盜CASE的時候，往往需要把被盜期間登錄的IP地址和用戶歷史常用的IP地址進行比對，即使我們現(xiàn)在可以快速的對原始日志進行查詢，篩選一個用戶的所有歷史登錄IP并察看被盜IP在歷史中出現(xiàn)的比例也是一個非常耗時的工作。
再比如我們的風控引擎在自動判斷用戶當前登錄IP是否為常用IP時，如果每次都去原始日志里面查詢聚合做計算也是一個非常“貴”的行為。

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

3選擇規(guī)則引擎將人工策略自動運行

一個設(shè)計優(yōu)雅的規(guī)則引擎是把分析師的經(jīng)驗決策和數(shù)據(jù)最終轉(zhuǎn)化為風險輸出的核心模塊，首先說為什么需要規(guī)則引擎而不是選擇硬編碼邏輯——
筆者無數(shù)次遇到過這種場景，一個上午剛剛上線的策略，沒過1個小時，攻擊者或者欺詐者就已經(jīng)試出繞過策略的方法了，如果你的風險控制邏輯是硬編碼，那么恭喜你，再走一遍開發(fā)測試發(fā)布流程。

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

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

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

1、Sharding會影響到你的策略

為了支持并發(fā)和性能，通常在利用集群計算變量的時候我們會用到sharding。
sharding方式會按IP把數(shù)據(jù)分配到不同的運算單元中去處理，在讀取結(jié)果的時候按IP去集群中的某臺機器中去拿數(shù)據(jù)，以大幅提升并發(fā)處理讀取計算結(jié)果的能力。
那么，現(xiàn)在如果我想去按某個USER去拿數(shù)據(jù)的時候，就會發(fā)現(xiàn)一個用戶在不同IP下的信息被保存在不同的服務(wù)器上了，所以單一的Sharding分配肯定是不合理的，這點必須要注意。

2、策略中用到的變量，能不用現(xiàn)場算的就不用

有些簡易的策略引擎設(shè)計中用到的變量都是到數(shù)據(jù)庫里現(xiàn)場算的，雖然可以極大的提升靈活性（新的變量不需要考慮歷史數(shù)據(jù)回補），但會極大的影響穩(wěn)定性和響應(yīng)時長，尤其在業(yè)務(wù)請求爆發(fā)的時候幾乎都會出現(xiàn)宕機無響應(yīng)的問題。
要知道業(yè)務(wù)研發(fā)對安全的結(jié)果并不是那么敏感，但如果出現(xiàn)了問題導(dǎo)致應(yīng)用不穩(wěn)定給人添麻煩，被拋棄可能就是早晚的事情，所以變量一定要盡量做到提前計算，并且設(shè)立緩存機制。

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

毫不夸張的說，合格的風險分析要做的實時、準實時計算量要大過應(yīng)用內(nèi)所有計算的總和甚至超過幾倍。
其實這也很好理解，比如一個典型登錄場景，業(yè)務(wù)要做的邏輯最主要的就是檢查密碼和帳號的身份是否吻合，而風控要把這登錄用戶的歷史檔案全部拉出來看個遍，然后根據(jù)風控策略來決定是否放行。所以在規(guī)劃風險分析要用到的資源時請不要吝嗇，按業(yè)務(wù)5X甚至10X的標準來評估風險分析的資源需求。

如果說信息采集主要看的是安全產(chǎn)品經(jīng)理的溝通協(xié)調(diào)能力，設(shè)計風險分析功能更多的就是考驗安全產(chǎn)品經(jīng)理的邏輯思維能力。

到了這樣一個階段，外部冗雜的溝通協(xié)調(diào)已經(jīng)結(jié)束，但如何最大化利用前期打下的基礎(chǔ)，需要對風險問題的分析、決策過程有一個非常清晰的認識，這里也有一個比較好的標準來去檢驗：
分析平臺設(shè)計的差，那么就只有設(shè)計者自己會用；設(shè)計的好，你會發(fā)現(xiàn)處理投訴的客服、分析師都會很樂意來用你的分析平臺為他們解決問題。

但是分析出來的東西不能光自己看著High，還得去阻攔這些風險才能真正產(chǎn)生業(yè)務(wù)價值。

到了第三步我們離整個系統(tǒng)核心框架的搭建就只剩一步之遙了，那么讓我們看看這個環(huán)節(jié)要考慮什么：

1、最終呈現(xiàn)給業(yè)務(wù)研發(fā)直白的判定結(jié)果

我們最終從數(shù)據(jù)中發(fā)現(xiàn)的報警和問題最終是要在業(yè)務(wù)邏輯中去阻攔的，在接入這些結(jié)果的時候，往往分析師覺得可以提供的信息有很多，比如命中了什么規(guī)則、這些規(guī)則是什么、什么時候命中的、什么時候過期，其中最讓接入方心煩的當屬風險分值當仁不讓了，很多接入風控的研發(fā)看到這些分值就一腦袋包：你到底想讓我做什么，攔還是不攔？這時候如果你喏喏的再丟出個多少分值以上要攔，研發(fā)多半都會跟你說直接給我結(jié)果就好了。
是的，很多風控接口設(shè)計的都十分累贅，無用信息多到研發(fā)會覺得你在故意浪費帶寬，其實一個code list給他們說明對應(yīng)希望做的操作就好，一定把你覺得那些很牛逼的中間結(jié)果等等包裝成最終結(jié)果再給出去。

2、T＋0還是T＋1

舉個例子來解釋實時(T+0)和異步（T＋1）風險判斷的區(qū)別。

T+1
你在打拳擊比賽，選手A只會打臉，上來就照著你臉來了一拳，你分析了一下打臉很疼而且不科學(xué)，在第二拳往臉揮過來時你突然告知對方不可打臉，對方就成功的被你克制住了。這就是T+1的特點，至少要在第二次風險攻擊才可以生效；

T＋0

拳擊比賽第二場對陣選手B，同樣被打臉后你說不可打臉，對方說好，結(jié)果沖著肚子就來了一拳。你說禁止打肚子，對方又一拳打腋下。這時你發(fā)現(xiàn)要在對方揮拳馬上打到你之前就要禁止。
這就是T＋0了。
因為T＋0在接入的時候要額外承擔很多計算成本，結(jié)果要現(xiàn)場算出來而延時要求又很高，所以一般都只在攻擊者得手關(guān)鍵步驟采取實時判斷（比如訂單支付或者提現(xiàn)請求）。而對于其他場景可以選擇T＋1方式，比如登錄或者提交訂單等。

3、阻斷邏輯到阻斷產(chǎn)品

這一點我們豈安在對外演講的時候介紹過很多，在阻斷風險的時候事件發(fā)生的點是不同的，但短期又不可能讓業(yè)務(wù)研發(fā)在所有的地方接入風險阻斷怎么辦？
所以我們需要考慮幾個基本的保底措施，比如統(tǒng)一的驗證碼驗證頁面在IP層全局防止任何爬蟲腳本行為，在賬號層通過登錄態(tài)管理統(tǒng)一攔截單個賬號在登錄后任何風險行為（全局強制登出）。
可能這些措施在體驗上不是最好的，但是在發(fā)生特殊問題的時候要等研發(fā)給你臨時加阻斷邏輯這個時間就沒法控制了。

1、接入風控阻斷的邏輯位置

登錄的時候賬號輸入框鼠標失焦就要去走風控了，登錄結(jié)果出來之后再去判斷就沒意義，而資金相關(guān)的一般是在跳轉(zhuǎn)去收銀臺之前，你會發(fā)現(xiàn)一般風險判斷都是在結(jié)果出來之前（收集本次行為完整日志之前），所以如果你要做T+0判斷，就要求研發(fā)在進行風險判斷的時候要提供更完整的信息，而不是只給個IP或者賬號名就行了（往往T＋1就之要這些就夠）。

2、對業(yè)務(wù)流量充分調(diào)研并關(guān)注

平時可能流量很小的業(yè)務(wù)，突然因為某個活動（比如秒殺）流量大增，除了在接入之初要對風險判斷請求有了解，對后續(xù)的活動也要提前準備，否則如果資源預(yù)估不足，突然又趕上這個點接了T+0接口有很多要現(xiàn)場計算的邏輯，陡增的業(yè)務(wù)流量分分鐘教你做人。

3、bypass ！ bypass ! bypass

風控風險判斷的最基本原則就是要不影響業(yè)務(wù)邏輯，所以超時機制在一開始就要嚴格約定并執(zhí)行，一旦發(fā)現(xiàn)風控接口超過預(yù)計響應(yīng)時間立馬放行業(yè)務(wù)請求。

4、讓一線同事們知道你在做什么

任何風控準確率都不是100%的，所以在和研發(fā)溝通好接入后一定要告訴一線同事們風控阻斷可能出現(xiàn)的表象，以及大致的原因，以避免一線客服們對風險攔截的投訴不知道如何解釋，并給出具體的阻斷回復(fù)措施（加白名單、刪除黑名單等等，上帝們在某些日子比如315維權(quán)意識是非常強的）。

阻斷是最終產(chǎn)生真實價值的環(huán)節(jié)，另外也是關(guān)聯(lián)部門最敏感的環(huán)節(jié)（嚇唬我半天逼著我把風控接了，結(jié)果一天到晚給我出毛病？生產(chǎn)環(huán)境是給你們玩的？！），請保護這至關(guān)重要的信任，你后面會越做越順的。

風控系統(tǒng)和大部分的產(chǎn)品項目一樣，最終需要對領(lǐng)導(dǎo)層匯報這個項目為公司帶來了什么價值，這是評估項目成功與否的要素；

另外是哪里做的不夠好，如果改善了能帶來更多的價值，給出了預(yù)期才有后續(xù)資源的補充，整個項目才能轉(zhuǎn)起來形成一個良性循環(huán)。

現(xiàn)在開始說說這個系列的最后一話：如何對風控系統(tǒng)進行效果評估與優(yōu)化。
我們看一下這個環(huán)節(jié)要考慮的：

1.找到錢在哪里
風控項目的基本價值在于省錢，而省錢的思路基本有三種：直接攔截風險帶來的止損（比如提前阻止了一筆欺詐交易所挽回的損失）；提升服務(wù)穩(wěn)定性所帶來的業(yè)務(wù)基本指標提升（比如因阻止風險事件所降低的服務(wù)響應(yīng)延時而提升的業(yè)務(wù)轉(zhuǎn)化）；降低服務(wù)不可用概率事件所帶來的直接業(yè)務(wù)損失（比如降低了風險事件導(dǎo)致服務(wù)宕機所帶來的營收損失）。

可以看出這三點是按風險事件的暴力程度做出的簡單劃分，其實也還有很多其他不同的視角來分類，很大程度上和對應(yīng)企業(yè)的互聯(lián)網(wǎng)業(yè)務(wù)形態(tài)有關(guān)。

而我們做這樣劃分的目的是為了：在一開始就明確風控項目從哪里可以挖掘效益。
很多情況下風險事件不是一個獨立的問題，而是一個鏈條，由一些看起來影響不大的問題逐層深入。比如，交易欺詐并不是一個獨立的問題，而是因為注冊環(huán)節(jié)發(fā)生的垃圾注冊問題攻擊者手里有了大量的賬號所導(dǎo)致的，所以任何一個風險問題都是有價值的。
無利不起早，作為風險分析者應(yīng)當有能力找到其中的關(guān)聯(lián)轉(zhuǎn)化關(guān)系，并預(yù)測對方的得手點進行效果評估會有更好的效果。

2.有效利用預(yù)期價值的力量

天下沒有100%準確的風控策略，所以在接入攔截的過程中業(yè)務(wù)方可能存在種種阻力，往往的一個誤區(qū)是沒有攔截就認為風控沒有效果。
其實，效果評估不只是在最后項目落地評估價值所用，在推行項目中間也有很好的效果，雖然沒有攔截，但預(yù)期效果放在那里，這對決策者平衡業(yè)務(wù)影響有著重要的價值。

3.學(xué)會考慮企業(yè)財務(wù)目標

風控系統(tǒng)并不是一個可有可無的東西。其實大部分企業(yè)中安全已經(jīng)是業(yè)務(wù)的必要組成部分了，那么我們知道在資源有限、而業(yè)務(wù)風險問題無限的情況下，所有的資源投入都必然有一個優(yōu)先級，而這個優(yōu)先級與整個企業(yè)發(fā)展的現(xiàn)狀必須是牢牢捆綁在一起的。
講簡單些：風控系統(tǒng)解決什么問題，評估出的效果與企業(yè)目前業(yè)務(wù)關(guān)心的問題息息相關(guān)。
如果企業(yè)目前的業(yè)務(wù)重點在一次年度促銷活動，那么風控的重點就應(yīng)當在促銷羊毛黨；如果企業(yè)目前面臨嚴重的賬戶盜用投訴問題，那么重點就應(yīng)在賬號安全。尤其在風控系統(tǒng)啟動之初，配合系統(tǒng)的需求交付時間選擇對應(yīng)的重點問題，對于項目效果的評估是一個巨大的加分項，切記一開始就貪大貪全。

4.策略的生命周期和健康度

風控系統(tǒng)的規(guī)則有多少？哪些已經(jīng)很久沒有觸發(fā)了？產(chǎn)生誤判投訴的對應(yīng)規(guī)則有哪些？一個新規(guī)則在建立起初的效果肯定是最有效的（因為這時風險問題正在發(fā)生，而規(guī)則正好對應(yīng)了風險），但隨著時間其有效性是呈快速下降的趨勢。
比如，攻擊者都知道網(wǎng)站三次輸入密碼錯誤觸發(fā)驗證碼，他們會傻傻的嘗試第三次猜測密碼的概率有多大？那么，是否有人在定期的去統(tǒng)計分析這些規(guī)則的效率？這就是風控產(chǎn)品的重要運營環(huán)節(jié)了。
而運營風控產(chǎn)品所要付出的代價，往往大于常規(guī)互聯(lián)網(wǎng)業(yè)務(wù)產(chǎn)品，并且是保證項目能夠持續(xù)產(chǎn)出價值并不斷迭代進化的一個前提。

業(yè)務(wù)風控是一個非常具有挑戰(zhàn)性的項目，我一直把它比作一種競技游戲，而這種攻防不同于傳統(tǒng)安全（在傳統(tǒng)安全你并不能有足夠的技術(shù)能力預(yù)測所有人的攻擊方法），它更強調(diào)邏輯和預(yù)測——
攻守雙方在一個雙方充分了解的環(huán)境下（業(yè)務(wù)邏輯簡單到任何人都可以理解，但又可以產(chǎn)生無數(shù)的變化和組合）不斷的博弈。

而這正是業(yè)務(wù)風控系統(tǒng)的樂趣所在。

業(yè)務(wù)風險問題足夠簡單而又足夠復(fù)雜，正是這樣的原因其參與攻擊者并沒有太高的門檻限制。處于國內(nèi)互聯(lián)網(wǎng)的環(huán)境下，任何一家企業(yè)都不可能逃開業(yè)務(wù)風險問題的影響。
作一個比喻，這片土壤是有著自己的一些特質(zhì)的，企業(yè)如果是生長在這片土壤中的一顆樹，投入足夠的養(yǎng)分才能快速生長，而業(yè)務(wù)風險則是寄生于樹木竊取養(yǎng)分的角色，只有能夠充分抵御這種風險的才能成長為參天大樹。

作者介紹 劉明  豈安科技聯(lián)合創(chuàng)始人，首席產(chǎn)品技術(shù)官 超過6年的風控和產(chǎn)品相關(guān)經(jīng)驗，曾就職網(wǎng)易，負責《魔獸世界》中國區(qū)賬戶體系安全。現(xiàn)帶領(lǐng)豈安互聯(lián)網(wǎng)業(yè)務(wù)風控團隊為客戶提供包括了明星產(chǎn)品Warden和RED.Q的風控服務(wù)。