- 一. 前言
- 二. 嘗試尋找解決問題
- 三. 結果：
- 四. 問題分析：
- 五. 防止刪庫跑路策略
一. 前言
思科前員工離職后刪庫，直接損失達 240 萬美元，今天這個事情竟然發生到我們公司身上，嚇了一身冷汗，同胞們一定要注意資料庫安全問題，安全無小事，不出問題沒人重視，一出問題就是致命的，
我目前在一家科技公司擔任研發總監作業，今天上午10點左右，我隨機點擊了一個線上APP的一個功能，發現資料沒有了，以為是個常規的bug，把這個問題直接反饋給了測驗主管，
下面試我們的聊天：
震驚： 生產環境表被覆寫了？？？而且不能還原！！！
我立馬停下手頭的作業，趕快找研發落實問題，這個時候研發、運維都聚在一起排查原因了，
最終發現一個庫的重要核心表被清空了，我問了下運維，可以恢復到之前資料不，運維說由于binlog日志沒開啟，而且沒有備份，還是單機的，沒法還原！如果真沒法還原，線上資料庫有20多萬的用戶，還有充值的金額，這個影響是致命的，
二. 嘗試尋找解決問題
聽完運維說的無法還原，我的心一下子提到了嗓子眼，頓時壓力倍增，但是表面故作鎮定，因為我是他們的精神依靠，我一旦慌了，他們估計就更慌了，
這個時候還有人在討論是可能是黑客攻擊、誤操作、代碼問題等原因，我阻斷了他們的討論，先解決問題！稍作鎮定，我開始梳理思路，人和任務分成以下3條線同步解決：
- 備份現有資料： 先把當前庫的所有表備份一遍，以防當前是由于黑客或者惡意破壞者繼續破壞，
- 運維繼續尋找還原策略： 運維負責繼續尋找還原策略，再次確認是否有binlog方案還原、事務回滾還原、是否有定時備份檔案，
- 研發通過其他表還原： 由于表被清空的只有一張，是否可以通過其他表的關聯關系，進行拼接組裝還原該表，經過和研發討論，可以通過其他表把資料還原90%，心想，90%如果能還原也不錯了，馬上安排研發通過查找其他表的方式進行sql拼裝的作業，
三. 結果：
就這樣三個方案同步進行了20分鐘，這個時候第二個方案，也就是運維這邊傳來了喜訊：他發現他之前做了一個定時任務備份資料庫策略，大家頓時興奮了起來，趕快找到了出問題的時間節點，然后順利找到了最近一次備份檔案，立馬進行了資料庫表的還原，還原程序很快，還原后驗證下線上的問題，一切正常，這下才把心放了下來，
四. 問題分析：
由于mysql資料庫，我們沒有開啟日志的記錄，無法統計的造成這次事故的具體原因是什么，只有通過以下方式進行分析原因：
1. 黑客攻擊：如果黑客攻擊的話，不應該只洗掉一張表吧，而且程式上面排查沒有類似的不安全腳本執行操作，所以黑客攻擊的可能性不大，
2. 離職員工惡意報復：這個也有可能，離職員工目前手里面有資料庫的賬號和密碼，也是有操作的可能的，
3. 員工升級誤操作導致： 這個理論上是最有可能的，但是今天沒有升級程式，都說沒動過資料庫，（其實我覺得應該是有人動了，不承認）
五. 防止刪庫跑路策略
1. 服務器異地定時備份： 一定要做個定時任務腳本，每天至少要異地（至少是異服務器）備份2次，防止磁盤掛了、黑客攻擊、誤操作等導致資料庫例外，
2. 開啟Binlog日志： 一定要開啟binlog日志，一旦出現問題，既能通過日志的方式恢復；又能查出操作記錄，從而追責到人，
3. 資料庫集群策略： 資料庫最好有3臺機器，一主兩從，互相同步，讀寫分離，
4. 資料庫賬戶、操作權限回收： 這個一定要有，要把資料庫的用戶和密碼以及操作權限，從研發人員手中會受到運維手中，防止研發誤操作、離職報復等損壞資料庫，
5. 業務庫分離： 不要把所有雞蛋都放到一個籃子中，每個業務對應一個庫，多個業務庫和庫之間是物理隔離的，就算是一個資料庫掛了，其他庫和業務正常運行，把影響范圍降到最小，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/120554.html
標籤：其他