今日，微盟發(fā)布有關(guān)微盟系統(tǒng)故障通告。通告指出，2月23日19點，系統(tǒng)監(jiān)控報警，服務出現(xiàn)故障，大面積服務集群無法響應，生產(chǎn)環(huán)境及數(shù)據(jù)遭受嚴重破壞。

　　此外該公司旗下SaaS業(yè)務服務出現(xiàn)故障，預測對有關(guān)業(yè)務帶來一定負面影響。

　　目前，公司正進行生產(chǎn)環(huán)節(jié)和數(shù)據(jù)修復工作，預計2月25日晚24點前生產(chǎn)環(huán)境將修復完成，所有新用戶可恢復服務;預計2月28日晚24點前老用戶數(shù)據(jù)修復可以完成。

　　此次事故經(jīng)調(diào)查系微盟研發(fā)中心運維人員賀某所為，賀某于2月23日晚18點56分通過個人VPN登入公司內(nèi)網(wǎng)跳板機，因個人精神、生活等原因?qū)ξ⒚司€上生產(chǎn)環(huán)境進行惡意破壞。目前，寶山公安局已將賀某刑事拘留，犯罪嫌疑人承認犯罪事實。

　　反思：頻繁吃一塹，如何長一智

　　在談反思之前，在此次事件中有幾個問題我們還要關(guān)注一下，為什么這么長時間還沒恢復?

　　為什么一個人可以有這么大的破壞性?

　　從公告中，我們可以看到，到目前為止，仍在進行中的恢復動作就是做數(shù)據(jù)恢復。

　　所以有網(wǎng)友說不難推斷，這次故障被破壞最嚴重的就是生產(chǎn)系統(tǒng)的數(shù)據(jù)庫，而且一定是核心庫，或許應用環(huán)境也被破壞掉了，否則影響不會像現(xiàn)在這么大。

　　1. 數(shù)據(jù)恢復這么晚，說好的災備呢?

　　說道數(shù)據(jù)回復的時間長可能是以下幾個原因造成的：

　　這個事件非常不幸，就是傳說中刪庫跑路的操作，而且極有可能是直接做了rm -rf或者fdisk這樣的基本不可逆轉(zhuǎn)文件刪除操作，更極端可能是主備一起干掉了。

　　數(shù)據(jù)庫備份沒有做好。可能壓根就沒有備份，只能從磁盤文件系統(tǒng)維度恢復;有全量備份，但是無增量備份，全量有可能是一個月、一周，三天等等，這中間的增量備份沒做。

　　不管哪一種，只要是數(shù)據(jù)庫備份機制不完善，沒做過完整的恢復驗證，真正要恢復的時候一定會花大量的時間找回數(shù)據(jù)。

　　2. 論一個人的破壞性?

　　從這次事件看，微盟這種規(guī)模的公司不太可能像大公司，一下招很多運維或DBA，然后每個運維和DBA都嚴格按照不同業(yè)務授權(quán)，也就是每個DBA只能訪問有限的業(yè)務庫。

　　小公司的成本不支持這種做法，而且招了這么多人也沒這么多事情可以干。

　　所以，對于絕大多數(shù)中小型公司來說，普遍和必然的現(xiàn)象就是，一個運維或DBA管整個系統(tǒng)，并且擁有整個系統(tǒng)所有主機的最大權(quán)限，比如root。

　　說做好權(quán)限管控，要分層分級等等，這些玩法只針對大公司有效，因為大公司有錢，有量，有事情干，招一批人，分分工，分分權(quán)限，各管各的，完全沒問題。對微盟這種類型的公司基本不可行。

　　3. 避免問題，我們可以做什么?

　　以上2個問題主要集中在運維人員權(quán)限太大，方便做了極端操作;公司沒有有效的備份恢復機制。針對這兩個問題，網(wǎng)上也有網(wǎng)友列出了自己的想法，小編羅列了幾點。

　　使用云產(chǎn)品，微盟雖然跑在云上，但是很顯然并沒有直接使用云數(shù)據(jù)庫產(chǎn)品，應該是用了云的裸金屬或者是虛擬機，然后在服務器上自己搭建的MySQL數(shù)據(jù)庫。因為從我們使用的經(jīng)驗看，當前任何一家公有云廠商的數(shù)據(jù)庫產(chǎn)品，都會有比較完善的自動備份和恢復機制，而且根本沒有機會去執(zhí)行rm -rf 和 fdisk這樣極端的操作。

　　做好備份。如果真心覺得自己有能力自建，那一定做好全量備份，增量備份，延遲備份，全量備份要多機房，異地備份，因為數(shù)據(jù)是核心資產(chǎn)，應用全刪了還可以重新部署。

　　關(guān)于權(quán)限控制，中小型企業(yè)如果真的沒法做到最小授權(quán)，建議上個主機安全管控軟件，或者堡壘機，各個云廠商都有，類似rm -rf 、fdisk、drop等等這樣的高危命令是可以實時攔截掉的。

　　技術(shù)人自覺才是保護用戶數(shù)據(jù)的最后防線

　　最近幾年，由于技術(shù)人員故意或者有意造成的事故不計其數(shù)。2018 年 3 月，Stack Overflow 發(fā)布了他們的開發(fā)者調(diào)查報告，并首次提出了有關(guān)道德的問題。對于“開發(fā)人員是否有義務考慮代碼的道德影響”這個問題，有近 80%的人回答“是”。不過，只有 20%的人認為他們最終在為不道德的代碼負責，40%的人會在被要求的情況下寫不道德的代碼，只有 50%的人表示在發(fā)現(xiàn)不道德的代碼時會舉報。

　　如果代碼對世界的影響不大，那么這也許就不成問題。打個比方，如果你寫了一個對 100 個人不利的算法，雖然這事不怎么光彩，但產(chǎn)生的影響也是有限的。但是，如果你在擁有數(shù)億用戶的 Facebook、Google、微信上做同樣的事情，結(jié)果就會很嚴重。

　　對于開發(fā)者來說，光是每天寫業(yè)務代碼就已經(jīng)讓人心力交瘁了。更何況不管在國內(nèi)還是國外，技術(shù)在大部分時候都是為業(yè)務服務，開發(fā)者的話語權(quán)是拗不過盈利這條大腿的。但是，遵守職業(yè)道德是最后的底線，如果技術(shù)人員做不到這一點，那保護用戶數(shù)據(jù)的最后一道防線就會崩塌。

　　所以，技術(shù)人的自我修養(yǎng)，在紛繁復雜科技產(chǎn)物的當下顯得更加關(guān)鍵。