聲明：本文來自于微信公眾號InfoQ（ID：infoqchina），作者：Tina，授權轉載發布。
7月13日晚間，B 站因無法訪問登上熱搜榜。
昨天深夜，B 站出現訪問故障，無法打開，頁面提示加載失敗。除了網站和移動端顯示加載錯誤之外，B 站出品的輕視頻、剪輯軟件必剪等均無法打開，顯示頁面加載出錯。
一個網站的短暫崩潰，居然引起這么大的聲響?
公司2020年第三季度財報顯示，去年8月，B 站的月活用戶突破2億。最新數據則顯示，B 站月活用戶為2.23億，其中35歲及以下的月活用戶比重超過86%。
B 站故障之后，消息迅速擴散，“B 站崩了”沖上了各種熱搜榜。微博熱搜第一，知乎的提問下截至目前為止，總共有12727個回復。連朋友圈里，都被 B 站技術總監分享過的“高可用架構實踐”演講刷屏。
故障持續了一個多小時，同時崩潰的還有老牌二次元網站 AcFun（A 站）以及豆瓣、晉江，但豆瓣、A 站等很快就得以恢復了。
一個網站的“崩潰”，讓無數習慣了互聯網生活的人睡不著覺，也有不少網友一起幫忙分析到底是互聯網的哪個環節出了問題，甚至還因此驚動了消防局。
對于網傳“B 站崩了是因為有火情發生”，上海消防辟謠道:“經了解，位于上海市政立路485號國正中心內的嗶哩嗶哩彈幕網 B 站（總部）未出現火情，未接到相關報警。具體情況以站方公布為準。”
今年3月份，曾發生過數據中心失火造成360萬網站下線的事故，因此有人猜測是云海數據服務中心發生了火情，消防也對此表示了極大關注。
什么原因會導致網站宕機?
至14日凌晨2點15分，B 站所有功能均恢復正常。B 站官方7月14日凌晨發布消息稱，昨（7月13日）晚，B 站的部分服務器機房發生故障，造成無法訪問。技術團隊隨即進行了問題排查和修復，現在服務已經陸續恢復正常。
但是對于具體宕機原因，B 站并未作說明。InfoQ 聯系了 B 站相關技術人員詢問具體情況，截止發稿前仍然沒有得到答復。
對于網站宕機常見原因，開源基礎軟件公司 Zilliz 的質量保障團隊負責人喬燕良認為，主要可分為軟件服務引起的故障和硬件服務引起的故障。
軟件服務故障一般可理解為代碼邏輯缺陷，常見的是新增或更新某個功能而引入缺陷導致整個服務中斷;硬件服務故障一般是由于某些服務設備的損壞造成服務中斷，比如光纖被挖斷了。
互聯網服務中鏈路的每個環節都有可能導致問題發生，據另一位數據庫專家分析，因為這次 B 站主站都掛了，應該和數據庫沒有關系;宕機發生的時候，通過技術分析，可以看出 CDN 查不到相關機房的數據。由此推測，B 站這次應該屬于機房級別的故障，需要增強多機房容災能力。
這次故障，對 B 站的影響不小，綜合損失應該也不小，但如果去提升業務的連續性，還需要很大成本。常見的可用性通常以百分比表示，這也意味著高可用性不是絕對的。換句話說，100% 的可用性是不可能達到的，可用性從99.99% 提升到99.999%，每提升一個9，需要十倍百倍的成本。可用性的效果和開銷對應的比例并不是線性增長的，每提高一點可用性，所花費的成本都會遠超之前。
雖然企業需要在這個非線性增加的成本和可用性之間進行權衡，但對于一些公司來講，肯定還會去嘗試獲得更多的 “9”，減少應用的宕機時間，降低宕機成本。
如何用合適手段降低宕機風險、提高服務的高可用呢?喬燕良認為:“首先從架構上，建議采用云原生架構，實現自動容錯機制和故障隔離，能夠在服務出現故障時快速遷移或回滾。對于網站來說，實現數據服務高可用的挑戰可能會比較突出，因為目前架構下多數服務都是無狀態的、可以完成平滑遷移，而數據服務往往是有狀態的，云原生服務（如目前的一些云原生數據庫）通常具有很好的自動容錯、彈性伸縮、安全隔離等功能。其次為防止硬件故障類風險，需要有完善的災備方案。針對傳統服務架構已經有比較成熟的同城雙活和異地災備方案，而基于云原生的高可用方案，比如 kubeadm 也已經比較成熟，只是國內企業在這塊投入比較‘節約’。”
就像人工智能無法替代人類一樣，目前的軟件仍然是不可完全信任的。我們的世界瞬息萬變，我們的軟件（包括人工智能）只是對世界當前場景的理解和判斷，隨著時間的推進，某一時刻這些理解判斷的邏輯會出現不適用甚至錯誤。這一時刻何時到來、環境又會變得怎樣，將永遠是最不可預測的因素。
