今日，微盟發布有關微盟系統故障通告。通告指出，2月23日19點，系統監控報警，服務出現故障，大面積服務集群無法響應，生產環境及數據遭受嚴重破壞。

　　此外該公司旗下SaaS業務服務出現故障，預測對有關業務帶來一定負面影響。

　　目前，公司正進行生產環節和數據修復工作，預計2月25日晚24點前生產環境將修復完成，所有新用戶可恢復服務;預計2月28日晚24點前老用戶數據修復可以完成。

　　此次事故經調查系微盟研發中心運維人員賀某所為，賀某于2月23日晚18點56分通過個人VPN登入公司內網跳板機，因個人精神、生活等原因對微盟線上生產環境進行惡意破壞。目前，寶山公安局已將賀某刑事拘留，犯罪嫌疑人承認犯罪事實。

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

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

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

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

　　所以有網友說不難推斷，這次故障被破壞最嚴重的就是生產系統的數據庫，而且一定是核心庫，或許應用環境也被破壞掉了，否則影響不會像現在這么大。

　　1. 數據恢復這么晚，說好的災備呢?

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

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

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

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

　　2. 論一個人的破壞性?

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

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

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

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

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

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

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

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

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

　　技術人自覺才是保護用戶數據的最后防線

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

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

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

　　所以，技術人的自我修養，在紛繁復雜科技產物的當下顯得更加關鍵。