作者：王曄倞 連結：https://dbaplus.cn/news-141-2712-1.html 

上個月，我們某個產線系統遭遇了一次資料庫宕機事件，整個控制檯服務停止響應近一小時。

事後覆盤，在場所有人都覺得不可思議，為什麼呢？因為MySQL是雙主互備模式，如果一臺資料庫掛了，應用服務應該是無感知才對。怎麼會把整個服務都搞掛了呢？

經過排查發現，雖然MySQL執行在雙主互備模式之上，但為了節省資源，測試環境部署的是MySQL單節點，可能運維在釋出的時候不知道要修改JDBC連線模式，直接在配置檔案中搞了個直連單節點，就丟到產線上去了。

釋出後，業務與開發都進行了功能性驗證，自然都順利通過。

直到在產線跑了一年後，資料庫主庫掛了，服務停止響應了，大家才發現。

說完了資料庫，再說一個與應用伺服器有關的案例。

上週的某個工作日，工作群裡突然一陣大亂，有的人說OA系統卡死，幾秒種後被拋到了登入介面，而有的人卻說一切正常。

起初，大家都認為是網路抖動，或者是神打了個盹。但我不信邪，追查了一通，結果發現了蹊蹺。

原來是某位運維的小夥伴，為了擴充資源，在沒和任何人打招呼的情況下，直接重啟了某臺物理伺服器，導致上面的近十臺虛擬機器受到影響。

OA系統採用的是雙節點模式，其中的一個節點恰巧部署在這臺機器上。

問題來了，拋開人為故障的緣由不談，既然是雙節點，為什麼一個節點掛了之後，有些使用者會有感知呢？

經過排查發現，兩個Tomcat節點並未開啟Session共享，所以才引發被重啟的那個節點Session丟失，從而導致使用者被拋到了登入介面。

為什麼“理論高可用”屢禁不止？

我曾經多次在技術社交場合，與一些CTO、VP及架構師，甚至一線開發聊起過類似話題，但他們似乎都覺得這樣的話題壓根沒必要討論。為什麼？

因為在他們眼裡，發生這樣的事完全是經驗、能力與責任心的問題。

在我看來，經驗多、能力強與責任心高的人才是可遇不可求的，尤其對那些中小型企業，無論成本還是規模，都不具備吸引這些人的屬性，就算你有幸擁有幾位這樣的高手，基本也都被投入在業務一線的陣營中，不僅每天瑣事纏身，忙得腳打後腦勺，而且還要顧及團隊成員的成長，除非是一些重大技術決策與實施，一般不可能每件事都親力親為。

所以，當某位小夥伴突發一些所謂的 “技術疏漏” 事件，只要不把公司搞死，從情感上還是可以接受的。

扯完大道理，我還是結合自己的經驗來談談。

連下盤都不穩，還扯什麼高可用？

在健身圈裡，有好多健身者只練上肢肌肉，不練腿部肌肉。這也可以理解，畢竟健身是一件非常枯燥而急需自律的事情，你花同樣的時間和精力，腿部肌肉再發達，也不得不套在衣褲裡，秀給誰看？但是手臂肌肉就不一樣了，你穿短袖的時候，手臂肌肉可以露出來，穿長袖時，手臂肌肉也能透過衣物顯現出輪廓來。

但那些健身老司機都明白，如果你不練腿部肌肉，時間一長，你的身材就像《神偷奶爸》中的格魯一樣，不僅缺少美感，而且還會影響上肢的訓練。

你想，所有的上肢訓練都需要壓在兩條腿上，下盤不穩，怎麼玩得起來？

因此，我們常說：“要練上肢，先穩下盤，只有下盤穩了才是真男人！”

同樣的道理，一套系統，一套穩定的系統，一套穩定而高效的系統，就好比一個人的身體，上肢是應用，下盤是基礎。

在追求 “快速迭代” 的今天，業務功能的 “快上線，別出錯” 似乎變成了標準配置，也成為了衡量技術團隊價值高低的一把尺，但這背後需要有強大的基礎服務支撐，而這些基礎服務卻需要大量的金錢、精力的投入。

設想下，想要獲得資源的投入，就需要得到決策高管們的認同。

假如你跟老闆說，給我加100個人和100臺伺服器，我能搞出幾個爆款功能，只要你曾經有不錯的業績，外加與老闆之間有信任的基礎，估計這事就成了。但假如你跟老闆說，給我加100個人和100臺伺服器，我要對DevOps平臺進行改造，相信很多老闆都會問：“啥意思？啥叫DevOps？這對我的業務增長能帶來什麼幫助？”，你隨即挺直了腰板說：“肯定有幫助啊！IT投入是一種價值投資！”。

想必很多老闆都會憤然站起，並對你來一個手勢：“Get Out！”

這叫 “秀才遇著兵，有理說不清” ，這也正常，一來是很多IT人的口舌普遍都很笨拙，想舉重若輕地把一個技術問題給沒有技術背景的領導說明白，比登天還難，二來是在一家業務驅動型的公司裡，如果你想通過數字化的方式，呈現出技術投入和業務收益之間的量化關係，那你的抗擊打能力要強，否則你會很容易精神崩潰。

長此以往，系統的發育變得畸形，像極了一個 “只練上肢，不練下盤” 的健身者。

平時穿著長褲，露著帶有肌肉線條的手臂，看似一切都很正常，但對方給你來個掃堂腿，立馬摔個四腳朝天。

不過，這些很多公司的技術負責人都不承認，不信你隨便找一家公司的技術負責人來問，你們公司的系統高可用嗎？他一定會拿出一堆圖和資料，告訴你，我這裡固若金湯，啥事沒有。

但跟你混熟之後，或者你直接進入內部一看，基本都是千瘡百孔，搖搖欲墜。如果你非要尋其根源，基本就是 “缺錢、缺人、沒時間”。

想搞隨機故障測試？歇著吧

在這篇 #講個 '理論型' 高可用架構的故事給你聽# 的文章裡，我有提到想學 “餓了麼” 搞隨機故障測試，結果怎麼樣呢？

搞了一次，大家都覺得有點雞肋，放棄了。

咦？為什麼呢？先來晒一下當時的方案。

在決定啟動做這件事之前，我們先明確了3個目的，一是論證是否存在理論高可用，二是驗證是否能快速發現問題，三是當發現問題之後，是否能快速解決問題。然後再確定了3個測試場景，一是隨機斷網，二是隨機斷電，三是隨機弱網路。

一切就緒，拿什麼系統開刀？直接在產線上搞嘛？

有人提議拿交易系統，而且必須上產線，否則沒有意義，話音剛落立即有人反對，理由也很犀利，“出了事怎麼辦？你確認沒問題嗎？”

一群人沒經驗的人，你看我，我看你，無法回答，算了，放棄。

那就拿某非交易系統，在模擬環境搞吧。問題來了，雖說是模擬系統，但無論是應用節點數量，還是伺服器效能配置，都與產線有很大不同。比如資料庫，模擬系統就是隻有2個節點，一主一備。

就在要進入僵局的時候，我提議：“既然大家都沒經驗，要不就先試試看，然後咱們基於實踐再來複盤。”

贊同，當天晚上就風風火火地搞起來了。結果如何？一切正常。

無論是應用，還是資料庫，乃至中介軟體，輪流斷網、斷電及網路丟包，只要還有一個節點活著，似乎業務都能正常訪問。

瞧瞧，咱們的系統太高可用了。

有句話說得好，“來得早，不如來得巧”，就在我們隨機破壞測試執行後的第二週，被測系統就在產線來了一場罷工，原因是某節點宕機之後，負載均衡策略沒有生效，導致部分使用者收到404。加q群：478052716 免費領取（Java架構資料，視訊資料，BATJ面試資料）

咦？不是隨機破壞測試的時候測過嗎？通過排查，才發現NG的配置與環境部署，生產與模擬完全不同。

從結果看，這一記耳光很響亮，對大家的打擊不小。

在覆盤時，有人提出，我們重新梳理模擬環境，無論配置、節點、部署，都改成與生產一樣，並在模擬環境按生產環境要求新增監控。也有人提出反對，覺得與生產同步完全不可能，人力和物力都不允許，何況我們的模擬環境是用來做業務驗證的，如果用它來承擔隨機破壞測試，會不會對業務部門產生影響？另外，這才剛剛觸碰到非交易系統，如果是交易系統，又該如何去做？

最終，大家都覺得必須在生產上做，這件事情才會有意義。但該怎麼做？

在服務、環境、灰度及監控不完善，經驗不足的情況下，這個課題還要不要繼續下去？

還是歇了吧，等條件成熟的時候再做吧。

再牛逼的經驗，也擋不住客觀環境的變化

我曾問過很多人，為什麼你們費盡心思要招有經驗的人？回答基本一致。

一是探測地雷，仰仗他的經驗，能避免他曾經踩過的坑不在這裡重現。二是降成提效，仰仗他的經驗，能夠用更少的資源、更快的效率達到目標。

更重要的是，我們期望這些有經驗的人，能夠慷慨地將自己的經驗傳授給那些經驗尚淺的年輕人，從而達到團隊整體實力提升的效果。

想得挺好，效果怎麼樣呢？

在我的經歷中，無論你請誰來，無論你怎麼為他配備資源，放心，他曾經踩過的坑還是會在這裡重新踩一輪，那些栽過的跟頭也繼續要栽一次，甚至踩得更深，栽得更狠。

這是為什麼呢？

當然，不排除我身邊都是一些倒黴鬼，或者引進的人都是水貨。但相比之下，我更願意相信是因為客觀環境因素的不同，從而導致原有經驗的可落地性變差。

怎麼理解這句話？我來說個親身經歷的案例。

去年，我寫過一篇 #故障：一場由虛擬化儲存引發的分散式快取效能悲劇# 的文章，詳細描述了一次由虛擬化儲存引起的分散式快取故障。

在文章釋出後的第二週，就曾有讀者提出質疑：“核心中介軟體，居然出現如此小兒科的故障，你們上線之前不做高可用與效能的測試嗎？”

我的回答是：“我們不僅在上線初期做了非功能性混合場景測試，而且每週還會做常規性壓力測試。值得一提的是，代理層的核心程式碼是團隊中某架構師從以前公司帶來的，聲稱這套系統曾經歷過 “雙11” 的洗禮，流過血，流過汗，值得信賴。

無論怎麼想，似乎都會相信這套系統是可靠的、高效的。但萬萬沒想到，在穩定執行很長一段時間後，卻無聲無息地死在了I/O爭搶上……

因為事故的影響範圍太大，在事故覆盤的過程中，業務方老大吐槽，“我平時偶爾也參加你們的技術評審會，最常聽見的詞就是 ‘高可用’、‘高效能’，看了大家是很重視的，也確實做了很多工作，但為啥一遇到實際場景，就不奏效了呢？”

我當時正在氣頭上，直接回了句，“是啊，我也想知道啊，等明天我打個電話問問伺服器，為啥他突然間發脾氣，不高可用了。”

就因為這件事，整整一週，團隊的士氣都很低落。

事情過去一個月後，我請團隊小夥伴喝酒，一來緩解下情緒，二來提升下士氣。

酒桌上，我端起酒杯走到那位負責快取的架構師面前，說：“別一臉頹廢，搞咱們這行遇到這種事情不是很正常嗎？一切都過去了，後面咱們再慢慢改進。”

他笑了笑，端起酒杯站起來，說：“哎……我一直對這套系統很有信心，沒想到出這種事，覺得太丟人了，搞得好像我只會耍嘴皮子似的。”

我拍了拍他，說：“別擔心，下次神會與你同在。”

自從有了網際網路+這個名詞之後，似乎到處都能看到或聽到各種高可用架構，並且還會有個看似很牛逼的人告訴你這個系統架構多麼牛逼，用某某框架你的系統就會起飛，但仔細想想，這對你來說有用嗎？

因為他們只給你指了一扇門，告訴你通過那扇門你就有多牛逼，但鑰匙在哪裡呢？而且也沒有告訴你，在走到那扇門之前，用什麼方法才能把我從現有的坑裡拽出來？

記得在某技術大會上分享的結尾詞，我說過這樣一段話：

為什麼別人的高可用架構，用到我這裡不起作用了呢？

因為真正的高可用壓根就不用糾結架構設計，更不用糾結是否有大廠用過，對於一般的企業來說，只需要把注意力放在程式碼的健壯性、主備設計及環境治理上就行了，不需要其他的。

忽略了這幾點，還談