運維進化論：微盟故障給我們的啟示

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

事件背景

微盟是國內移動互聯網營銷引領者，中國最大的微信公眾智能服務平台，基於微信為企業提供開發、運營、培訓、推廣一體化解決方案，幫助企業實現線上線下互通，社會化客戶關係管理，移動電商，輕應用等。

2月23日19點，微盟出現了大規模系統故障，根據官方消息，這是一起運維部門核心員工在生產環境的「刪庫」操作引發的。截止發稿時，系統目前還處於修復階段，預計全部恢復將在2月28日晚上24點完成。在這期間，微盟啟動緊急響應機制，並在騰訊雲的大力支持下一起研究制定生產環境和數據修復方案。

歷史上類似的事件

說到「刪庫跑路」這檔子事，歷史上可以追溯到《西遊記》，你是否還記得孫悟空大鬧地府，硬生生把閻王爺的「地獄資料庫」（Hell-DBMS），其實就是生死簿，改的面目全非的故事吧。

 話說那孫猴子拿起大筆就把自己的名字，還有他的那些猴孫們的名字一起劃了，以此避免了生老病死的輪迴。很顯然，這個地獄資料庫顯然是沒有做過任何備份，從頭到尾就那麼一份，刪了之後就再也回不去了。當然，這個只是我的一個玩笑，但是由此可見備份以及在系統故障情況下恢復能力的重要性。 

IT歷史上此類事件其實不在少數，2015年5月28日中午11時左右，攜程官網和APP同時崩潰，一時之間，攜程資料庫被物理刪除的說法在網上盛傳，直到深夜23：29，攜程才逐漸恢復。第二天，攜程發布官方解釋，稱是由於運維員工的錯誤操作，刪除了生產伺服器上的執行代碼導致，最終的詳細報告官方並沒有公布。

另一個著名的事件是2017年2月，Gitlab.com資料庫也出現了誤刪，當時由於遭受DDoS攻擊造成staging 資料庫（db2.staging）落後生產資料庫（db1.cluster）4GB的數據，並且staging 資料庫由於PostgreSQL的問題處於hang狀態，在試圖修復這個問題的過程中造成了刪錯庫的誤操作，最終造成很多項目代碼不同程度的丟失。

之後，又陸陸續續發生了順豐，廣西移動等類似的事件。

微盟的危機應對值得我們借鑒

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

要知道，微盟也是此次事件的最大受害者，在幕後，我們可以想象會有多少個我們運維人的不眠之夜。在這期間，騰訊雲給予了極大的支持和幫助，派駐了很多一流的技術專家，不計成本來支持微盟和微盟的客戶。

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

為什麼恢復時間這麼長

那接下來的問題就是，既然微盟已經在全力搶修，同時騰訊雲也給予了極大的技術協助，那全面恢復的時間為什麼還要這麼久呢？

圈子外的同學可能覺得這個不應該很複雜，感覺不就是重裝一下系統嗎，資料庫不是都應該有備份嗎，直接恢復一下不就行了嗎。其實事情遠遠要比你想的要複雜得多。很多時候，人常常會有一個認知上的偏差，對於一個自己沒有切身參與過的領域，我們會不自覺地對難度產生錯誤的判斷。這種所謂的迷之自信，是很難克服的。

這樣的例子很多，比如在看球賽的時候，有人就恨不得把電視砸了，總覺得某些球員怎麼這麼挫，但是真要是輪到你上場，你就能比他好嗎。再比如蘭州拉麵，看起來也沒什麼難度嗎，來回幾下子面就拉出來了，但要是換你上，你能拉出那碗面嗎。

其實，熟悉現代軟體架構和運維的同學一定知道，現在軟體的架構以及部署是及其複雜的，尤其在微服務大行其道的今天，每個微服務本身一個集群，微服務和微服務之間還有各種依賴關係，同時每個微服務都有可能會和資料庫打交道，光理清楚這些服務之間的依賴和配置就夠大家受得了。更何況這次的微盟事件不是一次局部的更新和發布，而是幾乎整體架構的全局梳理，從這個意義上說，難度不亞於從頭搭建整個系統，更何況是在如此巨大的業務壓力和輿論壓力之下。

再來看看資料庫，根據目前官方的信息推測，這次的資料庫應該是在生產環境的本地庫發生了不可逆的刪除，否則不可能會需要這麼長的時間。假定本地生產庫沒了，那唯一的方法就是藉助遠程災備的全量備份庫來恢復，但這也會引發出一系列的問題，比如遠程庫容量大，需要大量的網路傳輸時間，再比如，增量備份的完整性欠缺，另外，還會出現由於近期的數據Scheme變更引發的備份數據兼容性問題等等。這些都需要研發人員和運維人員的共同推進，這就會需要更多的時間。

運維進化的冷思考

通過這次的事件，站在運維的全局視角來看，對我們又有哪些啟發呢。這裡我提出了4個問題作為我們討論的主線。

問題1：一個普通個體，能在多大程度上破壞系統？

先說我的觀點：在信息時代，一個普通人完全可以摧毀一個系統。是的，你沒有聽錯。這種事情在信息時代以前，是很難想象的。在人類歷史上，一個個體決定一個民族，一個朝代歷史走向的事情，也不是沒有發生過，但必須是那些位高權重的大人物，你有沒有聽過，兩個普通人聊著聊著，就把人類文明和外星文明都改寫的事吧。

聽起來很荒唐，但是這樣的事情就發生在了劉慈欣的《三體》小說中，地球人葉文潔和三體人1379都是各自世界中的小人物，葉文潔處於對人類的失望，1379處於對生活的失望，在雙方建立了聯繫后改變了人類世界與三體世界在接下來幾百年中的命運。雖然這只是小說中所描繪的場景，但是所有的邏輯都是自洽的，就連霍金在接受採訪時也表達了相同的觀點。

回到運維和DevOps，你有沒有發現，現在很多互聯網產品運維人員的許可權其實是很大的，有時候大到可以直接摧毀一個系統，這種現象在一些B輪或者C輪的企業中尤為普遍，我們先不談運維人員是否會處於惡意故意破壞自己的系統，但是忙著中出錯的概率還是不小的。Gitlab.com的刪庫其實就是運維人員的誤操作導致的，由於過多的終端窗口反覆切換，導致原本應該在staging上執行的刪庫操作實際發生在了生產環境，最終釀成大禍。

所以，這個問題帶給我們的啟示是，要充分重視個人在系統中可能產生的作用，必須對個人的行為進行嚴格的監管，避免由個人引發的系統性故障。這也就是為什麼大型企業都會建立比較完善的分級和分層發布流程，層層監管和審批，避免個人單點故障的無限放大。當然，這些監管和審批必須要納入到由技術驅動的DevOps流水線中來完成，而不是靠傳統的領導簽字來完成。

問題2：「人肉運維」還有多大的生存空間？

首先解釋一下「人肉運維」，我認為那些在生產環境中直接敲命令來完成的各種運維操作都屬於人肉運維的範疇。我記得左耳朵耗子就說過「一個公司的運維能力的強弱和你在生產環境敲命令的多少成正比」，運維能力越弱，在生產環境上直接執行各種命令的頻次就越高，運維能力越強，人直接和生產環境打交道的機會就越少。

所有對生產環境的變更，無論是系統參數、安全策略、網路配置、應用參數、環境參數、文件更新、資料庫更新都應該是通過DevOps的流水線走正式的發布上線流程，所有的操作必須是由腳本或者自動化代碼來完成，任何個人都不應具有直接在生產環境上執行命名操作的場景。這樣做的好處有一下幾點：

1. 發布流程的詳細過程可以被記錄和回溯；
2. 發布流程可以被重複，避免操作步驟的遺漏或錯誤，保證集群中節點狀態的一致性，這點對於集群擴容場景非常重要；
3. 避免生產環境中有人為產生的隨機錯誤；

 所以，這個問題的結論顯而易見，我們應該儘可能避免任何形式的人肉運維，我們的行為準則是「人管代碼，代碼管機器」，而不是「人直接管機器」。

問題3：運維已經積累了大量實踐，為什麼依舊舉步維艱？

隨著軟體架構複雜性的不斷提升，運維的理念和技術手段也在一直都在不停的演進，從早期的運維，到現在的DevOps，再到日漸完善的AIOps，我們已經積累了大量的經驗和最佳實踐，但是為什麼似乎我們運維人依舊感覺舉步維艱。

我認為其中的原因有兩個，一個是現在軟體架構的發展速度在某種程度上超越了運維自身的發展。你如果回頭看一下，運維的技術體系一直在進步，各種CI/CD的工具鏈，容器技術，自動化部署工具，系統監控方案都在日趨成熟，我們的運維能力的確在不斷增強。但是，與此同時，運維的對象也隨之變得越來越複雜，無論是依賴關係，還是集群規模都比以往任何時候都複雜，可以說「水漲船高」是現代運維所面臨的主要矛盾。

另一個原因是，很多運維的最佳實踐在實際工作中被「教條化」了，沒有達到這些實踐設計的初衷。比如為了防止人為的出錯，在做一些關鍵操作的時候，我們往往會有Peer機制（兩個人配對相互檢查），也會有Checklist機制（自己檢查），但是在實際執行過程中，往往是形式主義佔了上風，這一點不用我解釋你也能心領神會，所以這些機制並沒有發揮出應該有的效果。因此我的建議是把這類方法完整嵌入到流水線的執行步驟中去，而不是靠人為的方式來實施。我常說一句話「凡是靠人完成的東西都是不靠譜的，要靠技術手段才靠譜」。

另外，還有一個我認為不太好的實踐，在實際工作中為了引起運維工程師的注意，我們會把系統設計成「危機敏感型」的，也就是說有事沒事都輸出很多告警信息，或者很多一般的操作都讓你反覆確認是否要執行。比如，你發起某個命令執行某個操作，系統就會先給出告警，然後讓你再次輸入「Y」來確定是否繼續執行，看起來這是一種風險更低和更穩妥的設計，但是實際上這會造成一定的困擾。我們一定都聽過「狼來了」的故事，當你每次都覺得這些信息是無關緊要的話，你就會下意識忽略這些信息，那麼當真的狼來的時候，你就慘了。這個問題在以前的波音飛機的設計上也遇到過，因此我的建議是只在那些最有必要的操作上才啟用這種雙重確認的機制。

問題4：運維部門是成本中心嗎？

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

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

我們一直說有兩種類型的待辦事項，一種是既重要又緊急的事，也就是運維同學經常面對的各種救火型任務（生產環境Bug fix、Hotfix發布等），另一種是非常重要但是不緊急的事，也就是我常說的未雨綢繆型任務（自動化運維、監控數據分析統計、模型獲取與優化等）。理想情況下，應該將更多的時間放在未雨綢繆型任務上，而只將少量的時間放在救火型任務。當把未雨綢繆型任務做好了，那麼救火的概率就下降了。但是現實情況正好相反，運維同學天天忙於各種發布，各種線上救火，根本沒有精力去償還各個時期欠下的技術債，這種模式就難逃成本中心的宿命。

關於未雨綢繆型任務，我還想多說兩點。

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

其次，對於日常運維中遇到的各類看得見的問題，不能只是關注表面上的解決，而是要有「刨根問底」的精神。這裡我強烈推薦《豐田模式：精益製造的14項管理原則》一書中的方法：問N個為什麼。

舉個書中的例子，「工廠地上發現一大片油漬。通常的處理方式就是先清理地上的油，最多再檢查一下，機器哪個部位漏油，換掉有問題的零件就好了。但是按照豐田的思路，會引導員工繼續追問：為什麼地上會有油？因為機器漏油了。為什麼機器會漏油？因為一個零件老化，磨損嚴重，導致漏油。為什麼零件會磨損嚴重？因為質量不好。為什麼要用質量不好的零件？因為採購成本低。為什麼要控制採購成本？因為節省短期成本，是採購部門的績效考核標準「。當你連續問了N個為什麼之後，漏油的根本原因才找到。所以對漏油事件的根本解決方案，其實是改變對採購部門的績效考核標準，這樣才能防止以後發生類似問題。

對於日常的運維工作也是如此，只有這樣才能發現和定位那些未雨綢繆型的任務。

好了，我的分享就到這裡。困難的路越走越簡單，簡單的路越走越困難，祝好運！