從微盟刪庫事件看資料備份和專案管理

3 月初，鬧得沸沸揚揚的「微盟刪庫」事件終於有了乙個解決方案，也讓不少技術人唏噓不已，乙個上市公司的資料備份和專案管理流程居然如此不堪。

先來看下此次事故的時間線。

對於一家業務型的公司來說，資料的丟失，可以說是致命的打擊！更何況是一家上市公司！

客觀說，微盟這家公司的資料備份意識太淡薄了，備份流程等肯定也有重大問題，否則也不會出現這次嚴重事故。

正常情況下，資料庫應該根據業務設定讀寫分離、主從庫，且定期備份全量資料庫。

我上家公司最開始的時候雖然只有乙個庫，但是一周也會備份幾次。甚至融資盡調的時候，還是乙個庫，所有的資料都是這個單庫查出來的，現在想想都後怕，萬一出點問題，那融資可能就黃了。後來隨著業務慢慢發展，資料量逐漸變大，專案重構，資料庫讀寫分離，主從庫等策略也都安排上了。

資料備份的意識必有再三強調，絕對是重中之重，不僅是資料庫的資料，任何跟公司業務相關的資料都要妥善儲存並定期備份。

涉及到線上資料的，必須要有相應的許可權管理。

舉個例子，在使用專案後台管理系統的時候，要根據人員的身份設定不同的操作許可權。例如客服只能檢視使用者的和訂單等相關資訊，沒有修改許可權，客服主管有部分資料的修改許可權；活動運營人員，只能開放活動配置許可權和相應活動的資料檢視許可權等。

此外，在申請後台管理賬號的時候，也要進行郵件審批，申請人發郵件寫明申請人資訊及申請的許可權，由其部門主管審批，然後再由技術部門主管審批，審批後交由負責管理的人員統一進行賬號和許可權配置，並將賬號資訊傳送給申請人。

關於線上資料庫相關操作，開發人員如果要進行 ddl 或 dml 操作，需要向其技術主管進行申請，審批通過後由 dba 或運維人員進行執行操作。

簡單介紹下 sql 語言的幾種運算元據庫的能力：

ddl允許使用者定義資料，也就是建立表、刪除表、修改表結構這些操作。通常，ddl由資料庫管理員執行。

dml為使用者提供新增、刪除、更新資料的能力，這些是應用程式對資料庫的日常操作。

dql允許使用者查詢資料，這也是通常最頻繁的資料庫日常操作。

當然，以上都是我之前工作的一些經驗，不同公司可能有不同的流程，但是歸根結底，就是讓相關人員知曉跟資料相關的操作，從而避免資料洩露和資料庫誤刪。

微盟事件，看似是在資料備份和許可權管理方面出了問題，但是在我看來，這不過是整個專案管理流程上暴露的冰山一角。

我個人從乙個 android 開發轉做專案經理，最開始的時候也沒有一套可以依據的專案管理流程。但是隨著在專案開發的過程中不斷總結，不斷改進，逐漸總結出了自己的一套專案管理的流程，可能並不完全適合他人照搬，但涉及到的部門協作和管理流程是類似的。

乙個專案從需求收集到開發測試，直至最後的上線，也就是 dba 或運維人員進行線上資料庫操作和程式的發布，其實只是整個專案管理中的一部分。後面的文章會將會詳細說明每個步驟中的注意事項。

專案管理流程最難的部分不是在整理流程，而是在執行方面，乙個制度很容易就能制定出來，但是要執行起來困難還是挺多的。

就我個人經驗而言，最怕的就是技術領導不重視、不按流程走，如果是偶爾的緊急需求那無可厚非，但經常不按流程走，那就很危險了。所謂上樑不正下樑歪，技術領導都不當回事，下面的技術經理和開發人員會當回事嗎？

長此以往，可能不會出現微盟那麼嚴重的刪庫事件，但是線上資料誤操作肯定會有的。退一步講，人非聖賢孰能無過，出問題也是常有的事，但是就怕出了問題不優先解決問題，而是先甩鍋，還不總結教訓，這就很可怕了，更可怕的是這還是技術領導的所作所為。

這次的微盟的事故，其 cto 有很大的責任，他對資料備份和專案管理流程肯定不夠重視。

許可權管理和專案管理的存在就是為了規避某些可以避免的誤操作，人確實會犯錯，但是能避免的錯誤為什麼不去盡力避免呢？不論是對個人還是對公司，能嚴格執行許可權管理和專案管理流程，並且培養基本的備份意識，都是有好處的。