構建持續高可用系統的破局之道

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 故障，雖然等級都是一樣，但是影響和破壞力是天差地別。

總而言之，構建持續高可用系統的破局之道，其實在於公司和組織的技術文化上，而非技術手段。