作者 | 林冰玉

一、離奇的數(shù)據(jù)丟失案件

最近生產(chǎn)環(huán)境出了一起數(shù)據(jù)離奇丟失的案件，調(diào)查過程很曲折，幾度進(jìn)入死胡同。下面跟大家分享整個(gè)事件的來龍去脈。

1. 數(shù)據(jù)丟失案件

8月初，用戶批量導(dǎo)入了一批（300+）委托人數(shù)據(jù)，導(dǎo)入后檢查過數(shù)據(jù)都沒有問題。最近（10月中），處理那些委托人的時(shí)候，發(fā)現(xiàn)所有委托人的某幾個(gè)列表（list）類型的自定義字段的值都沒有了……

用戶報(bào)過來以上問題，涉及到數(shù)據(jù)丟失，是高優(yōu)先級問題，客戶為此特別緊張。

團(tuán)隊(duì)隨即展開調(diào)查。

2. 補(bǔ)充說明

為了更好地解釋這個(gè)問題，補(bǔ)充如下信息：

委托人的信息存在于兩個(gè)系統(tǒng)中：從A系統(tǒng)導(dǎo)入，存入A系統(tǒng)的數(shù)據(jù)庫，同時(shí)會有同步機(jī)制把數(shù)據(jù)同步到B系統(tǒng)的數(shù)據(jù)庫；在B系統(tǒng)也可以修改這些數(shù)據(jù)，修改完會同時(shí)寫入A、B兩個(gè)系統(tǒng)。

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

3. 案件排查過程

案件排查過程

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

(2) 懷疑B系統(tǒng)的用戶操作不當(dāng)導(dǎo)致數(shù)據(jù)被抹去。但是，通過檢查數(shù)據(jù)變更event，沒有發(fā)現(xiàn)來自B系統(tǒng)的event；況且，現(xiàn)在丟失的是一批數(shù)據(jù)，B系統(tǒng)并沒有批量操作的入口。

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

(4) 會不會是第三方的系統(tǒng)寫入導(dǎo)致數(shù)據(jù)丟失？隨即查看第三方的api和相關(guān)event，也是沒有找到任何可疑跡象。

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

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

二、案件引發(fā)的思考

找到了罪魁禍?zhǔn)祝讣簿蛡善屏?。不過，經(jīng)歷這次驚心動魄的數(shù)據(jù)丟失案件，我們該有哪些啟發(fā)和思考呢？下面，我從問題排查、修復(fù)問題和制定預(yù)防措施幾個(gè)維度進(jìn)行反思和總結(jié)。

數(shù)據(jù)丟失案件的思考

1. 問題排查

數(shù)據(jù)出現(xiàn)問題相對比較嚴(yán)重，團(tuán)隊(duì)都會著急去排查原因，不過，在開始排查之前，有更重要的事情要做。我認(rèn)為問題排查也分兩個(gè)步驟：清晰識別問題、定位問題。

(1) 清晰識別問題

對于數(shù)據(jù)丟失的情況，首先要搞清楚丟失的數(shù)據(jù)類型，以及丟失數(shù)據(jù)的時(shí)間段和對應(yīng)的系統(tǒng)/功能模塊等。案件中小陳就是進(jìn)一步識別了問題，發(fā)現(xiàn)了問題的根本點(diǎn)在于只有l(wèi)ist類型自定義字段對應(yīng)的數(shù)值有丟失，因此找到了問題的突破口。

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

(2) 定位問題

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

2. 修復(fù)問題

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

(1) 恢復(fù)數(shù)據(jù)

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

(2) 修復(fù)代碼缺陷

如果數(shù)據(jù)丟失是因代碼缺陷導(dǎo)致，在恢復(fù)數(shù)據(jù)之后需要修復(fù)相應(yīng)的代碼問題。本案件中的自定義字段被使用，但是還允許用戶刪除該字段，且沒有收到任何提示，這也是一種代碼缺陷，是需要結(jié)合真實(shí)業(yè)務(wù)使用情況進(jìn)行完善和修復(fù)的。

(3) 審查安全措施

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

3. 制定預(yù)防措施

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

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