一、為什么要做資損防控

二、如何做資損防控

三、資損防控產出階段

四、如何挖掘及度量資損防控規則

五、如何選擇資損實現方式

六、如何做資損防控運營

    1. 迭代需求運營

    2. 如何做資損規則保鮮

    3. 如何做資損規則日清SOP

七、資損防控實踐及收益

八、總結及規劃

一、為什么要做資損防控

隨著互聯網電商平臺競爭的加劇，各平臺的業務復雜度不斷提升，線上環境的穩定性面臨更大挑戰。在匯金領域，由于其高資金屬性，除了確保鏈路可用性達到99%以上，防止資損亦成為關鍵保障事項。得物匯金業務涉及復雜的資金流和大額資金敞口，因此實施資損防控尤為重要。

• 防資損、資金安全

保障企業財務健康：資損防控措施能有效識別和應對風險，保護企業現金流和資產，維護股東投資收益。

降低風險敞口：面對市場波動和欺詐等風險，實施資損防控能顯著減少對企業財務的負面影響。

增強抵御危機能力：在經濟不確定或突發事件（如市場崩潰、疫情等）發生時，穩健的防控措施幫助企業保持資金流動性和安全性。

• 防客訴

提升客戶信任：資損防控有助于提高服務質量和客戶滿意度，降低資金管理不當造成的風險，從而增強客戶信任。

減少客戶投訴：不當的資金管理可能引發服務延誤和錯誤收費，良好的防控措施可避免這些問題，確保客戶順暢的服務體驗。

維護品牌聲譽：客戶投訴頻繁會影響品牌形象，實施有效的資損防控可保持良好的客戶關系，并促進長期發展。

經過不斷的演進與發展，我們已經沉淀出一套匯金資損防控體系的方法論，并在實踐中取得了一定成效。因此，我們希望通過知識梳理與分享，鼓勵大家共同交流學習，持續推進資損防控的提升與優化。

二、如何做資損防控

整體方案：

圖片

開展思路：

根據平臺特性，涉及到交易和資金流，就會考慮到是否會發生資損，那么如何避免產生資損，總結出一套適合業務特點的方法便成為資損防控的關鍵。匯金平臺和業界內的其他平臺采用的資損防控方法論基本一致，但是不同的每個階段所覆蓋的產出的內容不一樣。

圖片

從項目全生命周期來看，已發布時間和出現問題時間為時間點，發布時間前的階段為事前階段，出現問題的時間點為事中階段，出現問題后應急響應為事后階段。

• 事前

階段：項目發布前的時間段，在這段時間內會經歷需求評審、研發設計評審、測試用例評審、穩定性項目評審，我們要從4個關鍵事項對焦如何從需求、代碼、線上核對/監控等發現手段上做到防資損、及時發現資損問題。

關注的內容：需求層面，挖掘是否直接涉及資金流，或間接涉及資金流，如果涉及資金流，了解資金如何進行流轉，進而挖掘到資金流涉及的上下游。技術設計或編碼層面，實現資金計算的邏輯、計算公式，明確上下游之間的資金交互元素、金額/幣種/單位，持久化資金數據，異常監控報警邏輯，業務單據冪等邏輯，資金平衡校驗等。測試層面，從正常流程和異常流程驗證代碼實現邏輯是否符合預期，如資金計算、金額大小、方向、幣種、單位，上下游傳遞，數據存儲等，基于驗收通過后的邏輯編寫自動化，自動化要核對金額的正確性，用編寫自動化目的是為了沉淀資金場景的測試手段，為后續迭代改造的保證質量及提高效率。

• 事中

階段：生產環境出現問題的階段，對于不同的問題發現有不同要求，重資損鏈路要做到1分鐘發現，即系統出現問題后1分鐘發現，系統有告警。從系統告警后5分鐘內介入做出響應，即5分鐘內有人看到告警并進行跟進。所以重資損鏈路的問題要做到1-5。非資損鏈路可做到D+1發現，D+1介入和修復即可，相比資損鏈路而言，發現能力沒有太強要求。如果沒有問題的發現能力，最終可能會導致資損的慢性流血發生。不論線下環境如何測試，都很難保障測試環境100%覆蓋，所以線上問題的主動發現能力尤為重要。

關注的內容：系統出現問題后，是否有實時或者非實時的告警能力。對于告警內容，要根據業務優先級及系統實現，編寫實時/非實時核對腳本。如果業務復雜性高，可以編寫抽檢腳本，就是系統實現的重算邏輯，從旁路發現問題。那么如何驗證腳本有效性，發現問題是否進行報警，就要進行攻防演練。通過演練，可以檢查是否具備問題的能力，以及開發的響應能力，如果不達標，要進行改進和優化直到達標。

• 事后

階段：發現問題后的止血階段。一般分為兩方面：當前問題的扼制，不再新增問題；存量問題的解決。止血應急能力要有相應的預案或者建立新的應急能力。如果止血比較快，能降低問題的影響，如果止血比較慢，可能會擴大問題的影響，提高問題的嚴重等級。

關注的內容：對于資損問題要做到10分鐘的止血，從發現問題到消除增量問題產生，要在10分鐘內解決。對于存量問題的解決，可根據業務特性，在相應時效內修復即可。在修復前可以通過掛公告的方法，暫時消除或者降低問題事態的影響。對于比較核心或者比較固定的問題，可以形成執行預案，當發現問題后，可及時執行預案進行問題止血。對于比較復雜的業務，要根據不同的問題及時進行編碼修復問題。不管是進行代碼或者編寫預案代碼，如果涉及代碼修復，開發測試均要參與保證代碼的正確性。如果只是一個角色進行修復，可能會因為預案問題導致的二次事故發生。

三、資損防控產出階段

對于項目實施階段，當承接新功能、新建系統或者分析存量系統時，如何判定是否要做資損防控，可以從兩個角度出發分析：信息流或者資金流。資金流和信息流之間是相互依賴的。當業務需求中涉及資金流時，系統要實現業務需求，那么系統之間就要設計信息如何流轉最終完成資金流轉。當系統中存在資金字段的信息流時，可最終推導出直接或者間接的資金流。資金流通過信息流實現資金流轉，信息流是資金流轉的載體。所以當信息流中存儲或者涉及資金交互，資金傳遞時，就要做資損防控，分析資損場景及如何編寫資損腳本。

圖片

對于項目發布后階段，當項目前期如果沒有做資損防控，那么也可以從線上穩定性來看是否要做資損防控。一般可以從線上故障、線上工單等結果分析需要做的資損場景有哪些。從線上問題來看可以比較直觀的看到缺少哪些防控手段并做針對性的補充，這樣能起到立竿見影的效果。這種是從問題點切入的方法進行分析跟進，但比較好的做法是從面上進行分析，集合需求、問題全面分析，從多個點同時作為抓手判定資損防控的必要。

圖片

以上兩個方法，均在匯金域進行了實踐，在項目發布前和發布后都會進行資損防控補充。

四、如何挖掘及度量資損防控規則

當要實施資損防控時，如何挖掘實施資損規則變得尤為重要。當規則挖掘的不對或者偏少，不利于及時發現問題。當規則過多時，對規則的投入成本會變高，規則保鮮會成為挑戰，最終也會影響到發現問題的及時性。

那么如何比較全面的挖掘資損規則呢？目前匯金域從三方面切入，分析資損規則并推進資損防控覆蓋的成熟度度量。我們從這3方面進行資損規則分析并編寫規則腳本，完成資損布防。

• 資損字段覆蓋度量
• 業務指標覆蓋度量
• 跨域資金安全覆蓋度量

圖片

資損字段覆蓋【字段】

當系統鏈路涉及的數據庫有資損字段時，在Dcheck平臺上做資損字段標記，資損字段標記資損，非資損字段標記非資損。從字段上挖掘到要有資損規則覆蓋。當在Dcheck上編寫完對應規則后，要進行字段和規則的綁定，維護字段和規則之間的關聯關系，這樣也可以在報表上看出來資損字段是否有對應的線上布防能力。

字段層面覆蓋是比較簡單可以做到的資損規則分析，常見的資損字段如金額、幣種、單位、匯率、計算公式、數量、日期、狀態等。如果鏈路中涉及這些字段，都可以進行對應的規則實施和布防。一般此類字段覆蓋的規則可以通過實時核對實現，這種正確性時效要求比較高，如果存儲不正確也比較容易發現問題。資損字段覆蓋是比較入門并快速上手的手段，但不能作為發現全部資損問題的手段之一。除此之外，還需要通過其他方式挖掘規則。比如字段內容正確，但是其他指標異動方面較大有影響，這種從字段覆蓋層面無法發現問題。

業務指標/場景覆蓋【業務】

不同的業務域關注的指標不一樣，但可以通過觀測這些指標可以發現潛在的問題，進而避免可能產出的投訴或者擴大影響。常見的業務指標比如：時效性巡檢、成功率異動巡檢、失敗率異動巡檢、中間態異動巡檢或者其他指標異常巡檢。通過對這些指標的監控覆蓋，可以補全數據正確但系統有問題的發現手段。一般業務指標類的覆蓋時效性不高，非實時核對方式實現，可能是D+h或者離線D+1方式實現。

圖片

上下游資金安全覆蓋【跨域】

資損字段或者業務指標覆蓋，更多的是聚焦在內部的穩定性上面，對于和外部間資金覆蓋較少。當然資損字段可能也會涉及到外部之間的核對，但上下游之間的資金安全覆蓋會涉及更多，可能是直接的上下游資金覆蓋，或者全鏈路上的非直接上下游的資金場景覆蓋。常見場景如：下單支付場景，訂單域的支付金額和支付域的金額、狀態一致性check，各種費用項的一致性校驗；采購結算付款鏈路，付款場景下的金額要和采購結算單據的金額幣種保持一致等。通過在發生資金流轉的時間，做上下游資金安全check，能和業務側的金額做校驗，進而保證流轉的資金安全。

圖片

業務域度量探索實踐效果

• 建立核對場景分層覆蓋策略，圍繞字段/業務/跨域開展。
• 探索定義各層級的度量方法，并在各子域實踐落地，經過與對應功能開發owner對焦，確定了度量方式的有效性。

圖片

示例如下：子域2025Q1落地結果，核對覆蓋率100%（平臺配置采用率100%，共120+個業務場景，60+個跨域場景覆蓋率100%；資損字段30+個，核對覆蓋率100%）。

圖片

五、如何選擇資損實現方式

得物實現資損防控的平臺為Dcheck平臺，作為實現線上核對的平臺，支持資損場景核對或者非資損場景核對，從時效性上實現了實時核對或者定時巡檢，也支持配置變更的核對。數據源上支持監聽生產環境數據庫的binlog消息，連接離線數倉、連接業務庫。支持語言上可以用Groovy語言編寫核對腳本，離線數倉或者通用SQL編寫SQL腳本進行核對。同時支持對編寫的腳本進行演練，檢查腳本有效性。當發生報警后設置通知群@到具體人進行日清處理。業務域可以根據業務特性靈活選擇不同的實現方式滿足業務目標。平臺本身支持的能力比較多樣化，靈活性也比較強，支持各種變更的核對。

圖片

• 實時核對原理通過實時監聽binlog消息/自定義消息/實時數倉消息，觸發規則核對。監聽binlog和自定義消息的腳本要用Groovy實現，監聽實時數倉消息要用SQL實現，Groovy實現的規則會涉及到接口間調用，會出現超時發布導致調用不同的情況，穩定性有一定影響。用SQL實現相比起來更靈活更穩定。監聽實時數倉的前提是數據源要接入實時模版平臺。

圖片

• 定時巡檢原理定時巡檢是通過配置定時任務觸發核對，核對腳本可以通過離線SQL或者Groovy腳本實現，Groovy腳本可以連接業務數據庫，比實時核對有小時級別或者天級別的延遲。離線SQL的延遲就是D+1。對于時效性不高的規則場景可以使用此種方式。

圖片

• 核對方案選型

圖片

六、如何做資損防控運營

迭代需求運營

圖片

• 匯金獨立項目&迭代資損布防：日常迭代或者項目如果涉及到資損防控，有一套運營流程機制保證資損場景的分析及布防。

當需求涉及到資損時，會對需求進行打標標記。

在測試用例評審時，編寫資損場景及組織開發評審，保證場景有效性。

目前按照RDC“資”需求打標--->測試用例打標資損用例--->Dcheck規則實現--->用例平臺綁定Dcheck規則運營流程推進。

在測試前置階段完成資損用例分析，高優資損場景在預發、生產流量發布前完成資損布防，低優場景在放量一周內完成規則實現，分析到的核對場景布防率100%。

在生產環境有流量前實現資損規則并進行演練，推進上線狀態。當線上數據觸發報警時，有值班人員跟進日清，如果發現bug，會在系統上標記bug并進行bug修復。整體流程也會不斷進行復盤和review，提升資損防控的投入和產出價值。

• 研發測試分工：目前迭代或獨立項目通過Dcheck方式實現的資損場景主要是測試負責推進，一般在項目開展時或項目灰度前推進完成。涉及的資損場景，測試會邀請開發進行評審。對賬平臺實現的離線核對場景及實現主要是開發負責，一般偏于迭代測試周或者后續迭代進行開發實施，測試參與度低。

關于Dcheck規則報警，測試報警后會做初步排查，然后確定不是腳本問題后@對應的開發介入處理，開發負責協助進行問題分析，如果是代碼bug或者數據問題，開發進行緊急或者排期修復。

測試過程中，如發現資損風險，不適合Dcheck手段布防，開發添加監控。

• 資金SOP驗收執行：背景：匯金屬于強資金業務線，涉及的資金敞口大，資金流錯綜復雜，其資金安全對穩定至關重要。為規范資金需求類的產品研發流程，避免低級流程問題導致的資金安全問題，需規范各職責角色和產出，確保需求流轉過程中的高效協作和最終交付質量。驗收方案：整體流程如下：

圖片

如何做資損規則保鮮

• 保鮮策略：目前通過提出保險管理策略，平臺實現后，讓用戶發現規則的有效性和質量，及時發現僵尸規則，做到規則保險。

保鮮策略如下：

• 一段時間內核對失敗占比，時間支持選擇；
• 核對無執行記錄；
• 狀態為下線規則；
• 無演練記錄或者演練失敗的規則。

圖片

• 保鮮運營：保鮮功能Q4上線后，匯金域內完成存量僵尸規則治理。且隨著資損防控成熟度建設，場景規則有效性已作為成熟度指標之一，保鮮治理已隨迭代常態化運營。

子域1：下線24個規則，剩余規則全部有效

子域2：下線12個規則，剩余規則全部有效

子域3：下線8個規則，剩余規則全部有效

子域4：下線6個規則，剩余規則全部有效

子域5：下線6個規則，剩余規則全部有效

如何做資損規則日清SOP

明確目標及范圍：針對業務巡檢、實時核對報警，梳理告警跟進SOP，形成閉環處理問題流程，確保資損防控處理的高效性和處理一致性，提升日清率，降低誤報，提升有效問題發現。針對資損問題進行日清，同時也是資損成熟度的指標，隨迭代運營開展。非資損問題發生報警同時也會進行日清處理。

具體的操作步驟：說明資損防控告警運營的具體步驟，見下圖，需要清晰易懂，確保操作性強。

責任人：說明具體步驟對應的責任人，以及不同步驟需要知會的人，確保問題有效推進解決。

監督措施：定期評估SOP的實施效果，并進行必要的改進。監督機制的設計應該確保SOP的執行情況得到有效監督和管理，保障SOP的實施效果。

圖片

圖片

各步驟定義說明：

圖片

資損發現問題復盤模版：

圖片

示例：

圖片

七、資損防控實踐及收益

匯金域通過資損防控專項的實踐，不斷總結沉淀出一套體系化的方法：需求識別資損規則-->如何分析資損規則-->如何選擇實現技術。此方法可以降低人員對資損防控專項的學習門檻，提升學習效率。通過挖掘資損規則的方式，可以較快分析產出資損規則。通過學習實現方式，能較快的選取合適的實現方式，減少試錯成本。

自2024年全年至2025年5月共完成了520+個規則，發現了160+個問題。其中5+個問題為資損問題，155+個非資損問題。有效遏制了線上的資損發生和有效保障了線上穩定性。

圖片

利用Dcheck手段，降低客訴明顯。

• 核算&發票巡檢及發票接入配置化項目：通過不斷通過完善發票平臺線上巡檢，制定各類配置問題跟進的SOP，共產出8類配置巡檢規則，成功將配置等工單問題從15降到0且持續保持平穩。配置類問題線上問題主動發現率100%。
• 來自TS反饋：

圖片

• 子域有明顯下降趨勢，整體降低41%(業務咨詢減少&配置類治理有顯著效果)。

八、總結及規劃

經過匯金在資損防控專項的體系化建設及實踐，取得了顯著進展。從事前挖掘資損規則、代碼預防性建設，事中及時布防資損規則、巡檢規則、開發添加監控，事后及時執行預案以及補充未布防場景規則，以及經過各種挖掘資損方法的探索及分享，大部分員工具備資損防控意識和資損規則挖掘、布防、日清保鮮的能力。并且在整個推薦過程中，研發測試協同分工，共同保障及推進線上穩定性穩步提升。目前體系化流程已初見成效，后續除常態化運營繼續開展外，讓全員具備資損防控意識，同時也會重點治理以下環節中的痛點問題，不斷提升專項的ROI。

• 資損分析：AI資損場景分析目前資損分析從三層架構出發，沉淀了一定的規則規律邏輯，后面嘗試AI推薦資損場景分析，減少人工輸出成本。
• 腳本實現：通用SQL降噪目前通用SQL實現的腳本規則噪音比較大，因為Flink平臺底層數據存儲在Redis，當多表比對的時候，會出現單表查詢Redis超時，對比不一致的情況。后續嘗試支持重試或者其他方案降噪解決問題，減少噪音干擾和降低人工成本。
• 降噪歸因：報警自動歸因日清隨著業務復雜升級，資損規則不斷增多，腳本失敗報警日清處理成本會越來越高，同時隨著AI應用普及，嘗試通過AI自動歸因日清，進一步降低人工投入成本。