這是頭哥侃碼的第305篇原創
周末和朋友閑聊，有位不嫌事大的「吃瓜大佬」，又提起與國內雲廠商宕機的事來。
剛剛過去的4月某天，騰訊雲楞是崩了 74 分鐘（15:31 - 16:45），還波及全球 17 個區域與數十款服務。依賴雲API提供產品能力的部份公有雲服務，也因為雲API的異常出現了無法使用的情況。
去年11月末，阿裏雲宕機的事沖上熱搜，什麽阿裏雲盤，什麽淘寶，什麽閑魚……幾乎全線產品受到影響。
這沒過幾天，這滴滴系統崩潰的事直接沖上了熱搜，不僅讓打工人直接打不到車，甚至連共享單車都掃不到，這一 「罷工」 就是好幾天。
……
你們瞅瞅，這沒完沒了的故障，對企業不管是財務和聲譽的損失都是巨大的，更有網友辣評到 「這是降本增效一刀切到了大動脈上」。
1
國內的公有雲都是垃圾？那國外也這樣嗎？
去年，就在滴滴崩潰事件發生後不久，我曾在某社群網站上看到過這樣一則評論。
「還是國外的雲廠商牛逼，這些年我就沒聽到過國外雲廠商宕機！我們和人家還是有差距啊！」
「你真是一條崇洋媚外的舔狗。」，這是我給這哥們留下的評語。
發泄完情緒之後，我還特地進行了搜尋和整理，主要是為了證明任何一個公有雲供應商，在發展的歷史長河中，都遭遇了這樣那樣的宕機、故障。 或因人為因素、或因雷電太兇、或因機房停電、或因光纜被挖、或因程式碼錯輸……這些問題的出現與解決，正好也是公有雲服務不斷最佳化與提升的過程。
這玩意是科學，不是跳大神。
咱們以全球公有雲 「一哥」 AWS 為例，近十年來可查詢記錄的宕機事故高達20次，咱們來看看最近的5次。
【2018年】
AWS網路故障，故障持續時間不詳。
2018年3月，亞馬遜Alexa智慧家居出現了區域性失靈，使用者在家中喚醒亞馬遜Echo系列產品時，Alexa會讓使用者重試並報告找不到伺服器。AWS數據中心硬體故障導致雲服務影響，持續時間30分鐘。
2018年5月31日，因北維吉尼亞地區的數據中心出現硬體故障，AWS再次出現連線問題。在此事故中，AWS的核心EC2服務，Workspaces虛擬桌面服務以及Redshift資料倉儲服務均受到影響。AWS管理控制台故障，故障持續近6小時。
2018年7月18日訊息，亞馬遜盛大的購物促銷活動Prime Day遭遇了史上最大的尷尬，亞馬遜網站和套用出現了重大技術故障，威脅到了其持續36個小時的銷售盛宴。
與此同時，亞馬遜核心產品AWS雲服務也出現了中斷。客戶登入AWS管理控制台時，將收到一條帶有狗圖片的錯誤訊息，消費者Prime Day在亞馬遜網站上看到帶有狗的圖片類似，該故障持續了將近6小時。
AWS南韓伺服器中斷，故障時間持續一個多小時。
2018年11月23日亞馬遜網路服務（AWS）的核心伺服器在南韓全國發生中斷，導致兩個主要的加密貨幣線上交易平台停止運作。AWS是全球廣泛使用的雲服務之一，受到內部核心伺服器故障的影響，導致主要的數位資產交易平台Upbit和Coinone戛然而止。據外媒報道，幾個主要的電子商務中心在大約一個小時內也無法存取。
【2019年】
AWS北京區域因光纖被挖斷中斷新例項啟用，故障時間持續不詳。
2019年6月1日晚，AWS北京區域CN-NORTH-1地區的隔夜道路施工中有幾處光纜被切斷，導致可用區無法連結Internet，進而引發所有可用區中新的例項無法啟動的故障，包括EC2 API啟用故障。因而EC2 API在整個CN-North-1區域都不可用。
……
2
故障那麽多，難道真的只是技術問題嗎？
事實上，任何軟體系統都難以避免故障的發生，無論是國內頂尖的BAT，還是國際巨頭如Google、Amazon、FB、Twitter等，都無法完全杜絕故障。隨著業務規模的擴大和系統復雜性的增加，問題和故障自然也會隨之增多。
然而，這並不意味著我們應該對故障視而不見。 相反，我們應該正視故障，將其視為技術和管理上的挑戰。
故障並非表面現象，而是深層次技術和管理問題的反映。 因此，作為負責人的目標不應該是消除故障，而是要透過設計更健壯的系統、完善故障隔離和快速恢復機制等措施，降低故障對業務的影響。
在接受故障現狀的同時，團隊負責人也應該擁抱風險，將註意力放在解決技術和管理問題上。比如說，人員技術是否過硬、自動化平台是否完善、線上敬畏意識是否足夠等問題，都是導致故障頻發的重要原因。
此外， 團隊負責人 還需要關註可觀測性建設和故障預案的完善程度。只有把問題定義清楚、找到根源，那才能真正降低故障對業務的影響。
說白了，很多人壓根不明白什麽是成本、什麽是效率。
這降的是應該是系統的復雜度，這提的應該是系統的可觀測性、服務間松耦合以及管理有效性等方面。
很可惜，國內的很多負責人，不僅在專業性上是個半吊子，而且還選錯了路。
最後，我們應該認識到，開發和運維是密不可分的兩個環節。
只有讓專業素質過硬且具備高情商的管理者來領導團隊，才能確保業務順暢執行並降低故障發生機率。
總之， 在面臨系統故障時，為何難以迅速辨識原因並恢復服務？
這背後的問題值得我們深入探究。 是否因為監控體系尚不完善，導致告警繁多而使人員產生麻痹心理？ 是否因為問題定位效率低下，使得故障的根本原因遲遲無法確定？ 又或是因為故障隔離機制不夠成熟，以及應急預案僅停留在紙面，無法有效執行？
必須承認，在故障處理過程中，開發和運維的角色各有側重，互為補充。
開發團隊專註於功能的實作與創新，而運維團隊則負責確保系統的穩定與可靠。兩者雖有交集，但專長領域各異。
因此，我們不能簡單地將故障歸咎於某一方，更不能以處罰作為解決問題的手段。
這種做法只會掩蓋問題，使小問題累積成大問題，最終引發更大的故障。
3
透過現象看本質，再說點大道理
老實說，一個優秀的技術團隊需要擁有既懂技術又擅長管理的領導者。
這樣的領導者不僅能理解技術細節，還能洞察團隊動態，制定合理的工作流程和運作機制。
在故障發生時，他們能夠迅速作出判斷，協調團隊資源，有效應對挑戰。
在這方面，AWS等海外企業設立的SRE（Site Reliability Engineer）崗位值得借鑒。SRE不僅具備深厚的運維經驗，還具備開發背景。他們透過標準化、自動化、可延伸和高可用等手段解決運維問題。這一崗位的設定旨在打破開發與運維之間的隔閡，實作兩者的緊密協作與高效溝通。
然而，要真正實作這一目標，公司決策者們應該要關註團隊建設和專業素質的提升。
畢竟一個優秀的團隊需要具備強大的心臟和高情商，能夠應對各種挑戰和壓力。因為只有當一個 系統的可觀 測性和故障預案的制定與執 行背充分考慮與落實的時候，一群做事的楞頭青們 才能確保系統在面對故障時能夠迅速恢復並保持穩定。
此外，我還呼籲大家要摒棄一些錯誤的觀念。
比如，我經常聽到一些團隊管理者在那嚷嚷：「先讓業務跑起來，故障機率很低，別擔心」。其實這種心態是很可怕的，因為這只會讓我們在面臨故障時手忙腳亂，更可怕的是，這會導致你在 系統設計之初就會先入為主的認為 「先跑，再說」。
於是，人性的懶惰被充分的激發了，什麽故障預防，什麽應對措施，在業務利益面前似乎都不再重要。
好了，咱就嘮到這。
最後，我還是想對那些習慣於 「燒錢 + 圈地模式」 的大佬說幾句。
在這個內卷且產能過剩的存量時代，技術團隊應該更關註降本提效的真正內涵。在有限的時間和成本下，拼盡全力去降低系統的復雜度成本，提高系統的可觀測性和松耦合程度。
別再每天沈浸在PPT的夢幻之中，否則 企業的長遠發展與堅定信念，遲早毀在你手上。
