我想你一定很熟悉近幾年“百億補貼”“天降紅包”“簽到抽獎”這些電商、外賣、打車花樣百出的營銷活動和使用者補貼。而且它們的營銷逐漸從特有的大促場景中（比如雙 11、618）常态化，紅包、返現、抽獎、X 元套餐等活動玩法層出不窮，随之而來的還有各類資損事件，比如
2020 年 1 月，京東被爆出可以領取 200 元無門檻小家電優惠券，微波爐、電烤箱等小家電甚至可以 0 元購，網傳損失 7000W，研發團隊整體被裁掉，雖然後來京東官方辟謠，但根據按訂單發貨和砍單補償紅包的處理措施來看，最終的資損肯定是個天文數字
6 元的美的電烤箱
除了這個案例，還有商戶配錯價格、秒殺商品大量超賣等資損類事件，它們主要有這樣幾個共性的特點
- 平台感覺能力弱，技術名額不敏感，大部分是輿論爆發後人工回報；
- 因為感覺困難，往往持續時間長，最終資金損失大；
- 問題難以第一時間立刻恢複，并且止損後容易引起輿論關注和公關事件
簡單來講就是感覺難、修複慢、影響大
大部分研發者對資損類事故的了解相對缺乏，因為它比可用性事故更隐蔽，并且很多人會将其簡單歸為“線上Bug”，忽略背後的資金損失，也沒有量化具體的業務影響。是以，如果一個團隊要想在資損上不栽跟頭，能結合具體的業務場景在系統上做好防控建設，技術 Leader 的認識和引導就起到關鍵作用
建立資損概念的宏觀認知
很多 Leader 有這樣一個認知誤區： 平台有資金外流或者因為平台的系統故障導緻某一方客戶有資金外流，這才是資損事故。這種隻關注真實流失的資金，是狹義的
從廣義上來看，存在理論損失也應該算資損， 比如因為搜尋推薦系統出問題（不論什麼原因）導緻這一階段廣告的收入減少，或者因系統 Bug 導緻使用者取消訂單的申請被預設同意（雖然原本商戶可能也會做同意處理，但是申訴的話平台依然要賠付），類似預計收益減少或者因系統問題産生賠付的場景都應算為資損
常見的定義與分類，因為資損場景與業務是息息相關的，是以又簡單地舉了幾個例子
資損定義與分類
在這裡，注意資損分類的“已知資損”。 聽起來有點兒怪，怎麼還能允許已知資損存在呢？其實這種情況很常見，主要還是因為業務規則與使用者體驗之間的平衡，比如電商平台有跨店鋪滿減優惠券，如果你湊單後，退掉不需要的商品就可以跨過“本不滿足的優惠券使用條件”
雖然這種“鑽空子”是業務規則允許的，但是也會存在風險，有可能形成超出預期的問題，比如家居這類大客單價的場景，如果忽略“已知資損風險”，發出了 3000-500 的優惠券，和 300-30 帶來的風險肯定天上地下了
你可能感覺跟自己的關聯不大，因為自己負責的不是交易或者營銷這類與資金關聯很強的系統。隻要公司的業務存在資金流，那麼體系中的任何一個系統都很難完全規避資損風險，隻是機率高低而已。很多時候，你一松懈，也許問題就會發生
資損防控的三個關鍵
資損事故感覺難、修複慢、影響大，是以更應該把精力投入到預防上，這樣才能從根本上解決問題。修複慢是因為缺少預案，隻能臨時 Fix，時間上緊迫還容易引入新的風險。而想要更早發現問題，就要有監控，這樣才能在事發第一時間響應處理，縮短事故持續時間
是以你要争取做到事前梳理出風險點做好預防、事發可以及時感覺響應、事中可以快速止損恢複（簡單來講三個字：防、監、控）
從階段上來講，資損防控的落地動作與可用性治理的有所類似，但是每一部分的關鍵點和可用性治理又不相同，這些是 Leader 要格外注意的
1.防：資金視角做風險點識别
核心是引導團隊将精力放在風險點的識别與修複上，雖然大部分事故都和技術 Bug、産品邏輯設計、人為配置錯誤這三部分有關，但是具體的原因非常離散。比如圍繞紅包可能出現的資損風險點，從紅包的生命周期切入，就有很多可能
- 配置階段： 金額、數量、使用條件、補貼結構等資訊是否配置正确？
- 發放階段： 紅包發放人群是否有超出？
- 核銷階段： 優惠互斥關系是否滿足（比如滿減和新使用者紅包不可同享）？單筆訂單可使用紅包數量是否超出？
- 退回階段： 訂單取消後，紅包是否退回？如果用在 B 訂單上的紅包是來自 A 訂單的獎勵，那麼 A 訂單取消後，B 訂單使用的紅包是否受影響？
可以看到，抛開技術問題僅從業務邏輯的角度去假設，在紅包的各個階段都可能出現資損風險，并且問題非常多樣。這一方面說明資損風險點與業務場景聯系緊密，另一方面也說明窮舉風險點有很強的不确定性，我們需要一些可疊代的“套路”去分析和發現問題
如果說我們通常以 DB 設計、API 契約、架構圖作為切入點，梳理可用性的風險點，關注的是流量請求、調用鍊路以及資料變化（這是一個資訊流的視角）。那麼與之對應的，在資損方面我們關注的是業務邏輯中隐含的資金邏輯，也就是資金流的視角
因為不管是技術問題還是業務邏輯問題，資損風險最終的都會反映到資金層面上，而資金的變化是受業務邏輯影響的，二者結合就有了一個很好的切入點。 一般系統中資金的變化主要展現在 4個 方面，分别是資金流、資金賬戶、資金計算和資金憑據
- 資金流：通過梳理資金的流向，來确認資金轉移的鍊路是否有錯誤。比如使用者領取了滿 15-5 的紅包，其中 3 元平台補貼，2 元商戶補貼。使用者下單購買了 15 元的商品，那麼從紅包補貼到使用者支付再到商戶收款，就形成了一個簡單的資金流，這個流向可以形成很多個“等式”，通過梳理和驗證這些等式的正确性檢查資金流中是否存在錯誤，比如最簡單的
使用者應付/實付（10）= 商品價格（15）- 紅包優惠（5）
商戶應收/實收（13）= 商品價格（15）-商戶補貼（2）= 使用者實付（10）+紅包内平台補貼（3）
- 資金賬戶：通過流水和記錄核對資金賬戶資料的正确性，比如使用者賬戶、商戶收款賬戶……同樣也包含一些虛拟資産的核對，比如積分、優惠券……
- 資金計算：涉及資金計算的部分需要單獨 Review，并通過資料對比進行正确性核算。比如優惠金額的計算、訂單金額的計算、商戶抽傭的計算……
- 資金憑據：資金在各系統扭轉的過程中一定會落有大量的憑據，比如訂單上會存有使用優惠的資訊、對一筆訂單進行支付理論上在支付系統會存在一筆支付單，這些憑據的資料準确性以及彼此關聯的資料正确性都需要驗證
除了從這 4 個資金的角度梳理風險點之外，還要考慮到一些技術實作引入的問題，比如接口契約、計價機關等，這些技術實作所導緻的資料不一緻和不正确的問題都會引發資損事故，不斷完善 Checklist 和設計原則，整體的梳理思路參考如下
資損風險點識别
2. 監：一緻性與正确性雙核對
雖然資損類事故有點兒“潤物無聲”的味道，但是無聲勝有聲。比如一定規模的電商平台，如果紅包補貼金額有問題，哪怕一個紅包平台隻損失 0.01 元，但是在龐大體量和長時間的作用下，最終的損失也會是一個天文數字
除了技術名額外，更敏銳的是業務監控。然而它對于短時間資損嚴重的場景會有比較好的感覺能力，但是對于某些細小的資損的場景則無能為力，這就需要我們建立更加敏感、完善的監控體系
針對資損感覺的核心思想是：基于線上業務結果收攏進行監控，基于線下業務場景擴散進行核對
基于線上結果收攏進行監控，是忽略“因”聚焦“果”的一種假設方法，通過觀察結果的變化來反推因子是否發生變化。可以這樣思考，假設系統存在資損漏洞或Bug，那麼哪些關鍵的業務名額會發生變化？這樣你會發現
- 原本滿 10-5 的紅包，因紅包模版Bug，實際生成的紅包使用門檻為滿 5-5；
- 原本僅能在星巴克使用的 15 元專享紅包，因為配置錯誤，變成可以在任意門店使用的平台通用紅包
不同原因導緻的問題，最終都會促使交易GMV、使用者單均實付金額等宏觀業務名額與日常的同比環比出現差異，不同原因的業務影響會逐漸往關鍵的業務名額上彙集
是以可以結合這樣的規律，通過組合觀察關鍵業務名額，形成一個基本的資損監控大盤，這樣的大盤對來勢洶湧、機關時間内流血量大的資損問題是比較敏感的
而基于線下業務擴散進行核對，則聚焦到我們在資損預防階段梳理出的業務場景和業務鍊路。通過建立實時核對的機制確定每一個紅包涉及的資金流動與計算都準确無誤。這裡實時核對的思想是一種 DoubleCheck 的做法， 比如我們認為雖然系統會将記錄中的 A 資料變更為 B 資料，但是我怎麼知道它實際操作中是否所有的變都正确呢？那麼我就每次變更完都看一下，A 有沒有變為 B，隻要檢驗時發現沒有變為 B 我就告警出來
在實際業務中，首先根據不同的業務場景、邏輯規則和資金、資産的變化，梳理出一個個核對公式，這部分其實在風險點梳理時就應該有整理。然後通過系統實時判斷等式左右兩邊本應該相等資料是否一緻，一旦不一緻則告警出來。舉幾個簡單的例子
- 積分發放： 積分系統發放 100 積分給使用者 A = A 使用者賬戶中新增 100 積分
- 庫存扣減： 訂單系統生成包含 2 件 A 商品的訂單 = 商品系統中 A 商品庫存減 2
- 下單返紅包： 使用者支付金額 * 返還比例 = 使用者賬戶新增紅包金額
其中，資産的轉移發放是比較清晰簡單的，涉及資金組成（比如訂單金額計算）的公式就會更複雜一些，但是核對的原理是類似的，都是基于業務場景順着資金或資産流向建立一個個核對公式，在每一次資金或資産變動時，都會通過核對公式左右是否一緻判斷是否有資損發生
這裡需要技術 Leader 注意， 與可用性監控圍繞接口的技術名額不同，資損更關注的是資料核對，監控的并不是運作狀态而是運作結果，并且資損監控的粒度要求非常高，精細到每一筆交易、每一次金額計算、每一個紅包發放。是以資損監控的有效性很依賴于場景的覆寫率，僅覆寫幾個關鍵場景是不足以規避資損風險的，除了要定期梳理外，每次系統有變更或者新功能時，都需檢查是否有新的核對點，以及舊有核對公式是否需要調整
資損監控核對
3. 控：資金攔截 + 資産控制
除了防和監，資損防控的關鍵主要在“控”字上，我們希望在問題發生後第一時間止損，這就需要技術在系統層面對資金和資産有很強的控制能力。這種能力的表現就是： 不僅可以通過預案将某些場景與鍊路降級，還可以攔截資金的流出和資産的使用，同時具備快速訂正錯誤資料的能力
在開始處理資損事故時，會有三個共性的需求
問題止血不新增：核心是關閉問題産生源頭，往往通過業務場景降級來實作，比如對錯誤紅包或者滿減活動進行下線
控制資金流出：核心是對資金和資産進行攔截與當機，避免外流後損失無法修正，比如禁止使用者下單時勾選使用有問題的紅包
存量資料訂正：核心是撈取問題資料後可以快速地批量處理，比如批量更改紅包的金額、甚至直接将紅包無效
雖然其中一些操作對使用者體驗是有損的，但有而不用是一回事兒，無能為力則是另外一回事兒，其中
- 資金攔截的能力主要從資金的流入和流出這兩端進行把控。以紅包而言就是管控其建立與核銷。在紅包建立時，有預算系統進行管控，避免無限制地生成紅包進而超發。在紅包核銷時，由交易和營銷系統進行驗證，確定訂單上下文以及紅包合法，避免問題紅包被核銷進而造成無法挽回的資損
- 資産管控的能力則是資産的快速鎖定和資料訂正展開，以紅包而言，如果不同模版不同活動的紅包都有一個統一的批次号，就可以通過這個标記快速撈取某一批有問題的資料。同時如果提前準備批量訂正的腳本，或者有訂正資料的平台，就可以快速修改紅包金額、使用時間、使用門檻等關鍵資訊，甚至批量無效所有問題紅包
需要注意，這些能力的實作更多依賴于技術 Leader 在日常需求疊代和架構設計時，是否有意識引導團隊加強這方面的建設。大部分的預案思路來源于過去已經發生的問題，或者對未來可能發生問題的假設，将預案常态化是你重點關注并推進落地的
除了建設預案，還要有預案演練，以此保證預案的有效性。技術 Leader 更應該鼓勵測試和開發的同學主動做攻防演練，尋找漏洞、驗證止損方案、及時發現并修複問題
總結
資損事故很特殊，除非之前有過金融行業的從業經驗或者在這方面吃過大虧，否則很容易忽視其在系統中的風險。強調這樣幾個關鍵點
- 技術 Leader 應該加深對資損概念的了解，并引導團隊加強這方面的認識；
- 圍繞你負責的業務，建構風險梳理的“套路”，排查隐患；
- 重點圍繞業務場景打造高覆寫度的監控核對，早發現、早治療、少損失；
- 尊重墨菲定律，圍繞可能發生的問題做好預案和演練
在穩定性這個領域，不論是可用性還是資損，都是将系統中大量不确定性的風險識别出來，通過各種手段降低風險的過程。想要改變一件事，先要對其有足夠的認識和了解，技術 Leader 在這個過程中應該起主導作用，看到别人看不到的，想到别人沒想到的，引領團隊往正确的方向走