xx新零售卡管生産資料修複經驗分享

一、線上資料狀況

卡管空白卡、庫存卡、主題卡餘額、面值卡餘額由于前期系統不穩定、業務流程遺漏等原因造成資料不準确；

業務方訴求：要求每一天卡在各個階段在每一個人手裡面的數量，還有每一天的餘額是多少，還要跟訂單、

支付、憑證各個系統去核對資料（所有的金額以憑證為主，對不上的資料需要各個系統去分析原因、确認問題）；

需要對齊的資料：

空白卡：期初數量、入庫數量、調撥數量、建卡數量、廢棄數量、盤點數量、期末數量

庫存卡：期初數量、調撥數量、建卡數量、廢棄數量、領入數量、領出數量、換卡數量、發售數量、退售數量、期末數量

主題卡餘額：期初餘額、消費額、退款金額、清零金額、期末餘額

面值卡餘額：期初餘額、消費額、退款金額、清零金額、期末餘額

具體原因和需要解決的問題如下：

1.卡管上線前，将之前老系統的卡移動了新系統，同步初始化了庫存卡保管賬的初始值，由于資料組在同步資料時業務方還在繼續産生售卡、消費等業務，造成了初始化資料不準确；

2.調撥業務資料量大，由于保管賬都是異步線程執行，事務未復原重複點選，導緻資料重複累加；

3.主題卡換卡、退領、廢棄、POS過卡激活、調撥卡業務是建立的卡類型、并拆卡券、贈券、補贈券、面值卡發售等業務邏輯疏漏和相應的BUG造成資料異常；

4.餐飲卡前期修數錯誤、業務方要求手動改資料庫，這種手動修複的資料很難追溯；

5.定時任務不穩定，或是手動觸發了多次，造成了資料的重複；

6.管理類型的卡，在其它系統操作，未産生相應的記錄；

7.面值卡發售時銀行業務異常、硬體異常造成跟支付和訂單的資料同步異常；

8.POS卡消費業務BUG産生的資料異常，或資料未同步至卡管；

二、問題的解決思路

1.跟資料組同學确認期初數量和期初金額、根據當日的流水去修複當天的期初資料和期末資料；

2.根據每個業務段的流水去查詢保管賬的流水，檢視流水是否缺失或者流水是否重複，以此已經來修複每個階段的資料；

3.調撥業務根據流水和錯誤日志分析定位出問題，修複代碼堵住了漏洞；

4.在SQL修複記錄中找出餐飲卡修複異常的資料，排查相應的數量和金額；

5.POS過卡激活沒有任何記錄，且在激活後清空了保管人和保管地點，根據生成日志追溯出每一張卡的參數；

6.零面值的卡用于卡券的贈送和退售等相關業務，沒有相關記錄，根據單卡追蹤和資料庫日志分析了每一張卡的流程，确認每一張卡在發售前屬于哪一個人手上；

7.删除重複的記錄，手動腳本查找前一天期末資料不等于後一天期初的資料，查詢每一組異常資料；

8.業務方要求手動修改資料的在remark中有記錄資料，查詢remark這個字段的記錄修複相應的卡；

9.POS端由于用的老接口導緻資料未記錄，要求POS修複了此問題，然後根據流水和日志分析每一張卡的歸屬；

10.主題卡餘額跟訂單和支付跨庫查詢出了每一筆差異的資料，根據差異資料分析資料同步的問題；

11.面值卡問題根據相應的流水和各系統的資料稽核查詢差異資料，并修複漏洞；

三、第一次月結出現的問題和解決思路

1.新開店鋪某些業務異常，造成空白卡保管賬資料不準确；

解決思路：根據卡類型分析發現是新建立的卡類型，然後查找資料庫發現卡類型ID為空，基本就找到了問題；

2.餐飲卡數量異常，原因：前期手動調數修複資料異常導緻；

解決思路：根據腳本錄分析記每張卡的流向同步修複資料；

3.業務方手動改了資料庫的卡類型，造成某些卡資料對不上；

解決思路：根據移動的資料和資料庫中每條資料的備注同步修複每個賬目下的流水和保管賬資料；

4.主題卡餘額跟憑證對數遇到了很多異常資料；

解決思路：某些資料是卡餘額統計的方式不一緻，有些是系統BUG，還有一些是資料同步的問題，

根據每種場景調整對數的邏輯并修複異常資料的BUG；

5.面值卡餘額保管賬遇到的問題主要是庫存卡保管賬售卡資料異常導緻，同步修複完庫存卡保管賬後問題解決；

6.資訊部提供的報表跟各個系統資料不一緻，經分析發現兩邊資料SQL統計口徑不一緻導緻；

四、第二次月結出現的問題和解決思路

1.庫存卡保管賬每天有手動去核對資料，異常資料主要是業務邏輯漏洞導緻，後續修複了代碼基本解決了此問題；

2.主題卡餘額跟憑證的核對依舊問題很多，兩筆的資料很多對不上，經查發現第二個月期初不等于上一次的結存資料，後續發現是定時任務每天統計的資料覆寫了，且統計口徑與報表中的資料不一緻，後面修複了定時任務的邏輯，并同步修複了前一天的期末不等于後一天的期初的資料；

3.面值卡餘額資料差了很多，跟核算、憑證好幾條資料不一緻，後續發現是跨店消費的原因，同步修複了代碼BUG和異常資料；

4.一次性盤點資料好幾十萬，導緻系統逾時又重複點選，導緻資料差異很大，後續将盤點改成了異步執行操作；

五、兩次月結後續ACTION

1.總結了跟每個系統對接的和資料推送的SQL（包括：消費記錄、退款記錄、清零記錄等），然後将比對SQL放入ADB資料庫，每天定時核對，避免了月底大範圍修複資料，減少月結的時間和工作量；

2.卡管内部自查，每一個報表和卡金額資料都整理好相應的腳本放入ADB資料庫，每天定時跑腳本核對，将不一緻的資料導出然後分析原因，查找系統BUG并修複資料，減少月結的時間和工作量；

3.核查各個影響資料的業務場景（前期測試不充分，業務場景考慮不全），修複代碼中錯誤邏輯和遺漏的邏輯；

4.實時關注慢SQL，修複可能影響資料的業務邏輯并優化SQL；

六、總結

主要總結以下幾點：

1.線上問題複盤，分析每次出問題的原因，以及如何避免再次發生；

2.設計測試用例非常關鍵，要覆寫所有的場景，卡管第一次月結就是由于測試場景不全導緻遺漏了很多資料；

3.測試力度不夠，未考慮資料量及異常情況，正常情況下沒問題，生産往往是操作大批量的資料；

4.修數前要分析産生問題的原因，代碼可以延期修複，不然同類問題還會重複出現

5.研發人員需求了解不到位，需要跟BA多溝通，不了解的業務要及時問，這樣能發現很多對業務了解的盲點

6.線上日志的檢視對定位排查問題幫助很大，本次資料修複查詢了近一個月的日志，分析卡的流向；