微盟宕機事件相信大家都有所耳聞，這次事件在互聯(lián)網(wǎng)圈也是一次不小的地震了，據(jù)悉這次事件讓微盟業(yè)務(wù)宕機長達125小時，300萬商戶生意停罷，300萬商家眼下只想盡快恢復(fù)生意，渡過這場難關(guān)，而微盟老對手有贊在此時遞出了橄欖枝，毫不掩飾自己借機收割微盟客戶的野心，微盟或面臨一定程度的客戶流失，這也直接導(dǎo)致了市值蒸發(fā)20億港元，將影響今年Q1整體營收，為微盟難過的同時也在警醒自身，如何防預(yù)此類危機？

近幾年來，由于技術(shù)人員故意或者有意造成的事故不計其數(shù)，微盟事件之前，2018 年 3 月，Stack Overflow 發(fā)布了他們的開發(fā)者調(diào)查報告，并首次提出了有關(guān)道德的問題。對于“開發(fā)人員是否有義務(wù)考慮代碼的道德影響”這個問題，有近 80％的人回答“是”。不過，只有 20％的人認為他們最終在為不道德的代碼負責(zé)，40％的人會在被要求的情況下寫不道德的代碼，只有 50％的人表示在發(fā)現(xiàn)不道德的代碼時會舉報。開發(fā)者的代碼道德依然是條很長的路，刪庫代碼其實只有短短的一行：“rm -rf/*”，但使用不當，造成的結(jié)果卻會天翻地覆。

猶如2017年1月31日，全球第二大的開源代碼托管平臺GitLab內(nèi)部的一位系統(tǒng)管理員，在給數(shù)據(jù)庫做日常維護時，一時不慎運行了數(shù)據(jù)庫目錄刪除命令……結(jié)果是雖然幾經(jīng)搶救修復(fù)，論壇上原本高達300GB的數(shù)據(jù)只保留下來 4.5G，直接導(dǎo)致當時的GitLab被迫下線。正因如此，貓云SaaS平臺公司對于刪庫這種行為，是從技術(shù)和管理上都做了很多限制的。基于此次事件中賀某能夠刪庫成功，且微盟需要“至少六天”來恢復(fù)數(shù)據(jù)這一結(jié)果，也引發(fā)了互聯(lián)網(wǎng)業(yè)內(nèi)討論。

業(yè)內(nèi)專家任向暉通過個人公眾號發(fā)文稱，“大多數(shù)成熟 SaaS 企業(yè)都會建立科學(xué)的部署架構(gòu)，內(nèi)部分工和運維規(guī)范。如果沒有這些規(guī)范存在，組織無法獲得任何第三方的質(zhì)量認證?！比蜗驎熢谖恼轮校f明了真正的“規(guī)范”應(yīng)該做到三個方面：

一，高可用的架構(gòu)。

通過幾乎實時同步的主從服務(wù)關(guān)系（應(yīng)用和數(shù)據(jù)都可以實現(xiàn)），讓單一服務(wù)出現(xiàn)問題的時候可以瞬間切換到其他鏡像服務(wù)。這個架構(gòu)也可以用來均衡不同訪問路由的負載。

二，在異地增加冷備份。

這個冷備份雖然有一定的延時，但是可以起到關(guān)鍵的數(shù)據(jù)保全作用。為了足夠的安全，冷備份應(yīng)該不止一份。為防范服務(wù)商系統(tǒng)性故障，冷備份最好分布在不同的云主機服務(wù)商。雖然冷備份非常偶然地被使用，但SaaS公司都在支付這些冗余存儲的成本。

三，最關(guān)鍵的管理分權(quán)。

原則上，生產(chǎn)服務(wù)器的運維管理權(quán)只限于極少數(shù)人即可，因為研發(fā)團隊并不需要訪問真實的生產(chǎn)環(huán)境，他們在模擬的研發(fā)環(huán)境中調(diào)試即可。計算機安全體系允許將主機運維、數(shù)據(jù)庫管理和其他系統(tǒng)管理的權(quán)限全部分開，分別授予不同的人員，并且所有的訪問行為均會保存日志，就連日志數(shù)據(jù)也是可以分權(quán)管理的，這使得單個人破壞全部服務(wù)的可能性為0。微盟事件的主要原因肯定是疏忽在這個環(huán)節(jié)。

在通俗一些說，上述問題1與2屬于技術(shù)范疇，而問題3則屬于公司內(nèi)部管理問題。任何一環(huán)出現(xiàn)問題，都會增加SaaS平臺的數(shù)據(jù)風(fēng)險和安全風(fēng)險，而安全事件的根源，往往在于管理。

我們需要有效避免悲劇重演，企業(yè)應(yīng)該重新審視自己的防范預(yù)案是否合理，要在在技術(shù)、制度和流程規(guī)范這三個方面進行加強，保障用戶的數(shù)據(jù)安全。