作者 | 林冰玉

一、離奇的數據丟失案件

最近生產環境出了一起數據離奇丟失的案件，調查過程很曲折，幾度進入死胡同。下面跟大家分享整個事件的來龍去脈。

1. 數據丟失案件

8月初，用戶批量導入了一批（300+）委托人數據，導入后檢查過數據都沒有問題。最近（10月中），處理那些委托人的時候，發現所有委托人的某幾個列表（list）類型的自定義字段的值都沒有了……

用戶報過來以上問題，涉及到數據丟失，是高優先級問題，客戶為此特別緊張。

團隊隨即展開調查。

2. 補充說明

為了更好地解釋這個問題，補充如下信息：

委托人的信息存在于兩個系統中：從A系統導入，存入A系統的數據庫，同時會有同步機制把數據同步到B系統的數據庫；在B系統也可以修改這些數據，修改完會同時寫入A、B兩個系統。

丟失數據的“字段”（不是字段的“值”）本身是通過list類型來自定義的，也就是說不同類型的委托人可能看到的字段是不一樣的；而丟失的是自定義字段對應的“值”。

3. 案件排查過程

案件排查過程

(1) 團隊第一反應是懷疑雙寫和同步之間出了問題，但仔細檢查后覺得沒法成立。

(2) 懷疑B系統的用戶操作不當導致數據被抹去。但是，通過檢查數據變更event，沒有發現來自B系統的event；況且，現在丟失的是一批數據，B系統并沒有批量操作的入口。

(3) 是不是A系統進行過批量操作，導致數據被重寫？開發人員看代碼，測試人員嘗試重試各種相關場景，也是沒有成功；同時，從event里也沒有找到跟這批委托人相關的任何可疑event。

(4) 會不會是第三方的系統寫入導致數據丟失？隨即查看第三方的api和相關event，也是沒有找到任何可疑跡象。

(5) 能想到的用戶相關操作都試過了，也沒有任何相關event的記錄，難道是直接運行SQL腳本把數據刪除了？客戶的相關人員不會無故去運行腳本，懷疑可能我們提供的某次修復生產環境問題的腳本搞得鬼……查看最近這段時間的腳本記錄，大家放心了，沒有腳本會導致數據丟失！

(6) 真的是見鬼了！怎么可能數據就這么莫名其妙的丟了呢？！調查小組幾經折騰已經筋疲力盡了，決定求助資深專家小陳。小陳同學聽了前面的排查過程，好像真的天衣無縫，但他還是不甘心，決定再去看看event和log。他重新查了前面提到的那些委托人相關的event，的確沒有發現任何可疑。又仔細看了看用戶報過來的問題，發現竟然只是list類型的值丟失了！這一定有什么不對！他趕緊去查看那幾個list字段相關event，終于真相大白了！原來是有用戶把list里的選項刪除又重新以不同順序添加了一遍，從而導致原來用這些選項的字段的值都沒有了！

二、案件引發的思考

找到了罪魁禍首，案件也就偵破了。不過，經歷這次驚心動魄的數據丟失案件，我們該有哪些啟發和思考呢？下面，我從問題排查、修復問題和制定預防措施幾個維度進行反思和總結。

數據丟失案件的思考

1. 問題排查

數據出現問題相對比較嚴重，團隊都會著急去排查原因，不過，在開始排查之前，有更重要的事情要做。我認為問題排查也分兩個步驟：清晰識別問題、定位問題。

(1) 清晰識別問題

對于數據丟失的情況，首先要搞清楚丟失的數據類型，以及丟失數據的時間段和對應的系統/功能模塊等。案件中小陳就是進一步識別了問題，發現了問題的根本點在于只有list類型自定義字段對應的數值有丟失，因此找到了問題的突破口。

因此，清晰識別問題，才可能朝著更加正確的方向去排查問題，這一點至關重要！

(2) 定位問題

• 收集日志、Event等信息：查看系統日志、數據庫日志和其他相關的系統記錄，收集可能有關丟失數據的信息，例如異常情況、錯誤信息、登錄記錄等。
• 對收集到的信息進行分析，以確定可能導致數據丟失的原因。例如，檢查數據庫或其他系統的異常操作、網絡連接或系統故障等。
• 排查過程需要結合業務、開發、測試和運維人員的力量，考慮可能會影響的業務場景，從界面操作和系統代碼兩方面入手，同時排查各種可能性。案件中的定位問題過程還是做的比較周全的，對于復雜的系統，就得集團隊之力一步一步細心地去排查；甚至有的時候需要借助外部專家的力量，外部力量作為旁觀者加入，可能會事半功倍，起到關鍵作用。

2. 修復問題

數據丟失問題的修復需要處理以下幾種情況：恢復數據、修復代碼缺陷、審查安全措施。

(1) 恢復數據

數據丟失問題，最緊急的是恢復數據。如果有備份數據，則可以嘗試使用備份數據進行恢復。如果沒有備份，則可能需要使用數據恢復工具或其他手段嘗試恢復丟失的數據。

(2) 修復代碼缺陷

如果數據丟失是因代碼缺陷導致，在恢復數據之后需要修復相應的代碼問題。本案件中的自定義字段被使用，但是還允許用戶刪除該字段，且沒有收到任何提示，這也是一種代碼缺陷，是需要結合真實業務使用情況進行完善和修復的。

(3) 審查安全措施

數據丟失也可能是代碼以外的其他原因所致，需要評估現有的安全措施。例如數據備份策略、數據恢復策略、訪問控制和身份驗證措施、加密和防火墻等。以確定是否存在缺陷或漏洞，并進行相應的修復和改進。

3. 制定預防措施

任何問題如果能做到防患于未然當然是最好的！分析數據丟失事件的原因和影響，制定預防措施以避免類似事件再次發生至關重要。例如，加強數據備份和恢復策略、加強安全防范和監控、加強員工培訓和管理等。

《都是臟數據惹的禍》一文對于臟數據的預防有詳細的介紹，而數據丟失也是臟數據的一種形式，適用同樣的預防措施。