[[316623]]

【51CTO原創稿件】

上周微盟出現了大規模系統故障，根據官方通告:微盟研發中心運維部核心運維人員賀某，于2月23日晚18點56分通過個人VPN登入公司內網跳轉機，因個人精神、生活等原因對微盟線上生產環境進行了惡意的破壞；這是一起運維部門核心員工在生產環境的“刪庫”操作引發的。

本次刪庫事件引發了IT技術圈的廣泛關注；小編整理了網友們比較好奇的幾個問題：運維產生的危害為何這么大？修復期為何這么久？微盟是否存在管理漏洞？類似事件如何預防？為此，小編對沃頓在線負責人朱磊、阿里云OLAP產品團隊高級產品專家韓鋒和業界知名軟件研發工程效能專家茹炳晟進行了專訪，內容整理如下。

單個運維人員產生的危害為何這么大？

信息化時代，沒有孤立的個體

信息化時代，系統集成變得度越來越高，作為單個個體是完全可以摧毀一個系統的。但是在信息時代以前，這是難以想象的。人類歷史上，一個個體決定一個民族，一個朝代歷史走向的事情，也不是沒有發生過，但必須是那些位高權重的大人物。此次事件的主角作為公司的核心運維人員，顯然在這種事情擁有天然的便利。

云上服務，運維權限過大

談到運維和DevOps，我們會發現，很多IT運維人員的權限過大，甚至會大到可以摧毀一個系統/產品，這種在一些創業公司中比較常見。微盟公司現提供的服務是部署在服務器上的。為了便于工作，運維工程師手里掌握著高權限的賬號，可以對服務器進行任何操作。例如，這次刪庫事件運維工程師使用高權限賬號把服務器上的文件刪除，直接導致服務器崩潰，進而造成公司業務中斷。

難以避免的人為因素

拋開運維人員是否會出于惡意去破壞自己的系統，但作為人的操控來講，忙中出錯的概率還是不小的。所以，這個問題帶給我們的啟示是，要充分重視個人在系統中可能產生的作用，必須對個人的行為進行嚴格的監管，避免由個人引發的系統性故障。

恢復時間為何這么長？

據介紹，一般來說數據備份要對最近的數據至少在30分鐘內可以恢復。既然微盟已經在全力搶修，騰訊云也表示在給予技術協助，那全面恢復的時間為什么還要這么久呢？

影響因素一：災備出現問題

運維人員對生產服務器進行了文件刪除，并沒有提到對備份服務器進行破壞。如果微盟有著高性能災備，那么恢復服務在技術層面是沒有太大難度的。但是根據目前官方的信息推測，數據庫應該是在生產環境的本地庫發生了不可逆的刪除，否則不會需要這么長時間。假定本地生產庫沒了，那唯一的方法就是借助遠程災備的全量備份庫來恢復，但這也會引發出一系列的問題，比如遠程庫容量大，需要大量的網絡傳輸時間。

影響因素二：恢復流程復雜

就數據恢復來講，受到的影響因素較多，這其中包括了應急團隊響應速度、技術能力、被刪文件體積、文件被刪后繼續頻繁讀寫硬盤等等，這些任何一個出現問題都影響恢復時間。

影響因素三：恢復預案不完備

當企業遭受到如此重大的破壞時，是否有完整的恢復預案并真實演練過，將變得非常重要。如果之前沒有相關準備，很難在出現問題時快速響應，并將問題涉及范圍、恢復手段、相關風險、所需資源等一一考慮清楚。倉促應戰的話，難免顧此失彼，且對可恢復的程度、時間等，也很難預估。

影響因素四：技術實現難度大

不熟悉運維的人可能會覺得恢復是比較簡單：不就是重裝一下系統或者恢復下數據庫備份嗎，其實這其中的涉及技術比我們想的要更復雜。

1.業務架構復雜，現在常用的軟件的架構及部署是極其復雜的，在微服務大行其道的今天，每個微服務本身就是一個集群，微服務和微服務之間還有各種依賴關系，同時每個微服務都有可能會和數據庫打交道，光理清楚這些服務之間的依賴和配置就夠大家受的了。

2.時間緊，任務重，此次事件涉及到幾乎是整體架構的梳理，難度不亞于從0到1搭建一個新系統，再加上客戶壓力和輿論壓力，難度可想而知。

3.數據庫問題，有可能是增量備份的完整性欠缺，此外，還會出現由于近期的數據Scheme變更引發的備份數據兼容性問題等。這些都需要研發人員和運維人員的共同推進，這些都會導致工作量加大和時間的推遲。

微盟的問題：技術管理和數據災備不能忽視

成本是影響公司數據管理投入的直接因素

微盟刪庫事件，暴露了部分互聯網公司內部數據管理的混亂。按理像微盟這種體量的公司對于數據安全和保護的投入和重視程度理應是非常大的。但是此次事件背后隱藏的是利益問題，對以微盟為代表的企業來說，數據安全和保護對于是比較大的成本支出，并不能直接創造營收，所以往往有些還在成長階段的企業不會重視投入，很多制度保護也往往流于表面。對大公司來說，如果忽視數據安全會有可能帶來更大的損失，所以一般來講大公司對數據安全對投入和措施比較規范，類似微盟這樣對刪庫問題基本不會出現。

互聯網公司管理內功欠缺

21世紀是屬于互聯網等新產業的時代，但是管理問題一直是新興互聯網企業前行的最大阻礙，企業管理的意義，估計每個公司的高管都懂，任何一個企業的領導掌舵者都不會忽略的問題，但是能夠真正做到真的很難。

互聯網發展迅速的同時也埋下了隱患，浮躁的行業使得互聯網公司高層管理沒有時間學習管理，沒有時間苦煉內功，這次微盟事件，給互聯網公司上了重要的一課，也希望更多公司能吸取教訓。

如何避免此類事件？

此次事件給微盟和微盟客戶造成了巨額損失，對于整個事件背后暴露的管理與技術漏洞等問 題，其他公司甚至整個行業需要如何避免類似問題再次發生呢？小編總結了茹炳晟和朱磊的建議，來從運維和公司兩個角度聊一下。

對于運維技術人員：

1.避免任何形式的人肉運維

如今隨著軟件架構復雜性的不斷提升，從早期的“人肉”運維，到現在的DevOps，再到目前初綻頭角的AIOps，運維的理念和技術手段也一直都在不停地演進。但這其中人的影響一直存在。

這也是為什么大型企業都會建立比較完善的分級和分層發布流程，層層監管和審批，避免個人單點故障的無限放大。當然，這些監管和審批必須要納入到由技術驅動的DevOps流水線中來完成，而不是靠傳統的領導簽字來完成。

所有對生產環境的變更，像系統參數、安全策略、網絡配置、應用參數、環境參數、文件更新和數據庫更新都應該是通過DevOps的流水線走正式的發布上線流程，所有的操作必須是由腳本或者自動化代碼來完成，任何個人都不應具有直接在生產環境上執行命令操作的場景。

因此應該避免任何形式的人肉運維，倡導“人管代碼，代碼管機器”，而不是“人直接管機器”。

2.未雨綢繆，做好災備演練

一般來講待辦事項分為兩類，分別是既重要又緊急的事和非常重要但是不緊急的事，也就是運維同學經常面對的各種救火型任務（生產環境Bug fix、Hotfix發布等）和未雨綢繆型任務（自動化運維、監控數據分析統計、模型獲取與優化等）。

理想情況下，應該將更多的時間放在未雨綢繆型任務上，而只將少量的時間放在救火型任務上。當把未雨綢繆型任務做好了，那么救火的概率就下降了。但是現實情況正好相反，運維同學天天忙于各種發布、各種線上救火，根本沒有精力去償還各個時期欠下的技術債，這種模式就難逃成本中心的宿命。

因此運維部門在平時定期開展一些故障演練的實踐是很必要的，結合混沌工程（Chaos Engineering）的思想，來確保系統的魯棒性和可維護性，以此來應對各類突如其來的“黑天鵝”事件。“紙上得來終覺淺，絕知此事要躬行”，只有在實際故障演練的過程中，我們才有可能得到很多寶貴的一手實戰經驗，光靠想是不行的。

對于整個公司：

1.運維是成本中心的謬論

在很多人的眼中，運維部門都被歸在成本中心，簡單來講就是花錢的部門。運維是成本中心的宿命論對于運維的發展其實是很不利的，如果運維部門長期處于機械性的發布執行和生產環境救火的狀態，那么就會陷入無止境的惡性循環。

很多時候，我們總是解決了看得見的問題，但是看不見的問題往往會在看不見的地方聚集，這類問題一旦出現就都是大問題。所以我們需要轉變運維是成本中心的思維定式，讓運維的同學能夠更積極地去思考和解決系統性的問題。

2.做好危機公關

微盟的這次刪庫事件，對很多行業用戶造成了很大的影響，但是面對危機，微盟所表現出來的社會責任感是值得我們借鑒和學習的。面對突如其來的故障，微盟并沒有試圖掩蓋真相，而是第一時間在其官網發表聲明，解釋事情的背后原因，并且明確告知了后階段的恢復計劃以及明確的時間節點。

多一些真誠，少一些套路，有問題一起扛，是面對此類危機最好的方法。如果你試圖掩蓋，蓋不住了就撒謊，接著就像張宇唱的那樣“用一個謊言圓一個謊言”，必然會讓自己陷入更深層次的危機。危機之下，我們要的是公開的信息，這樣才能減少公眾的猜測，抵制黑公關，并獲得大家的理解和支持。

3. 練好“內功”

面對類似疫情這類突發事件，首先讓員工知悉真實情況，并做好必要的宣導工作。從員工角度來講，一般能夠理解此類情況，并愿意付出。其次是要做好工作量評估及必要的人員安排，包括值班、輪休等。最為重要的一點，是負責人到崗，與員工一起承擔；一方面便于快速響應、快速決策；一方面減少員工壓力，有利于公司業務的快速開展。

還有對于管理層來講，應重視技術工作（包括基礎運維）的重要性。從團隊構建上予以傾斜，建立起一支有戰斗力的技術團隊。從人才角度上，在“選育用留”多個環節，把握公司價值觀，將真正認同公司價值、愿意付出的同學選到、用好；淘汰不合格人員。

最新消息

2020 年 2 月 25 日，微盟發布公告稱，公司線上生產環境及數據遭到員工惡意破壞，導致公司系統服務不可用。經過幾天的“搶救”，3 月 1 日，微盟再次發布公告稱，數據已全部找回，將于 3 月 2 日進行系統上線演練，于 3 月 3 日上午 9 點恢復數據正式上線，同時針對受到影響的商家也給出了賠付計劃。

賠付計劃

根據公開資料顯示，微盟目前的渠道代理商超 1600 家，注冊商戶超 300 萬。此次微盟宕機或導致 300 萬商家生意停擺，損失巨大。因此，微盟也公布了商家賠付計劃，整體準備了 1.5 億元人民幣賠付撥備金，其中微盟公司承擔 1 億元，管理層承擔 5000 萬元。

針對商家因系統不可以而造成的不同損失，微盟也制定了不同的賠付方案：

現金賠付計劃

針對因系統不可用而造成利潤損失的商戶，微盟將按照商家邊際貢獻利潤額進行賠付，具體公式計算如下：邊際貢獻利潤額 = 日均收入×行業平均邊際貢獻利潤率×系統故障時間

流量賠付計劃

針對因系統不可用而造成流量損失的商戶，微盟將給予騰訊廣告 50000 曝光次數的流量補償，并且提供賬戶運營服務，同時再延長 SaaS 服務有效期兩個月。

放棄自建數據庫，基礎設施全力上云

以上是經濟方面的賠償，在技術方面，此次核心運維對微盟生產環境和數據造成破壞，使得商家對微盟系統安全和穩定性產生了質疑，同時也給微盟自己敲響了警鐘。

微盟在 3 月 1 日發布的公告中稱，微盟將會支持基礎設施全力上云，逐步放棄自建數據庫服務 ，遷移到騰訊云數據庫（CDB），增加數據庫跨可用區和異地災備的能力，同時將黑石 1.0 物理機全面升級黑石 2.0，全面使用云主機。

除了之外，微盟還宣布將加強數據安全管理機制和安全災備體系建設。

采訪對象：

1.茹炳晟：業界知名實戰派軟件質量和研發工程效能專家，騰訊云最具價值專家，中國商業聯合會互聯網應用技術委員會智庫專家，暢銷書《測試工程師全棧技術進階與實踐》的作者，“軟件測試52講-從小工到專家的實戰心法”的專欄作者。現任Dell EMC中國研發集團資深架構師，歷任eBay中國研發中心測試基礎架構技術負責人，HP軟件中國研發中心資深架構師、性能測試專家，Alcatel-Lucent高級技術主管，Cisco中國研發中心資深工程師等職位，具有超過16年的軟件研發和技術管理經驗。

2.朱磊：專注運維安全的北京沃頓在線信息技術有限公司創始人，《暗戰：數字世界之戰》一書作者。他曾任京東研發系統安全經理，具有多年的互聯網信息安全管理經驗，豐富的信息安全理念和多個安全系統架構經驗。

3.韓鋒：花名：群峰，阿里云數據庫產品團隊高級產品專家，CCIA（中國計算機行業協會）常務理事，Oracle ACE，dbaplus社群聯合創始人，ACMUG主席團成員、專家組成員，《SQL優化最佳實踐》作者。

  【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】