一. 前言

思科前員工離職後刪庫，直接損失達 240 萬美元。今天這個事情竟然發生到我們公司身上，嚇了一身冷汗。同胞們一定要注意資料庫安全問題。安全無小事，不出問題沒人重視，一出問題就是致命的。
我目前在一家科技公司擔任研發總監工作。今天上午10點左右，我隨機點選了一個線上APP的一個功能，發現資料沒有了。以為是個常規的bug，把這個問題直接反饋給了測試主管。
下面試我們的聊天：

震驚： 生產環境表被覆蓋了？？？而且不能還原！！！
我立馬停下手頭的工作，趕快找研發落實問題。這個時候研發、運維都聚在一起排查原因了。
最終發現一個庫的重要核心表被清空了。我問了下運維，可以恢復到之前資料不，運維說由於binlog紀錄檔沒開啟，而且沒有備份，還是單機的。沒法還原！如果真沒法還原，線上資料庫有20多萬的使用者，還有充值的金額，這個影響是致命的。

二. 嘗試尋找解決問題

聽完運維說的無法還原，我的心一下子提到了嗓子眼，頓時壓力倍增。但是表面故作鎮定，因為我是他們的精神依靠，我一旦慌了，他們估計就更慌了。
這個時候還有人在討論是可能是駭客攻擊、誤操作、程式碼問題等原因，我阻斷了他們的討論，先解決問題！稍作鎮定，我開始梳理思路。人和任務分成以下3條線同步解決：

1. 備份現有資料： 先把當前庫的所有表備份一遍，以防當前是由於駭客或者惡意破壞者繼續破壞。
2. 運維繼續尋找還原策略： 運維負責繼續尋找還原策略，再次確認是否有binlog方案還原、事務回滾還原、是否有定時備份檔案。
3. 研發通過其他表還原： 由於表被清空的只有一張，是否可以通過其他表的關聯關係，進行拼接組裝還原該表。經過和研發討論，可以通過其他表把資料還原90%。心想，90%如果能還原也不錯了。馬上安排研發通過查詢其他表的方式進行sql拼裝的工作。

三. 結果：

就這樣三個方案同步進行了20分鐘，這個時候第二個方案，也就是運維這邊傳來了喜訊：他發現他之前做了一個定時任務備份資料庫策略。大家頓時興奮了起來，趕快找到了出問題的時間節點，然後順利找到了最近一次備份檔案。立馬進行了資料庫表的還原。還原過程很快，還原後驗證下線上的問題，一切正常，這下才把心放了下來。

四. 問題分析：

由於mysql資料庫，我們沒有開啟紀錄檔的記錄。無法統計的造成這次事故的具體原因是什麼，只有通過以下方式進行分析原因：
1. 駭客攻擊：如果駭客攻擊的話，不應該只刪除一張表吧。而且程式上面排查沒有類似的不安全指令碼執行操作。所以駭客攻擊的可能性不大。
2. 離職員工惡意報復：這個也有可能，離職員工目前手裡面有資料庫的賬號和密碼。也是有操作的可能的。
3. 員工升級誤操作導致： 這個理論上是最有可能的，但是今天沒有升級程式。都說沒動過資料庫。（其實我覺得應該是有人動了，不承認）

五. 防止刪庫跑路策略

1. 伺服器異地定時備份： 一定要做個定時任務指令碼，每天至少要異地（至少是異伺服器）備份2次。防止磁碟掛了、駭客攻擊、誤操作等導致資料庫異常。
2. 開啟Binlog紀錄檔： 一定要開啟binlog紀錄檔，一旦出現問題，既能通過紀錄檔的方式恢復；又能查出操作記錄，從而追責到人。
3. 資料庫叢集策略： 資料庫最好有3臺機器，一主兩從，互相同步。讀寫分離。
4. 資料庫賬戶、操作許可權回收： 這個一定要有，要把資料庫的使用者和密碼以及操作許可權，從研發人員手中會受到運維手中。防止研發誤操作、離職報復等損壞資料庫。
5. 業務庫分離： 不要把所有雞蛋都放到一個籃子中。每個業務對應一個庫，多個業務庫和庫之間是物理隔離的，就算是一個資料庫掛了，其他庫和業務正常執行，把影響範圍降到最小。