2023年的互聯網世界，「草台班子」、「降本增笑」、「開猿節流」成為大家互相調侃的關鍵詞。苦笑過後，問題還在，事故終要復盤，未來仍需規劃。從架構角度看，我們應該怎麽去認清高可用的本質，並真正在業務場景中做好高可用，這是本文想跟大家探討的問題。
2023年過去了，但是相信沒多少技術人會特別懷念它。這是不平靜的一年：首先是大大小小的公司各種花式裁員，35歲危機的焦慮在行業蔓延；其次就是各個大公司蘿蔔蹲式的各種 P0/P1 故障，頻繁占據了熱搜榜單。
雖然事後各個公司公布的故障原因五花八門，例如有的故障是因為某地域 IDC 冷凍系統故障，有的故障是因為升級工具 bug 導致伺服器被誤下線，有的故障是因為 K8s 版本升級導致容器全部宕機……等等。但是這樣的解釋很難讓人信服為什麽2023年會成為多事之秋的一年，畢竟機房故障、各種升級操作等以前也都存在，並不是2023年獨有的。
那到底是什麽原因導致各個大公司頻繁的線上故障呢？
突然之間，「降本增笑」成了大家的共識：因為公司裁掉了經驗豐富的35歲以上的一二線老員工，留下來的技術人員有的是年輕的，有的是便宜的，有的是新招的。雖然可能降了成本，但是很多系統踩坑經驗和隱含陷阱都隨著老員工的離去而遺失，系統容易出問題也就不奇怪了，而一旦出問題又沒有經驗豐富的老員工能夠快速處理，問題影響變得更大，持續時間變得更長，之前各種技術大會上 PPT 寫的天花亂墜的異地多活、高可用等高大上的方案，也都形同虛設，成了全網吃瓜群眾的笑料。
這個解釋確實有一定道理，但是不是不降本就不會增笑呢？
其實遠沒有那麽簡單，今天我們就來聊聊構建持續高可用系統背後的困境和挑戰。
一、高可用的達摩克利斯之劍
首先，思考一個終極的類哲學問題：我們能否構建出永不出問題的系統，或者退一步講，能否構建出不出大問題的系統？
很遺憾，答案是「不能」，因為有兩條定律成了高可用系統上面懸著的達摩克利斯之劍。
第一條定律是「熵增定律」： 在一個孤立的系統裏，如果沒有外力做功，其總混亂度會不斷地增大，最後達到一個無序的狀態。
「熵增定律」本來是描述物理學方面的系統的，但是類社會的各種系統也是完全符合「熵增定律」的，無論是我們所處的公司，還是我們開發的各種軟體系統，都會遵循「熵增定律」。
對於軟體系統來說，「熵增」是無處不在的。例如：
為了完成某個領導年度 KPI，原本需要6個月的計畫，被壓縮到2個月，程式碼加班加點才能寫完，怎麽方便怎麽來，埋下大量的隱患和暗坑；
產品經理為了績效堆需求數量，做了大量無用又別扭的需求，程式碼經手了一茬又一茬的人，被改得復雜又看不懂，新需求都是另起一個if重新寫，系統慢慢成了「程式碼屎山」；
為了在市場競爭中先對手一步，技術團隊被當成生產隊的驢一樣驅趕做各種新需求，技術債越來越多，但只要不到崩潰那一天，是不可能有機會停下來清理技術債的；
好不容易花大力氣做完了重構，後面新來的人不熟悉，又是按照自己的理解來到處改，團隊又沒有 code review 機制（程式碼都寫不完，誰還有時間和精力去 code review），重構的模型和約定慢慢又被腐化了；
技術不斷在發展，各種新技術層出不窮。技術團隊不管是為了自己的績效也好，是為了業務的發展也好，最終都會大機率選擇不斷嘗試和引入新技術。雖然確實能享受新技術的一些好處，但也帶來了復雜度和風險的增加。
這些問題有破解方法嗎？看起來都可以破解，「只要……」 就行了，但實際落地會發現，一個都破解不了，因為有人的地方就有江湖，而技術團隊在這些場景中，基本都是最弱勢、最沒有話語權的。
第二條定律是「墨菲定律」： 任何可能出錯的事情最終都會出錯 。
好吧，假設我們的老板真的懂技術願意給技術團隊償還技術債，假設我們的 leader 真的時刻關註系統品質，假設我們的產品也都像微信張小龍一樣盡量克制，是不是就意味著我們的系統就不會出大問題了呢？
很不幸的是也做不到，墨菲定律告訴我們只要你的系統還在執行，就總有可能出錯的。例如：
機房空調可能會損壞，伺服器可能起火，網路可能被挖掘機挖斷，網線可能被老鼠啃破，海底光纜可能被船拉斷；
你用的 MySQL 一定會有 bug，K8s 也一定會有 bug，Nginx 也一定會有 bug……等等；
你的系統程式碼也一定有 bug，只是你現在不知道 bug 在那裏而已。
有的人可能會說，我們做了異地多活架構啊，出故障後切換就可以了。但實際上異地多活本身可能就有問題，異地多活相關的輔助系統在真正需要切換的時候也可能用不上。
基於上述分析，我們可以看到，構建永不出問題的系統是不可能的，如果你的老板看到出了問題就說技術團隊不行，那麽我建議你可以嘗試給他科普一下「熵增定律」和「墨菲定律」）
當然，我們也不能拿「熵增定律」和「墨菲定律」來作為躺平的借口。雖然無法構建永不出問題的系統，但也不能讓系統天天出問題，所以我們還是需要考慮如何去構建持續高可用的系統。
二、構建持續高可用系統的困境
但是在實際落地高可用建設的時候，會遇到第二個挑戰： 神醫悖論 。
「神醫悖論」是我從扁鵲回答魏文侯的問題裏面概括的一個名詞。原文大意是魏文侯問扁鵲三兄弟中誰的醫術最高明。扁鵲回答說：「長兄最善，中兄次之，扁鵲最為下。」扁鵲醫術精湛，神醫名聲遠播，為什麽扁鵲卻認為大哥二哥比他強呢？
扁鵲解釋說：大哥治病於病發之前，一般人不知道他事先除去了病因，故而他的名氣無法傳出去；二哥治病於病情初發之時，一般人以為他只能治輕微小病，故而他的名氣只及本鄉裏；而扁鵲治病於病情嚴重之時，所以他們認為扁鵲的醫術最高明。
我們在建設高可用系統的時候，一樣會遇到「神醫悖論」。不管公司是有專門的 SRE 團隊，還是各個團隊的直接負責系統高可用；也不管公司是為了可用性做了很多基礎系統，還是各個團隊靠人力來保障可用性，都會面臨這個問題： 你怎麽證明你的可用性做得好？你的可用性投入是有很大價值的？
假設1年沒出問題，能說明是你的可用性工作做得好嗎？
很難，因為大機率可能是你運氣好。所以也許有時候去廟裏燒點香，也能達到這個效果。某互聯網大廠以前準備雙十一的時候，很多團隊都會事先去靈隱寺拜一拜的，據說確實拜了和不拜有差別。
假設今年出了一個 P0 問題，就能說明你可用性工作做得不好嗎？
也不一定，因為也可能是你運氣不好。即便都是 P0 問題，如果沒有你做的這些可用性工作，時間可能從1小時變成6小時，損失可能從1000萬變成8000萬，而你做的可用性工作，投入才100萬。
你兢兢業業地像扁鵲的大哥一樣，做了很多事情把各種問題都消滅在萌芽狀態，全年下來沒有發生任何 P0/P1/P2 故障。年底匯報的時候回過頭來一看，全是一些看起來雞毛蒜皮的事情，你怎麽匯報才能拿到績效？
相反，隔壁團隊雖然上半年出了一次 P0 故障，但是換了一個 leader 後，新 leader 大刀闊斧重構架構，搞多活建設，年底匯報 PPT 都寫了50頁，績效不是 S 就是 A。你難道跟老板說「我是扁鵲大哥，他只是扁鵲而已」？
從技術的角度來說，構建持續高可用的系統實際上就是要和扁鵲的大哥一樣，要花費很大的時間和精力來做各種瑣碎的事情，將問題消滅在萌芽狀態。雖然不能徹底消滅所有問題，但是可以大振幅減少發生大問題的機率。
例如：單元測試、code review，資料庫設計規範、監控系統、應急系統、架構評審、方案評審、系統重構、全鏈路測試、混沌測試、故障定期演練、灰度釋出……等，這些事情散落在各個團隊，計畫的各個階段，但是都和高可用有一定關系，對持續高可用有一定的作用。
但是從人的角度來說，要想透過高可用建設拿到好的績效，卻需要和扁鵲一樣。只有等到系統已經被證明不行了，系統故障影響太大了，老板或者領導才會突然發現可用性的價值，才會給予技術團隊時間、人力、資金來做高可用建設。
例如：微服務演進、彈性架構、同城雙活、異地多活、多雲建設、混合雲演進……等，一看這些技術名詞就能看出來高大上，規劃這樣的計畫，技術團隊幹起來都特別有勁，年底匯報寫 PPT 都能寫出花來。
從老板的角度來講，一樣也面臨神醫悖論帶來的挑戰。假設老板心甘情願每年投入1000萬給某個團隊來做高可用，最後年底一看1000萬下去，就做了一堆瑣碎的事情，心裏肯定也會有疑惑：你們這幫小子，拿了我1000萬，弄了一個幾十人的團隊，一年到頭就幹這點事？
如果老板願意投錢的時候都會有這種困境，那麽當老板開始「降本增效，開猿節流」的時候，更加會毫不意外地優先裁掉做可用性建設的團隊和人員，而往往在團隊裏面負責這部份工作的員工，都是經驗豐富但成本也高的老員工。
於是乎，「降本增笑」幾乎成了不可避免的結局。
三、破局之道？
綜合上述的分析來看：結果的不確定性，價值難以準確衡量，工作不容易被看見等因素，讓實踐中的高可用工作都變成了 運動式高可用攻堅計畫 。
簡單來說就是陷入了一個無解迴圈：前人積累太多技術債，系統磕磕碰碰逐漸越來越不穩定，但是沒有人願意花太多時間去整體解決，只希望保證擊鼓傳花的雷不要在自己手裏爆炸即可。
等到哪一天某個倒黴蛋運氣不好，系統終於發生了「史詩級」的故障，成功讓公司上了熱搜；此時老板或者大領導們終於頓悟：如果系統再來一次類似的事故，業務或者自己可能就要吃不了兜著走了。
於是公司或者大領導開始了運動式的高可用攻堅計畫：先找一個原來的倒黴蛋背鍋，讓他走人或者降級；然後找一個新的幸運兒來負責高可用的「徹底最佳化」。幸運兒來了之後肯定不會走扁鵲大哥的路線，而是直接整高大上的計畫：重構、雙活、多活、多雲、混合雲等。
基本上這樣的計畫建設可以做1年，徹底完善可能需要2年。做完後系統整體的高可用能力確實能上一個新的台階，畢竟那麽多問題都明擺著，光解決這些問題就能夠很大提升系統品質，更何況還做很多高可用的架構、基礎設施等，肯定能夠大幅提升系統的高可用能力。
於是新的幸運兒大機率會升職加薪，走向新的職業巔峰，老板或者大領導們也終於放心了。
但是系統正是從這時候開始又慢慢地進入了新的一輪迴圈：繼續拼命趕計畫忽視品質；繼續堆各種雜亂的需求；原來做高可用相關的人員逐漸縮減，調崗到其它業務開發團隊……就這樣又慢慢地逐漸退化，直到新一輪的運動式高可用攻堅計畫來臨。
有什麽有效的破局之道打破這個迴圈嗎？坦白的說：幾乎沒有。
絕大部份人能做的就是期望自己不要成為這個迴圈中的倒黴蛋，或者自己能夠成為這個迴圈中的幸運兒。
如果說一定要打破這個迴圈，其實關鍵不在技術團隊身上，而是取決於老板和大領導們。
當然，並不是要老板和大領導們自己買一本【SRE 谷歌運維揭秘】的書籍自己去學習如何做高可用建設，關鍵在於轉變對持續構建高可用系統的認知，然後鼓勵技術團隊持續在高可用方面進行一定的投入。
首先，意識到系統和人類似，高可用的系統需要持續建設。
健康的系統和健康的身體都是要持續投入的，而不是靠一段時間內突擊運動和打興奮劑。在日常的工作中，給技術團隊留出一定的時間和精力來做一些高可用方面相關的工作，即便這些工作看起來在當時都沒有明顯的作用。
其次，不要那麽功利化。在高可用方面保持一定的人員和投入，即便看起來這些都是「成本壓力」。
就像人鍛煉一樣，很難說今天跑了 5KM，身體就一定變好了，甚至有可能今天跑了 5KM，過兩天還會感冒發燒。但長期來看，堅持鍛煉的人身體大機率會比不鍛煉的人要好很多。
因此，公司和組織可以安排一些人員來專門負責高可用方面的一些工作，保證高可用相關的一些系統、工具、規範有人去推動落地。就算這些人沒事找事，那他們也是在尋找系統中的一些隱患和不足，或者嘗試對系統進行最佳化和加固。
第三，堅持定期給系統體檢和保養。
就像人需要定期體檢，車子需要定期保養一樣，系統也需要定期的檢查和保養。千萬別不出事就萬事大吉，出了事就莫名驚詫！
可以每年給系統進行一次小的復盤和盤點，每兩年給系統進行一次全面的檢查和最佳化，大機率就可以避免一些災難級的故障發生。
即便運氣不好發生了嚴重事故，也可以大大減少故障的影響時間。要知道一個2小時的 P0 故障和一個12小時的 P0 故障，雖然等級都是一樣，但是影響和破壞力是天差地別。
總而言之，構建持續高可用系統的破局之道，其實在於公司和組織的技術文化上，而非技術手段。
作者介紹
李運華， 前阿裏 P9 級資深技術專家，16年軟體設計開發經驗，曾就職於華為、UC、阿裏巴巴、螞蟻金服，承擔架構設計、架構重構、技術團隊管理、技術培訓等職責；專註於開源技術、系統分析、架構設計，對互聯網技術的特點和發展趨勢有較深入的研究和理解，對於高效能、高可用、業務架構、系統解耦等有豐富的經驗，著有【編程的邏輯：如何用物件導向方法實作復雜業務需求】、【從零開始學架構】。
來源丨公眾號： 騰訊雲開發者 （ID： QcloudCommunity ）
dbaplus社群歡迎廣大技術人員投稿，投稿信箱： [email protected]
