**前言：**

時常有聽到各公司資料庫故障的案例，比如資料庫當機了、誤刪資料了、惡意刪庫了等等。可能還有更多的故障沒有披露出來。每次發生此類事件，都會在網際網路圈引起熱議，其實更應該留下的是警醒，我們應該足夠重視資料庫安全問題，對資料庫要有敬畏之心。

#### 1.案列盤點

我們再來回憶下近幾年網際網路圈發生過的“刪庫事件”。

2018 年 9 月份，據網上資訊披露，順豐科技資料中心的一位鄧某因誤刪生產資料庫，導致某項服務無法使用並持續 590 分鐘，最終公司決定辭退工程師鄧某，並在順豐內網通報。

> 鄧某錯選了 RUSS 資料庫，打算刪除執行的 SQL。在選定刪除時，因其操作不嚴謹，游標回跳到 RUSS 庫的例項，在未看清所選內容的情況下，便透過 delete 執行刪除，同時鄧某忽略了彈窗提醒，直接回車，導致 RUSS 生產資料庫被刪掉。
> 因運維工作人員不嚴謹的操作，導致 OMCS 運營監控管控系統發生故障，該系統上臨時線上發車功能無法使用並持續了 590 分鐘

2020 年 2 月 23 日，微盟運維人員賀某因個人精神、生活等原因對微盟線上生產環境進行了惡意破壞，直接導致公司 SaaS 業務突然崩潰，基於微盟的商家小程式都處於當機狀態，300萬家商戶生意基本停擺，生意快做不下去了。同時，微盟自身也蒙受巨大損失，短短几天公司市值就蒸發超過 20 億港元。

事件發生後，微盟團隊與騰訊雲團隊並肩作戰，盡全力抓緊修復，直到 3 月 1 日晚上 8 點，資料終於全面找回，並於 3 月 3 日上午 9 點資料恢復正式上線。儘管作惡的賀某在第一時間被警方抓獲，但並不足以彌補給微盟、商家帶來的損失。

#### 2.經驗與教訓

從以上案例我們可以看到，一旦資料庫發生重大故障，負面影響會非常大，對公司造成極大的損失。造成事件的主要人員也可能面臨被辭退或負刑事責任的風險。

有人說了，為啥資料庫故障這麼難修復，不是都有備份的嗎？其實還是想得太簡單。真的發生此類故障，可能首先需要冷靜下來制定恢復策略，要考慮最新的備份是什麼時候的，是否可用，新產生的資料如何補齊，恢復時間預計多久，出現資料衝突問題如何處理等等。

那麼我們從此類事件中可以得到哪些經驗與教訓呢？若想盡可能避免資料庫故障，談一談筆者自己的看法。

公司制度方面：

- 透過堡壘機控制伺服器許可權，做好環境區分，最好有運維審計系統。
- 有詳細的資料庫變更流程，並責任落實到崗到人。
- 定期檢查備份可用性，制定週期性演練計劃。

資料庫方面：

- 竭力完善資料庫高可用架構，最好可以留個延遲從庫。
- 資料庫賬號許可權盡可能小，不允許個人使用程式賬號。
- 有完整的週期性備份策略，最好增加異地備份。
- 增加資料庫審計，對資料庫流量或日誌審計，設定告警通知機制。

技術人員方面：

- 熟悉你使用的視覺化工具，SQL要看清楚再執行。
- 陌生環境不要操作，特別是古老的環境。
- 不做自己職責以外的操作。
- 資料變更之前記得備份。
- 高危操作要有 check 機制，請同事幫忙檢驗。
- 不要在疲勞狀態下運算元據庫。
- 要有責任心，記得自己操作了啥，出問題不要逃避。

**總結：**

寫本篇文章的目的是為了告誡大家，對資料庫要有敬畏之心，不要認為理所當然，可能一個很小的操作會導致很嚴重的後果。當然，人非聖賢孰能無過，也許只有經歷過一些事故才能更好的成長，我們要做的就是儘可能減少事故發生。

職場裡，對資料庫要有敬畏之心！

相關文章