7萬商戶苦苦等待的微盟公告來了。今日下午4點42分，據鈦媒體了解，微盟集團官方公眾號發布“刪庫”事件後的第二次業務進展公告，稱業務進展順利，目前新用戶所有服務可用，老用戶部分商家賬戶、權益數據等部分服務恢復，但預計“2月28日晚上可以恢復七成左右數據”。

此時，距離微盟內部人員賀某刪庫事發已經是第五天，“28日24時恢復老用戶數據”的承諾，無法如期完成。

過去五天，業界關於微盟的討論主要聚焦在三點：

1.核心運維人員為什麼要刪庫？

2.微盟技術架構及管理上有哪些疏漏，何以讓一個運維人員把系統整癱，行業應該吸取哪些教訓？

3.經歷6天144小時的服務暫停，給微盟影響多大、對商戶影響多大？

要回答以上三個問題，我們首先要復習一下微盟是一家甚麼樣的公司？

微盟，成立於2013年的SaaS服務商，2019年1月在香港主板上市，目前市值122.44億港幣，較25日的138.33億港幣縮水約16億，折合人民幣約14億元。2019年上半年，該企業總營收6.57億元人民幣。

其主要業務是在微信等平台上為電商、零售、餐飲、本地生活、酒旅等企業搭建小程序，並為其提供精準營銷服務，根據微盟提供的數據，目前微盟已經為超過300萬商戶提供這類服務。

這也意味著，在2月23日，微盟核心數據遭內部員工刪除（以下簡稱“微盟事件”），其SaaS產品不可用之後，有7萬註冊商戶的線上商城、小程序門店等無法訪問。（查看鈦媒體此前文章→《SaaS服務商微盟遭員工“刪庫跑路”，300萬商戶哭了……》）

“之前計劃通過公眾號在小程序商城上推接下來的一波活動，現在都被耽誤了。我們應該會轉向其他平台做這個活動了，比如天貓、京東、有贊等。”一位使用微盟服務的糖巧商戶對鈦媒體表示。

受事件影響，微盟股價下跌，截止鈦媒體發稿，微盟市值較25日已經縮水約27億港幣（約合人民幣24億元）。

截止28日4點微盟股價。較25日市值138.33億港幣，目前市值縮水約31億港幣（約合人民幣27億元）

微盟事件不是必然事件，卻是移動互聯網時代的產物。

在很多人認為SaaS市場會因為疫情而火爆的時候，微盟刪庫事件也讓大家更加認識到雲上數據安全的問題更需要引起足夠的重視，因為只要上了雲，數據一旦出問題，就相當於銀行倒閉，就是傾家蕩產的風險。

一次本可以避免的安全事故

輿論對犯罪嫌疑人賀某“刪除數據庫”的原因猜測不斷，直到有人將此事與甚至“微盟某高管傳言”聯繫到一起，甚至引發了SaaS 圈外人集體“吃瓜”——當幾百萬商戶都在關心“我的網店還能不能恢復”時，讓原本一樁技術事故，最終朝向娛樂化發展。

27日下午，微盟創始人兼CEO孫濤勇發布長文回應，就內部員工“刪庫”的原因向外界公開了一個模糊的官方定論。

關於刪庫原因，孫濤勇表示，“該員工春節期間一直沒有回家，由於疫情階段不能外出，只能一個人在房間獨處了30多天，加上本身經濟上的困擾，就做出了這種舉動，事後他也說跟公司無任何仇恨，我想他是在選擇一種自己解脫的方式吧，這也是為什麼事後沒跑路，也很快承認了犯罪事實。”

圖片來源@微盟CEO孫濤勇回應

截止目前，這是微盟關於本次事故的全部回應；而上海公安官方尚未對該案件做出任何公開。

某互聯網創業公司CTO 向鈦媒體記者評價微盟事件時稱，“看到事故出來，心裡一緊。” 但該人士對鈦媒體表示，把一項嚴重的技術事故歸因於一個員工身上，“這不符合技術常識。”

一位從業超20年的IT諮詢公司高管也告訴鈦媒體，“徹底刪除”這件事，在計算機時代根本不存在，只存在“數據恢復起來的複雜程度不同”。

那麼，到底誰要為數據安全事故背鍋？當下，電商企業普遍上雲需求迫切，我們到底該如何認識所謂的“刪庫”事件？

“穩定”，是雲服務廠商最重要的生命線

刪庫代碼其實只有短短的一行：“rm -rf/*”，但使用不當，造成的結果卻會天翻地覆。

例如2017年1月31日，全球第二大的開源代碼託管平台GitLab內部的一位系統管理員，在給數據庫做日常維護時，一時不慎運行了數據庫目錄刪除命令……結果是雖然幾經搶救修復，論壇上原本高達300GB的數據只保留下來4.5G，直接導致當時的GitLab被迫下線。

因此，SaaS平台公司對於刪庫這種行為，是從技術和管理上都做了很多限制的。基於賀某能夠刪庫成功，且微盟需要“至少六天”來恢復數據這一結果，也引發了業內討論。

明道云CEO任向暉通過個人公眾號發文稱，“ 大多數成熟SaaS企業都會建立科學的部署架構，內部分工和運維規範。如果沒有這些規範存在，組織無法獲得任何第三方的質量認證。 ”

任向暉在文章中，用“易懂的文字”來說明了真正的“規範”應該做到三個方面：

1）高可用的架構。

通過幾乎實時同步的主從服務關係（應用和數據都可以實現），讓單一服務出現問題的時候可以瞬間切換到其他鏡像服務。這個架構也可以用來均衡不同訪問路由的負載。

2）在異地增加冷備份。

這個冷備份雖然有一定的延時，但是可以起到關鍵的數據保全作用。為了足夠的安全，冷備份應該不止一份。為防範服務商系統性故障，冷備份最好分佈在不同的雲主機服務商。明道云的數據備份分佈在UCloud、阿里雲和騰訊云三個服務商。雖然冷備份非常偶然地被使用，但SaaS公司都在支付這些冗餘存儲的成本。

3）最關鍵的管理分權。

原則上，生產服務器的運維管理權只限於極少數人即可，因為研發團隊並不需要訪問真實的生產環境，他們在模擬的研發環境中調試即可。計算機安全體系允許將主機運維、數據庫管理和其他系統管理的權限全部分開，分別授予不同的人員，並且所有的訪問行為均會保存日誌，就連日誌數據也是可以分權管理的，這使得單個人破壞全部服務的可能性為0。微盟事件的主要原因肯定是疏忽在這個環節。

在通俗一些說，上述問題1與2屬於技術範疇，而問題3則屬於公司內部管理問題。任何一環出現問題，都會增加SaaS平台的數據風險和安全風險，而安全事件的根源，往往在於管理。

另一篇評論文章基於微盟事件聲稱，“99%的SaaS都有安全隱患”。但顯然，業內人士大多並不認同這樣的說法。

對此說法，任向暉認為，“這是偷換了一般安全隱患和安全災難的區別。計算機網絡和軟件的漏洞的確是常見的，但它們的破壞力非常有限，即使是嚴重的D0級（需要當天立刻修復）缺陷，也不至於造成完全的數據滅失後果。”

同樣向電商行業提供SaaS服務的有贊平台，也在微盟事件後第一時間，收到了來自多家客戶、投資人方面的疑慮和諮詢。

CTO 崔玉鬆在接受鈦媒體採訪時說，“為了逼自己重視，2013年我們給自己列了第一信條’系統穩定高於一切’，2017年1我們推出’有贊護航’計劃，如果出現微商城核心服務不可用，影響了客戶的生意，就按照不可用時間給予對應102.4倍的補償。這是整個信息服務行業裡沒有的最高規格的’承諾’。我們有嚴格的訪問控制，做了角色分離、權限隔離，杜絕少數人就能進行高危操作，制定了嚴重宕機的處理預案。”

崔玉松也告訴鈦媒體，有讚的CTO和CEO都沒有可能用一台電腦、一套賬號密碼完成徹底刪庫動作。

在IaaS雲的層面，有讚的主要的服務商有騰訊雲、Ucloud兩個，而且在兩家平台上相互備份。

“（我們的數據）在每個服務商的不同的機房裡有備份。退1萬步講，即使一個雲服務商出現問題，我們在技術上都可以自動切換到另一個雲服務上，並且從技術的角度、從數據的角度，我們可以在5分鐘之內基本上恢復95%的流量。”

崔玉鬆對有贊平台抗風險能力的預估是，“遇到非常極限的災難的時候，我們可能最長的時間——按我們現在預估——大概30分鐘可以完全恢復。”

管理問題是根源

對微盟事件的歸因，業界主流聲音是：沒有施行管理分權。

鈦媒體查閱公開資料發現，微盟的確存在這種權限管理過鬆的可能。微盟CTO 黃駿偉曾在一次公開分享中提到，微盟正處於高速成長期，微盟的技術團隊從最初的三四十人已經擴充到了六七百人。

為了應對研發管理的繁雜，讓技術研發跟上公司快速擴張的腳步，微盟施行了項目負責人制度。在這一制度下，每個項目匯總到一個負責人，並使得該負責人能夠調動盡量多的資源來協同他做事。“每個團隊事事都還要匯報到CTO這裡，那無疑是非常低效的。”黃駿偉說。

而身為核心人員的賀某，或許恰是某個項目具有高權限的負責人。

“刪庫”事件影響下，百萬級的平台商戶均陷入了網店關閉、無法登陸和交易癱瘓的窘境，對於微盟提出的“6天才能恢復數據庫”，6天（甚至還不確定的週期），對於任何一家平台商戶而言，損失慘重。

針對“至少6天”來完成數據恢復的公告，一種說法是，微盟沒有做數據雙活方案/異地備份，才導致刪除一個主庫之後，多天無法恢復；也有人認為，微盟使用了便宜好用的MySQL，沒有用商業級別的Oracle或DB2。

更確切的消息，據《中國經營報》報導，微盟的底層架構採用的是混合雲模式，部分自建部分上雲，而微盟被刪的數據恰好是沒有上雲的自建部分，這種做法會導致沒有上雲部分的數據在被刪除之後無法及時恢復。

“如果在雲上，雲數據庫的備份功能能夠保證哪怕是刪了數據，也能回滾到之前的某個時刻，把損失降到最低。”一位雲計算業內人士表示。

截圖來源@知乎

針對這一問題，@騰訊雲在官方賬號中也對雲數據庫這一問題進行了回复。騰訊雲稱，”在微盟事件中，微盟使用的雲數據庫在這次事故中沒有受到影響”。這一聲明或側面證實，事故中實際上出問題的是微盟本地化部署的數據。

當下，混合雲模式是雲計算界較為青睞的資源部署模式。但鈦媒體呼籲，採用本地化部署以及混合部署的企業，一定要做好本地部署數據的備份和防護，降低類似事故風險。

有贊CTO崔玉松針對中小商家的經營數據安全，提出瞭如下建議

1）要注意店舖管理員的角色分離、權限隔離，定期查看後台的操作日誌；

2）需要高級管理員的驗證碼來做二次驗證的，一定要搞清楚員工在做什麼重要操作；

3）通過API授權的方式，從有贊雲調取店鋪數據到其他第三方應用，應注意調取的接口類型。和安卓手機權限一樣，多餘的權限不要授予。

4）嚴格控制有表格數據導出權限的高級管理員的數量，密切監控數據導出的用途。

5）離職員工要第一時間刪除管理員權限。

時間不等人

微盟研究院在2019年5月發布的《2018微信小程序行業應用發展研究報告》顯示，超過一半的企業商戶對小程序保持高度關注，在已應用微信公眾號（訂閱號/服務號）的商戶中，57.18%同時開通了小程序；另外，95%以上的商戶有意願將企業未來的營銷推廣預算向小程序傾斜。

因此，受數據庫事件影響最大的是單一架構在小程序上的商戶。

市場的火爆，事件對整個行業的震動，已經無法讓大家冷靜面對商場沉浮。

微盟發布事故公告當天，同屬SaaS平台服務領域的有贊發布了“給微盟商家的江湖救急”計劃。公告中表示，有贊將為微盟商家提供2週免費開線上商城的服務，幫助他們重建小程序和店鋪；但如果商家在次過程中想要長期使用有贊服務，卻有顧慮到微盟軟件服務未到期，有贊可以適當補貼對應服務器來減少損失。

一位希望匿名的商戶告訴鈦媒體，當他對外發布了“商城不可訪問”的信息之後，立即收到多家SaaS 平台的溝通意願，但具體信息不便透露。

這充分反映出，在小程序搭建、店鋪私域流量的運營這片處於行業上升期的市場，競爭慘烈。

中國小程序服務商不完全統計（由鈦媒體TMTBase制整理）

據媒體不完全統計，類似小程序服務商這樣的企業除了有贊、微盟兩家發展比較快之外，還有點點客，商派雲、即速應用、序多多等多家服務商也參與其中。

有媒體評論稱，假如微盟商戶在此次故障中試用了另外一家的服務，那麼對微盟最大的影響將是面臨客戶流失。

在疫情之外，又突發數據庫安全問題，SaaS行業在不到一個月時間內黑天鵝事件頻發。受影響的幾萬家商戶們被迫面臨選擇：遷移還是等待？

事故已經發生，而根據部分受影響商戶在社交媒體上的抱怨，事故後平台方面的信息不公開、不對稱正在讓商戶與平台之間產生“信任危機”。一部分商家已經在考慮遷移問題。

而關於微盟在兩次公告中提及的“賠償問題”，一位跨境電商公司創業者、某平台SaaS小程序商戶對鈦媒體表示，“賠償問題不是最重要的，商戶最在意的是’信任問題’。”包括該跨境電商商戶在內的一部分商家，已經在著手準備向有贊等平台遷移。

該商戶還認為，“安全問題是相對的，畢竟我們使用的是工具。除了風險如何防範，我們更關心的是出現問題後平台怎麼能補救，有沒有能力預知可能的風險。”該商戶透露，兩年前在上線小程序的同時，自行購買了服務器對系統數據進行了備份。

“大商家”收到來自微盟恢復期到3月中旬的通知

一位做水產生意的微盟商戶向鈦媒體透露：“ 大商家都收到’恢復期到3月中旬’的通知了，只有我們在傻等著，只看到官網公告，並沒有收到任何通知。”

在中小企業“上雲”的主流趨勢之下，微盟事件的影響，已經遠超我們的估計。

黑天鵝事件考驗了整個SaaS行業的抗風險能力，而這些能力往往並不體現在股價上、銷售方案中，真正決定平台競爭力的，是這些潛於水下但事關生死的能力——技術架構是否完善、數據安全能否保障、企業管理是否良性，都是不能兒戲的平台責任。