兩年前，我曾寫過一篇 #有關理論型高可用# 的文章，目的是爲了警示使用者，切莫重理論，輕實踐，不把系統可用性當回事，這種思想很危險。
一轉眼，兩年過去了，這樣的事件還是日常工作中頻頻發生。
說兩個今年的案例，畢竟還熱乎着。
上個月，我們某個產線系統遭遇了一次數據庫宕機事件，整個控制檯服務停止響應近一小時。
事後覆盤，在場所有人都覺得不可思議，爲什麼呢？因爲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。
咦？不是隨機破壞測試的時候測過嗎？通過排查，才發現NG的配置與環境部署，生產與仿真完全不同。
從結果看，這一記耳光很響亮，對大家的打擊不小。
在覆盤時，有人提出，我們重新梳理仿真環境，無論配置、節點、部署，都改成與生產一樣，並在仿真環境按生產環境要求添加監控。也有人提出反對，覺得與生產同步完全不可能，人力和物力都不允許，何況我們的仿真環境是用來做業務驗證的，如果用它來承擔隨機破壞測試，會不會對業務部門產生影響？另外，這纔剛剛觸碰到非交易系統，如果是交易系統，又該如何去做？
最終，大家都覺得必須在生產上做，這件事情纔會有意義。但該怎麼做？
在服務、環境、灰度及監控不完善，經驗不足的情況下，這個課題還要不要繼續下去？
還是歇了吧，等條件成熟的時候再做吧。
再牛逼的經驗，也擋不住客觀環境的變化
我曾問過很多人，爲什麼你們費盡心思要招有經驗的人？回答基本一致。
一是探測地雷，仰仗他的經驗，能避免他曾經踩過的坑不在這裏重現。二是降成提效，仰仗他的經驗，能夠用更少的資源、更快的效率達到目標。
更重要的是，我們期望這些有經驗的人，能夠慷慨地將自己的經驗傳授給那些經驗尚淺的年輕人，從而達到團隊整體實力提升的效果。
想得挺好，效果怎麼樣呢？
在我的經歷中，無論你請誰來，無論你怎麼爲他配備資源，放心，他曾經踩過的坑還是會在這裏重新踩一輪，那些栽過的跟頭也繼續要栽一次，甚至踩得更深，栽得更狠。
這是爲什麼呢？
當然，不排除我身邊都是一些倒黴鬼，或者引進的人都是水貨。但相比之下，我更願意相信是因爲客觀環境因素的不同，從而導致原有經驗的可落地性變差。
怎麼理解這句話？我來說個親身經歷的案例。
去年，我寫過一篇 #故障：一場由虛擬化存儲引發的分佈式緩存性能悲劇# 的文章，詳細描述了一次由虛擬化存儲引起的分佈式緩存故障。
在文章發佈後的第二週，就曾有讀者提出質疑：“核心中間件，居然出現如此小兒科的故障，你們上線之前不做高可用與性能的測試嗎？”
我的回答是：“我們不僅在上線初期做了非功能性混合場景測試，而且每週還會做常規性壓力測試。值得一提的是，代理層的核心代碼是團隊中某架構師從以前公司帶來的，聲稱這套系統曾經歷過 “雙11” 的洗禮，流過血，流過汗，值得信賴。
無論怎麼想，似乎都會相信這套系統是可靠的、高效的。但萬萬沒想到，在穩定運行很長一段時間後，卻無聲無息地死在了I/O爭搶上……
因爲事故的影響範圍太大，在事故覆盤的過程中，業務方老大吐槽，“我平時偶爾也參加你們的技術評審會，最常聽見的詞就是 ‘高可用’、‘高性能’，看了大家是很重視的，也確實做了很多工作，但爲啥一遇到實際場景，就不奏效了呢？”
我當時正在氣頭上，直接回了句，“是啊，我也想知道啊，等明天我打個電話問問服務器，爲啥他突然間發脾氣，不高可用了。”
就因爲這件事，整整一週，團隊的士氣都很低落。
事情過去一個月後，我請團隊小夥伴喝酒，一來緩解下情緒，二來提升下士氣。
酒桌上，我端起酒杯走到那位負責緩存的架構師面前，說：“別一臉頹廢，搞咱們這行遇到這種事情不是很正常嗎？一切都過去了，後面咱們再慢慢改進。”
他笑了笑，端起酒杯站起來，說：“哎……我一直對這套系統很有信心，沒想到出這種事，覺得太丟人了，搞得好像我只會耍嘴皮子似的。”
我拍了拍他，說：“別擔心，下次神會與你同在。”
自從有了互聯網+這個名詞之後，似乎到處都能看到或聽到各種高可用架構，並且還會有個看似很牛逼的人告訴你這個系統架構多麼牛逼，用某某框架你的系統就會起飛，但仔細想想，這對你來說有用嗎？
因爲他們只給你指了一扇門，告訴你通過那扇門你就有多牛逼，但鑰匙在哪裏呢？而且也沒有告訴你，在走到那扇門之前，用什麼方法才能把我從現有的坑裏拽出來？
記得在某技術大會上分享的結尾詞，我說過這樣一段話：
爲什麼別人的高可用架構，用到我這裏不起作用了呢？
因爲真正的高可用壓根就不用糾結架構設計，更不用糾結是否有大廠用過，對於一般的企業來說，只需要把注意力放在代碼的健壯性、主備設計及環境治理上就行了，不需要其他的。
忽略了這幾點，還談什麼高可用呢？
當然，有的人天生內心強大，把理論高可用也當成一種高可用，沒毛病。
作者：王曄倞
來源：喫草的羅漢訂閱號（ID:kidd_wyl）
dbaplus社羣歡迎廣大技術人員投稿，投稿郵箱：[email protected]