| 本文轉載自【美團安全應急響應中心】公衆號，歡迎大家關注。
在互聯網時代，安全已經成爲企業的命脈。美團信息安全團隊需要採用各種措施和手段來保障業務安全，從而確保美團平臺上的用戶和商戶利益不會受到侵害。
本文主要介紹了美團在打造自有規則引擎Zeus（中文名“宙斯”）的過程中，信息安全團隊遇到的挑戰以及對應的解決方案，並分享了很多踩過的坑，同時還有一些思考和總結。希望對從事安全領域相關工作的同學能夠有所啓發或者幫助。
背景
美團App每天都面臨着各類的欺詐、盜號、作弊、套現以及營銷活動被惡意刷單、惡意搶佔資源等風險。而業務安全團隊採用的主要措施和手段就是在業務請求中識別出誰、在什麼時間、通過什麼方式、做了什麼事。這個識別邏輯的制定過程叫做策略的生產。同時，還要對已經完成生產的策略進行快速的驗證和落地，以防止風險變化後策略失效。從發現風險經過策略生產、驗證，再到最終的落地部署，全流程的處理速度和效果將決定整個業務的成敗。
在業務發展初期，我們可以通過硬編碼的方式將風控邏輯部署在業務邏輯中實現，但美團的業務比較複雜，從最初的團購形式，經過與大衆點評、摩拜、貓眼等業務的融合，發展到涵蓋餐飲、到店、貓眼、外賣、金融、酒店、旅遊、大交通等多個垂直領域。隨着業務的快速發展，適用於初期的硬編碼方式出現了策略分散無法管理、邏輯同業務強耦合、策略更新迭代率受限於開發、對接成本高等多種問題。此時，我們需要有一套可配置化的規則管理平臺，進而實現風控策略與業務解耦、快速部署、驗證。
但規則引擎的建設初期，會面臨着各種困難和挑戰，主要包括以下幾個方面：
-
在業務層面：垂直領域多，包含幾乎所有的吃喝玩樂服務。美團細分業務多達百個。服務用戶角色多（用戶、商戶、供應商、渠道商），交易頻率高，日訂單量大。
-
在風險層面：存在用戶作弊、商家刷單、賬號盜用冒用、支付和信貸等多種風險。
-
在企業外部環境層面：黑產已形成自下而上的產業鏈，攻擊方式升級比較快速。
針對以上這些挑戰，我們打造了自有的規則引擎 Zeus（中文“宙斯”，來源於“宙斯盾”作戰系統的啓發，期望規則引擎平臺能同“宙斯盾”一樣成爲先進的中央作戰決策系統，實現對風險的精準、高效打擊）。
下面，我們就來具體介紹一下，美團信息安全團隊在系統構建過程中面臨的挑戰以及對應的解決方案。
挑戰與方案
1.業務多-接入成本高
規則引擎最早只是業務系統中的一個函數，逐步演化成了獨立的服務。而這個獨立服務與業務後臺的交互是單點方式，即業務後臺在關鍵動作節點前調用規則引擎，判斷“有沒有風險”。但這樣每次新增加一個業務或新出現一個風險場景時，規則引擎和業務都要重新進行對接聯調。頻繁地調整給上下游團隊都帶來了不小的負擔，而且在頻繁的更改中，系統質量也難以保證。如何便捷、快速地實現業務接入是系統設計的核心目標之一。
在接入成本上，一次性集中接入往往是最便捷的方式。因此我們選擇在每個業務都會通用節點接入規則引擎，例如：用戶中心、商戶中心、訂單中心、收銀臺等均爲各類業務的通用節點，規則引擎同這些通用節點對接，業務在調用通用節點時，通用節點調用規則引擎即可完成業務的接入。
隨着美團業務和場景種類的增多，現在也存在不經過通用節點的業務。因此，我們需要提供通用的接入接口，目前業務側直接調用一個獨立服務接口即可獲得風控判斷。
2.風險點多-邏輯複雜、邏輯複用
風險點多且業務多，進一步增加了場景、策略邏輯的複雜度。表達式語言可支持的邏輯計算範圍有限，複雜的邏輯若仍通過硬編碼實現，會存在效率低、不易複用等問題。
受模塊化思維啓發，我們將複雜的邏輯封裝成模版，實現配置化，並支持邏輯複用。這樣就大大提升了規則引擎可實現的邏輯範圍。目前，我們已經建設的幾類常用的封裝邏輯如下：
（1）擴展函數：主要用於數據格式的提取和處理，比如字符串、數組等格式轉換、數據提取等。通過擴展函數功能，對業務側數據格式要求大大降低，也降低了業務側數據處理的負擔。
（2）累計因子：在業務中會高頻使用到與累計相關的邏輯。例如，在登陸、下單、支付等事件需要同IP的UserID進行計數計算，計算結果作爲特徵引用在規則中。規則引擎引入了內部研發的高效事件計數服務，實現累計通用邏輯的封裝，比如支持累計週期、計數/求和/最近幾次、累計值等計算邏輯配置化等等。
（3）決策表因子：部分業務中需要引擎處理的判斷條件較多，各條件又相互組合，存在多種決策方案的情況，這就需要用精確、簡潔的方式來描述這類複雜邏輯。在低頻使用時，我們可以通過硬編碼的case-when、if-else等語句實現，但在實時性和配置化上不盡人意。最終，我們通過決策表將多個獨立的條件和多個動作直接地聯繫、清晰地表示出來，並實現了邏輯的封裝。
（4）名單庫因子：與名單庫聯動過程中，將查詢名單的邏輯進行封裝。
（5）工具因子：將一堆規則進行打包形成大的邏輯集合，並對組成的規則設置評分。在執行時輸出評分結果並實現跨場景、跨業務應用，同時將大邏輯進行“黑盒”處理，簡化邏輯複用時的配置、溝通成本。
風險點多的另一個挑戰點是在多業務中會存在同質性，即制定的風險策略是可複用的。當一百條規則需要複用在幾十個場景中，逐個配置的效率太低，不僅一致性難以保障，後續的修改也是問題。同時又衍變出部分複用、部分差異化，讓業務直接複用場景行不通。因此，我們引入【規則組】的概念，將規則聚類管理。比如衆包識別規則組、虛假設備規則組、涉黃內容識別規則組等。業務在應用時，可在自己的場景中進行差異化的應用。
3 風險變化快、長期對抗-效果驗證速度
當外部風險變化時，風控的對抗也需要及時響應，這是一個爭奪“主導權”的比賽。風控通過對不同階段的組合打擊，實現策略的健壯性，包括用於識別有沒有風險的基礎對抗階段、引導節奏混淆視聽的“短平快”階段、誘敵深入的“高精尖”階段。對應系統需要支持不同階段的策略配置、迭代和驗證需求。而在策略迭代和部署階段，需要特別注意因配置錯誤導致的誤命中問題。
參考開發環境分類：測試環境、預發佈環境和生產環境。規則引擎在規則的部署和迭代上，可通過標記、雙跑和回溯功能，我們通過應用實時線上流量和歷史數據來驗證策略的有效性。
標記：規則在場景中的狀態，標記狀態的規則邏輯將灰度執行，即：與生效規則類似會實時執行，但決策信息不實時返回給上游業務方，不影響決策。同時用戶可在實時日誌查詢中查看標記規則的命中情況。
雙跑：規則在場景中的狀態，雙跑狀態的規則邏輯將灰度執行，但僅會出現在修改生效規則、因子（因子修改導致引用規則的邏輯執行變化）時，纔會存在的狀態。
回溯：規則在場景中的狀態，回溯狀態的規則邏輯將灰度執行，但僅使用回放的歷史數據。
通過這些功能，可以降低策略迭代的風險，縮短策略部署上線的時間週期。
思路總結
在確認清楚挑戰和解決方案之後，規則引擎的整體建設思路就已經形成了。現今，規則引擎隨着業務的快速擴張，由一個內部系統逐漸發展爲服務多個風控團隊的公共平臺。
從初期主要圍繞風控防控痛點進行搭建的表達式服務包，升級到配置化平臺，在配置效率和執行效率也得到了很大的提升。同時，隨着人工智能技術的應用和風控對抗進入白熱化，規則引擎也將從配置化快速迭代至自動化、智能化。
1.確定核心快速論證、快速落地
在系統建設中，進行了充分的論證後就需要快速落地，避免因長項目週期需求發生裂變而導致不可控。在初期，我們已經建立了aviator表達式服務包並穩定服務。因此，配置化平臺搭建時仍基於表達式語言，引入場景、規則、因子、決策等概念搭建，將策略的執行分爲執行層和計算層。
執行層：通過場景獲得一堆規則集合，規則執行完成後將其結果和對應的決策返回。
計算層：在規則執行時會進行其構成因子計算。
2.根據角色，進行定向提效
規則引擎搭建的初衷之一是提升風控對抗的整體效率。在對抗過程中，我們需要各種角色配合，例如開發建設系統、策略制定者、策略使用者和風險用戶等，因此需要針對各類角色定向開展提效工作。
（1）風險用戶處理提效（風險用戶）
業務已經可以實時獲得風控的決策，但發現風險用戶會在很多場景下重複攻擊。對這類用戶的處理，除了對當次行爲阻斷，還要阻斷其未來的行爲，因此就有名單管理的訴求。我們通過與名單庫的聯動，提升該類用戶的處理效率。
例如：在美團金融項目場景下，嚴重逾期的用戶會加入禁貸名單，再次申貸時取消其貸款資格。
（2）業務接入提效（業務方）
除了上面介紹的統一接入外，還有一種常見的情況：業務無法在發起請求時就將執行所需要的全部參數準備好，此時就需要引擎能主動獲取外部數據。針對這類情況，規則引擎通過數據接口的方式實現了外部數據的補充，在策略執行時根據計算需要動態獲取相關的參數。在實現與外部數據聯動的功能後，大大降低了使用規則引擎業務方數據準備階段的壓力，從全部參數準備簡化爲僅提供核心參數即可，剩餘參數按需引擎自行調度即可。
（3）策略管理提效（產品）
策略產品是規則引擎的主要用戶，主要的工作流程是圍繞策略管理、分析、驗證進行提效。如何管理大量的規則和應用場景？怎樣快速驗證策略有效性、評估誤傷率？客訴反饋問題，如何快速還原規則命中情況？針對這些維度，我們分別提供不同的產品功能進行提效。
在策略管理層面，可通過規則組方式、因子工具等，進行同類規則集合的管理、打包和複用。
在規則分析層面，可通過實時查詢規則的執行詳細數據和將規則執行流程進行回放提升分析效率。
在策略驗證層面，提供標記、雙跑和回溯提升策略驗證速度。
（4）工程效率提效（工程師）
複雜的邏輯且具有通用性就可以對特徵邏輯封裝，避免工程師重複進行邏輯開發工作，釋放出的開發資源可以進行其它維度的提效。
（5）算法/模型接入提效（算法工程師）
當對抗升級時，策略的產生者由人變爲算法/模型。而機器的生產效率遠遠高於人，人工搬運算法/模型會成爲迭代效率的瓶頸，怎樣跟算法、模型平臺進行快速聯動呢？最簡單、快速的方式就是使用引擎提供的外部數據聯動方式，將模型結果包裝成數據接口使用。但在實踐過程中，我們發現模型的出入參數較多且存在變化，整體的配置化效率低，模型應用和迭代頻率受限制。公司內部提供的深度學習還是算法工程平臺，目前主攻計算、訓練等場景，在上下游應用提供標準化的數據產出，但無法同類似引擎的平臺對接。
因此，僅聚焦在引擎與算法平臺的聯動上，可通過建設調度模塊實現：1.訓練樣本預處理-->2.算法平臺對接-->3.自動化生成接口-->4.自動註冊接口/策略至引擎-->5.評估任務啓動-->6.評估結果處理（策略上下線、樣本數據沉澱）-->1.訓練樣本預處理的閉環流程。
3.發現問題、橫向擴展、兼容更多場景
隨着引擎在多業務場景的應用，我們發現幾個實時引擎不好處理的場景。比如拉新場景，需要結合“註冊+登陸+交易”等多種行爲來判斷是否有“薅羊毛”等黑灰產行爲，需要將很多事件放到一起去綜合判定。當發現風險時，或在當前時間點漏過的變異風險在發現之後，需要對歷史數據進行回撈，這些在實時引擎中都不太好實現。當前已有的異步引擎也無法很好地進行覆蓋。爲了避免做“重複造輪子”的事情，團隊充分地討論了實時、異步和離線引擎的定位和服務邊界。
在實時引擎已經覆蓋的邏輯基礎上，我們引入新的封裝邏輯-個體因子，全局因子實現SQL語句的配置化管理，進而實現批量累計、聚合特徵的計算，比如：近一年某商家的平均下單金額，近30天商戶大盤下單均值，標準差等批數據的複雜邏輯。並基於Spark和實時引擎底層，實現多流和批數據的處理，解決上述場景無法處理的一些問題。
4.業務實踐結果
-
交易安全
策略產品在日常工作中，通過對業務分析發現風險、挖掘風險特徵並應用在策略中。通過Zeus實現策略的部署和應用，大大降低了業務風險，提升風險防控效率。例如：在某業務地推場景中發現B、C端聯合刷單風險，以返利、送贈品收到誘騙下單。
-
金融安全
金融風控主要有反欺詐和信用安全。反欺詐同業務安全在策略形態上相同，都是判斷有無風險，在決策結果上是通過和拒絕。因此，通過普通決策即可滿足業務需求。
但信用安全會比前兩者複雜一些，在決策上，除了通過和拒絕外，對於通過的請求要進行分層實現金融的差異化定價。因此，需要在規則引擎中引入更多功能，來滿足業務需求。主要包括：
路由場景：可支持多層，決策流模式，即一堆規則的集合，支持按照邏輯進行分流，滿足指定條件可以指定走向在每個節點進行條件設置，實現最終流向。例如：對於某分期場景用戶申請一筆貸款，需要經過欺詐識別、信用評估後方可給出最終的額度、定價。
決策衍生參數：適用於複雜的多級路由決策場景Key-Value型數據，在決策中指定衍生參數信息從而在路由場景中產生全局傳遞變量，比如：流轉過不同的場景需要將用戶進行等級分類。
決策附加信息：適用於複雜決策場景Key-Value型數據，在決策中指定附加信息從而實現更多決策信息的計算及返回，比如：加入風控名單庫，加入什麼風險類型、風險等級、名單類型。
未來發展與思考
目前規則引擎正處於配置化階段，正在向自動化、智能化的階段發展，從而不斷提升策略的管理和迭代的速度。但業務間的智能化訴求和進程不同，平臺可以提供更多集成託管服務，從而提升各業務的智能化覆蓋度。
其次，引擎仍然存在無法處理的幾個問題：
一些長時間週期特徵無法快速應用的問題，例如近一年的時間週期。如何將離線引擎和實時引擎在特徵計算上組合，實現特徵的快速生產、驗證和應用，從而擴展引擎的計算能力範圍、提升風控業務的對抗效率。
當前引擎的接入對非複雜邏輯需求的業務就比較重。而接入成本是各業務接入時重點評估的因素，如何實現快速、低成本的業務接入（包括技術接入和人員操作接入），考慮提供模塊化的引擎計算服務能力適用於各類業務訴求，實現按需接入，比較“臃腫”的全局接入會更快速和便捷。但這種在引擎側怎樣更好地管理這些模塊，也是一個挑戰。
最後，業務流量和策略的增長速度仍在高速增長，引擎的穩定性和策略管理效率也需要持續提升。
踩過的坑
1.如何實現產品功能高聚合架構上低耦合
規則引擎建設時兼容各類業務場景，具備了極高的靈活性，同時自身也相對複雜。從頂層的路由場景到底層的參數（路由場景-場景-規則組-規則-決策-因子-參數-數據接口-參數）每一個節點、節點間都是由用戶配置的，在產品上期望用戶的操作流程是連貫的，在一個操作流程中解決儘量多的問題。系統架構上，包括配置層、執行層、計算層、數據獲取層等，各層之間相互依賴，對最終引擎的輸出結果負責，底層上需要儘量的解耦合，纔將降低單模塊對引擎的影響。但在實踐中，隨着業務訴求的增多，慢慢就出現來產品上的低耦合、架構上的高耦合情況。
例如：在用戶修改生產策略時的強制更新流程優化項目中 ，就涉及了這個問題。在產品功能上用戶修改策略-->雙版本策略並行執行-->兩版本數據覈驗-->修改完成；但在系統架構上，上述的產品流程就產生了系統架構高耦合，即生產修改雙版本問題，配置層、執行層、計算層高度耦合。項目一期上線後在性能上、後續功能擴展性上都有瓶頸。隨後，技術項目優化配置層的緩存模式，採用增量更新方式。產品功能上增加用戶進入修改模式後修改。重新立項後，實現了用戶修改流程閉環、系統架構上僅配置層兼容雙版本，執行層和計算層無耦合。
因此，在產品功能設計上除了用戶閉環操作外，還需要考慮是否低耦合。在技術優化時需要前瞻性的開展去耦合項目。
2.如何平衡系統複雜度與業務需求
隨着接入業務的增多，又需要兼容新業務定製化需求，就面臨這一個問題：定製化的功能不具有通用性，大量定製功能將加重平臺的複雜度。這個問題一直困擾引擎建設團。，目前，我們採用的也許不是最優但比較有效的辦法。主要通過定、判、看Gap，將業務需求轉化爲系統模塊升級功能和非系統功能：
-
定：重新定義“定製和通用”。在現實中有些定製化需求其實是業務速度已經遠遠領先於其它業務，所有需求看上去是定製化，實際上是未來可預見性的問題。
-
判：將業務需求進行分類，判斷需求是針對主幹流程還是分支節點。
-
看Gap：需求同當前建設情況比對差距。
對於系統模塊升級功能，可逐個完成。對於非系統功能，可通過提供公共對接服務的外掛來實現。
3.特別需要“防呆”設計
人工操作會存在各類誤操作引起的風險問題，在產品設計上，用戶操作簡潔的初衷是好的，但需要增加防止錯誤發生的限制方法。在實踐中這些“防呆”設置大大降低了人工誤操作Case，例如：
-
業務高峯期封版--->禁止業務高峯期時變更策略。
-
降低無邏輯驗證的誤傷情況-->策略上線前，強制標記驗證執行是否符合業務預期；修改生產上應用的策略，強制雙跑驗證修改後的邏輯執行是否符合業務預期。
-
降低邏輯配置錯誤機率-->策略部署時強制測試邏輯正確性。
-
慣性操作-->驗證數據結果強制回填等。
4.產品功能最佳實踐的意外驚喜
要承認一個事實就是，最瞭解功能使用的可能不是規則引擎的產品經理。在規則引擎的建設中出現了這樣的”驚喜”，例如：
（1）規則組功能建設初期目標是實現規則的高效管理、複用。在A業務場景基於規則組除實現規則的高效管理、複用外，還實現了決策計算。但這種用法在隨着其業務的發展複雜度增加，已經不再利於策略高效管理，目前還在尋找更優的解決方案。
（2）累計因子的功能是將對多條請求進行計數或求和邏輯進行封裝。B業務基於上述功能上還是實現了事件行爲記錄、多事件時序性累計和攔截行爲的累計。目前在其業務下廣泛使用並有效地識別了跨事件風險。
總結而言，做好業務定期應用回訪和應用監控是非常有必要的。
---------- END ----------
招聘信息
美團信息安全部正在招聘實習生，業務方向包括：安全\後端開發\機器學習算法\自然語言處理\風控策略\數據開發\Web前端\測試開發\產品經理\產品運營\安全與隱私合規等。工作地點：北京/上海。歡迎感興趣的同學發送簡歷至：[email protected]（郵件標題註明：美團信息安全團隊）
也許你還想看
