1. 資損盲區(qū)

隨著有贊支付體量的增大，資產(chǎn)部門承擔(dān)的資金管理，風(fēng)險把控的責(zé)任也越大。我們一方面要小步快跑，快速支撐業(yè)務(wù)，又要穩(wěn)住底盤，守好底線。支付業(yè)務(wù)底線就是守護用戶的每一分錢，不能有資金損失。在我們搭建這套體系前，有贊支付資金類的線上監(jiān)控是個盲區(qū)，缺乏自我發(fā)現(xiàn)的能力。業(yè)務(wù)成功了，但內(nèi)部對用戶的資金操作可能是錯誤的，導(dǎo)致資損。而且故障發(fā)生到發(fā)現(xiàn)的時間很長，且大部分是用戶上報，導(dǎo)致故障的影響面擴大，用戶的信任度降低。

預(yù)防資損有很多種手段，除了事前線下通過各種測試手段保障資金安全外，線上也是非常重要的一環(huán)。除了發(fā)現(xiàn)問題，相應(yīng)的，出現(xiàn)故障時，資損止血的能力也需要配套跟上。

舉一個最基本的支付業(yè)務(wù)場景，在有贊內(nèi)部會經(jīng)歷以下幾個系統(tǒng)之間的交互

1.jpg

通過上圖可以看出每個系統(tǒng)的處理結(jié)果，會依據(jù)系統(tǒng)建立的模型存儲在數(shù)據(jù)庫中，部分關(guān)鍵信息會傳輸給下層系統(tǒng)。系統(tǒng)之間處理的重要信息如金額、賬戶不一致就會導(dǎo)致資損。目前我們也內(nèi)部對賬會發(fā)現(xiàn)這些問題，但是內(nèi)部對賬都是每天跑批執(zhí)行一次。如果依靠內(nèi)部對賬來發(fā)現(xiàn)這個問題，資損早就發(fā)生了。需要調(diào)用很大的人力物力去追款，大部分情況下還追不回來。我們分析了有贊近一年來的資損場景，結(jié)合歷史的經(jīng)驗，總結(jié)出資損類故障發(fā)生有幾下幾大類:

1）有正確的輸入，錯誤的輸出：比如系統(tǒng)與系統(tǒng)之間的金額存儲單位不一致，或者自己處理金額正確，傳輸給下游的金額錯誤，導(dǎo)致后面交易金額錯誤；
2）上下游系統(tǒng)的數(shù)據(jù)不一致：該處理的沒處理，該到達終態(tài)的單據(jù)沒有到達終態(tài)；
3）冪等控制失效，多扣款或多入賬；
4）系統(tǒng)內(nèi)部邏輯錯誤，無對外輸出；
5）人工修復(fù)異常場景，產(chǎn)生資損。

2. 資損體系的誕生

基于解決以上問題的目的，我們設(shè)計了實時防控資損體系。總體設(shè)計思路圍繞以下幾點：

1）發(fā)現(xiàn)問題的實時性，減少故障的影響面；
2）信息流一致性兩兩比對、資金流平衡型檢查；
3）全方位監(jiān)控：業(yè)務(wù)觸發(fā)、人工變更資金檢測、歷史數(shù)據(jù)檢測；
4）檢測的準(zhǔn)確性，無誤報；
5）和支付鏈路解藕，不影響主鏈路。

平臺能力是基礎(chǔ)，檢測規(guī)則是其靈魂?；趯I(yè)務(wù)的豐富經(jīng)驗，我們可以沉淀一些業(yè)務(wù)資金規(guī)則，從旁路來約束和檢測系統(tǒng)邏輯的正確性。比如支付金額-退款金額應(yīng)該==結(jié)算金額，退款金額不能大于支付金額，憑證支付、現(xiàn)金支付無資金流類型不用調(diào)用賬務(wù)，支付和賬務(wù)之間會經(jīng)過結(jié)算的處理，賬務(wù)累計出入金額和支付的金額應(yīng)該要相等。

3. 系統(tǒng)設(shè)計：

3.1 總體設(shè)計的架構(gòu)圖如下：

2.png

系統(tǒng)定位于事前線下測試環(huán)境兜底，事中一致性檢測，事后資金兜底，不對業(yè)務(wù)造成入侵，完全旁路運行。觸發(fā)點有 2 個，業(yè)務(wù)事件消息和數(shù)據(jù)庫變更 binlog 信息。

分三類信息處理：

1. 基于各個業(yè)務(wù)事件比如支付完成事件、退款完成事件、確認收貨時結(jié)算完成事件，賬務(wù)收支明細變更事件等，觸發(fā)運行系統(tǒng)內(nèi)配置的依賴此事件的規(guī)則；
2. 通過監(jiān)聽 binlog 變更，可以檢測到人為操作類變更, 按定義好的邏輯生成對應(yīng)的檢查點，每個檢查點有包含多個鏈路檢測。觸發(fā)對應(yīng)的規(guī)則運行檢測全鏈路數(shù)據(jù)的一致性、資金的平衡性；
3. 人工處理歷史數(shù)據(jù)前，對歷史數(shù)據(jù)的質(zhì)量進行前置檢測。保證不產(chǎn)生二次資損。
   通過系統(tǒng)間兩兩核對數(shù)據(jù)一致性，或者抽象出系統(tǒng)內(nèi)的業(yè)務(wù)規(guī)則、資金規(guī)則旁路自檢來發(fā)現(xiàn)故障。并且實時獲取數(shù)據(jù)，實時運行，對于業(yè)務(wù)處理上有滯后和緩沖的場景，我們提供了異步運行的機制，以及三次重試的機會。全面提供系統(tǒng)整體的容錯性，無因系統(tǒng)設(shè)計問題導(dǎo)致的誤報。

3.2 處理流程圖如下：

3.jpg

經(jīng)過系統(tǒng)的沉淀之后，我們將過程中的數(shù)據(jù)存儲到了 hbase，把整個支付過程落地成了可視化試圖，可清晰的查看每個環(huán)節(jié)的數(shù)據(jù)形態(tài),具體數(shù)據(jù)就不展示了。
比如一筆訂單可以看到，當(dāng)前已經(jīng)是退款完成狀態(tài)，對應(yīng)的支付成功時支付、結(jié)算、計費、賬務(wù)數(shù)據(jù)形態(tài)：

4.png

退款完成環(huán)節(jié)支付、結(jié)算、計費、賬務(wù)數(shù)據(jù)形態(tài)：

5.png

3.3 資金熔斷：

熔斷的處理流程圖如下：

6.png

基于我們之前建立的異常發(fā)現(xiàn)能力，同時我們需要具備資金止損能力。建立后臺觸發(fā)熔斷操作入口，人工錄入熔斷配置或資損防控檢測出異常新增并生效熔斷配置，應(yīng)急情況生效熔斷，日常支付鏈路不會過熔斷判斷。
熔斷支持按業(yè)務(wù)碼緯度、指定的單號、商戶號熔斷；
目前我們在業(yè)務(wù)方接入的熔斷埋點有 3 個點：退款、結(jié)算、出金。為什么考慮這三個地方埋點呢？

1. 我們整個系統(tǒng)的定位都是不侵入主鏈路，對用戶無感知的，所以支付環(huán)節(jié)不考慮埋點。且錢不能流出有贊的體系外，一旦流出則無法追回。
2. 在支付鏈路產(chǎn)生的故障，考慮在退款、結(jié)算環(huán)節(jié)來做攔截，且支付完成后，錢停留在有贊的中間戶，此時訂正支付鏈路數(shù)據(jù)，對商戶來說無感知。
3. 一旦在結(jié)算環(huán)節(jié)出現(xiàn)問題，則考慮最后一道兜底，出金報送銀聯(lián)前進行攔截。
   確認無誤或故障處理完成后，觸發(fā)解熔斷操作，業(yè)務(wù)繼續(xù)處理或駁回。

4. 總結(jié)：

建立了這一整套體系后，半年時間內(nèi)，我們已經(jīng)在線下環(huán)境聯(lián)調(diào)時就成功兜底資金處理 bug，線上也避免了多起問題。并定期的進行故障演練來檢測平臺能力。
本文主要介紹大體的設(shè)計和實現(xiàn)思路，后續(xù)會有詳細的技術(shù)細節(jié)介紹，敬請期待。資損防控路漫漫，共勉。