3 月初，鬧得沸沸揚揚的「微盟刪庫」事件終于有了一個解決方案，也讓不少技術(shù)人唏噓不已，一個上市公司的數(shù)據(jù)備份和項目管理流程居然如此不堪。

事故經(jīng)過

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

2 月 23 日，因公司員工惡意破壞公司線上生產(chǎn)環(huán)境及數(shù)據(jù)，導(dǎo)致公司系統(tǒng)服務(wù)不可用。目前，該犯罪嫌疑人已被公安機關(guān)刑事拘留。
2 月 25 日，緊急恢復(fù)了核心業(yè)務(wù)的線上生產(chǎn)環(huán)境，新用戶使用不受影響，并提供老用戶臨時過渡方案。
2 月 28 日，恢復(fù)了所有業(yè)務(wù)的線上生產(chǎn)環(huán)境，并且開放了老用戶登錄，以及恢復(fù)了微站產(chǎn)品的所有數(shù)據(jù)。
截止到 3 月 1 日晚 8 點，在騰訊云團隊的協(xié)助下，全面找回數(shù)據(jù)。
3月2日，進行數(shù)據(jù)恢復(fù)上線演練，在此期間系統(tǒng)會停止服務(wù)。

從數(shù)據(jù)恢復(fù)的時間上看，微盟的數(shù)據(jù)備份肯定有重大問題，不然也不會在騰訊云的協(xié)助下這么久才找回全部數(shù)據(jù)。

數(shù)據(jù)備份

對于一家業(yè)務(wù)型的公司來說，數(shù)據(jù)的丟失，可以說是致命的打擊！更何況是一家上市公司！

客觀說，微盟這家公司的數(shù)據(jù)備份意識太淡薄了，備份流程等肯定也有重大問題，否則也不會出現(xiàn)這次嚴(yán)重事故。

正常情況下，數(shù)據(jù)庫應(yīng)該根據(jù)業(yè)務(wù)設(shè)置讀寫分離、主從庫，且定期備份全量數(shù)據(jù)庫。

我上家公司最開始的時候雖然只有一個庫，但是一周也會備份幾次。甚至融資盡調(diào)的時候，還是一個庫，所有的數(shù)據(jù)都是這個單庫查出來的，現(xiàn)在想想都后怕，萬一出點問題，那融資可能就黃了。后來隨著業(yè)務(wù)慢慢發(fā)展，數(shù)據(jù)量逐漸變大，項目重構(gòu)，數(shù)據(jù)庫讀寫分離，主從庫等策略也都安排上了。

數(shù)據(jù)備份的意識必有再三強調(diào)，絕對是重中之重，不僅是數(shù)據(jù)庫的數(shù)據(jù)，任何跟公司業(yè)務(wù)相關(guān)的數(shù)據(jù)都要妥善保存并定期備份。

權(quán)限管理

涉及到線上數(shù)據(jù)的，必須要有相應(yīng)的權(quán)限管理。

舉個例子，在使用項目后臺管理系統(tǒng)的時候，要根據(jù)人員的身份設(shè)置不同的操作權(quán)限。例如客服只能查看用戶的和訂單等相關(guān)信息，沒有修改權(quán)限，客服主管有部分?jǐn)?shù)據(jù)的修改權(quán)限；活動運營人員，只能開放活動配置權(quán)限和相應(yīng)活動的數(shù)據(jù)查看權(quán)限等。

此外，在申請后臺管理賬號的時候，也要進行郵件審批，申請人發(fā)郵件寫明申請人信息及申請的權(quán)限，由其部門主管審批，然后再由技術(shù)部門主管審批，審批后交由負(fù)責(zé)管理的人員統(tǒng)一進行賬號和權(quán)限配置，并將賬號信息發(fā)送給申請人。

關(guān)于線上數(shù)據(jù)庫相關(guān)操作，開發(fā)人員如果要進行 DDL 或 DML 操作，需要向其技術(shù)主管進行申請，審批通過后由 DBA 或運維人員進行執(zhí)行操作。

簡單介紹下 SQL 語言的幾種操作數(shù)據(jù)庫的能力：

DDL：Data Definition Language

DDL允許用戶定義數(shù)據(jù)，也就是創(chuàng)建表、刪除表、修改表結(jié)構(gòu)這些操作。通常，DDL由數(shù)據(jù)庫管理員執(zhí)行。

DML：Data Manipulation Language

DML為用戶提供添加、刪除、更新數(shù)據(jù)的能力，這些是應(yīng)用程序?qū)?shù)據(jù)庫的日常操作。

DQL：Data Query Language

DQL允許用戶查詢數(shù)據(jù)，這也是通常最頻繁的數(shù)據(jù)庫日常操作。

當(dāng)然，以上都是我之前工作的一些經(jīng)驗，不同公司可能有不同的流程，但是歸根結(jié)底，就是讓相關(guān)人員知曉跟數(shù)據(jù)相關(guān)的操作，從而避免數(shù)據(jù)泄露和數(shù)據(jù)庫誤刪。

項目管理

微盟事件，看似是在數(shù)據(jù)備份和權(quán)限管理方面出了問題，但是在我看來，這不過是整個項目管理流程上暴露的冰山一角。

我個人從一個 Android 開發(fā)轉(zhuǎn)做項目經(jīng)理，最開始的時候也沒有一套可以依據(jù)的項目管理流程。但是隨著在項目開發(fā)的過程中不斷總結(jié)，不斷改進，逐漸總結(jié)出了自己的一套項目管理的流程，可能并不完全適合他人照搬，但涉及到的部門協(xié)作和管理流程是類似的。

一個項目從需求收集到開發(fā)測試，直至最后的上線，也就是 DBA 或運維人員進行線上數(shù)據(jù)庫操作和程序的發(fā)布，其實只是整個項目管理中的一部分。后面的文章會將會詳細(xì)說明每個步驟中的注意事項。

項目管理流程最難的部分不是在整理流程，而是在執(zhí)行方面，一個制度很容易就能制定出來，但是要執(zhí)行起來困難還是挺多的。

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

長此以往，可能不會出現(xiàn)微盟那么嚴(yán)重的刪庫事件，但是線上數(shù)據(jù)誤操作肯定會有的。退一步講，人非圣賢孰能無過，出問題也是常有的事，但是就怕出了問題不優(yōu)先解決問題，而是先甩鍋，還不總結(jié)教訓(xùn)，這就很可怕了，更可怕的是這還是技術(shù)領(lǐng)導(dǎo)的所作所為。

這次的微盟的事故，其 CTO 有很大的責(zé)任，他對數(shù)據(jù)備份和項目管理流程肯定不夠重視。

權(quán)限管理和項目管理的存在就是為了規(guī)避某些可以避免的誤操作，人確實會犯錯，但是能避免的錯誤為什么不去盡力避免呢？不論是對個人還是對公司，能嚴(yán)格執(zhí)行權(quán)限管理和項目管理流程，并且培養(yǎng)基本的備份意識，都是有好處的。

歡迎訪問的個人博客：掘墓人的小鏟子

總結(jié)

以上是生活随笔為你收集整理的从微盟删库事件看数据备份和项目管理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。