驚魂半小時：一次播放 404 的幕後排查
上海時間 6 月 25 日凌晨，部分使用者播放 404、部分卻正常。一次機率極低的儲存層（FUSE/NFS）核心崩潰，從回報故障到恢復約 40 分鐘——這是那半小時的幕後排查與復盤。
提示
上海時間 6 月 25 日凌晨 01:05，部分使用者播放報 404，另一部分卻完全正常。這是一次機率極低的儲存層故障，從回報故障到徹底恢復約 40 分鐘、定位後 15 分鐘內處置完畢。本文還原那半小時裡，我們如何用排除法一路鎖定真兇。
一半人中招、一半人沒事——這種「薛丁格式」的故障最讓人頭皮發麻，因為它幾乎排除了所有「一體適用」的簡單解釋。接下來的半小時，我們靠排除法把範圍一步步收窄，最後在最底層找到了真兇。
建議
先認識三個角色
-
推流閘道：你按下播放後，負責去後端把影片內容取出來、轉發給你的「前台」。
-
儲存叢集：真正存放海量影片的地方，規模 2PB 等級，完全自建。
-
線路調度：依時段自動切換最佳分發線路，讓不同地區的使用者都盡量快。
一個播放請求要穿過一條固定鏈路：使用者請求 → 推流閘道 → 儲存叢集 → 回傳影片串流。崩潰發生時，斷點就出在「儲存叢集」這一環。這也順帶解釋了「為什麼有人正常、有人 404」——路徑只有一條，差別只在儲存這一環；只有恰好命中受影響內容的請求才會失敗，其餘照常。
第一個嫌疑對象：播放器
最先被懷疑的總是離使用者最近的那一層——是不是某些播放器更新後改了取流方式，不相容了？
這個假設幾分鐘就被推翻：團隊拿不同的播放器交叉測試，全都能重現。問題與用戶端無關，根子在伺服器端。
第二個嫌疑對象：線路調度
第二直覺指向線路調度。我們有分時自動切換線路的機制，很自然會懷疑：是不是調度環節有快取沒及時刷新，把一個「已經不存在的位址」發給了使用者？——這甚至能解釋「為什麼只有部分人中招」。
但兩個事實對不上：
-
當前根本不在任何預設的切換時段；
-
那些根本不走這套調度的線路，也一樣在報錯。
建議
為什麼「快取沒刷新」是個合理懷疑？ 分發系統為了快，會把「去哪條線路取內容」的結果快取一小段時間。如果快取裡存了一個已經失效的位址，使用者就會拿到一個指向「不存在」的連結——表現出來正是 404。所以它一度是頭號嫌疑；只不過這次，證據不支持。
調度被排除。嫌疑範圍進一步收窄，指向了我們最不願意看到、也最難處理的地方——儲存叢集本身。
真兇：儲存層的核心級崩潰
定位到儲存節點後，真相浮出水面：節點上發生了一次極其罕見的 FUSE 檔案系統核心級崩潰，並連帶把依賴它的 NFS 共享一起拖垮了。
重要
FUSE 和 NFS 是什麼？
-
FUSE 讓檔案系統能在「使用者態」執行，靈活度很高——代價是，一旦它異常結束，掛在它上面的目錄會瞬間變成「無法存取」。
-
NFS 是把一台機器的目錄共享給其它機器使用的網路檔案協定，是叢集內部互通的「血管」。
當底層的 FUSE 崩了，上面的 NFS 共享自然也跟著失效——底層存取一中斷，上層取到的部分路徑就變成了「無效 / 不存在」，推流閘道對外就只能回 404。
到這裡，整條因果鏈閉合了。
搶修
判斷清晰之後，動作很快：
- 重新掛載崩潰的檔案系統，恢復底層存取；
- 刷新共享匯出，讓其它節點重新建立連線；
- 重啟那些掛載依賴被打斷的推流閘道——它們仍「釘」在已經失效的舊掛載上，只修底層還不夠，必須讓它們重新綁定。
三步走完，服務全面恢復。從 01:05 使用者回報故障，到 01:29 鎖定儲存層，再到 01:44 徹底處理完畢——全程約 40 分鐘，而真正定位之後，15 分鐘內就完成了處置。
復盤：自建 2PB 儲存，意味著什麼
這是一次機率極低的故障，但它真實地暴露了一件事：維護一套 2PB 規模的實體儲存叢集，維運難度遠高於直接套用雲端硬碟方案。 關於這套儲存與頻寬規模，見關於本站。
雲端硬碟把這些複雜度都藏在了服務商背後；而我們選擇自建，就意味著從核心崩潰、檔案系統、共享協定到推流鏈路——每一層都得自己扛。它對團隊的技術儲備和應急能力提出了更高的要求。這一次，我們扛住了。
下一步
恢復服務不是終點。我們已經在做兩件事，爭取把隱患壓在下一次「驚魂半小時」發生之前：
-
給底層儲存硬體做一次健檢，排查陣列控制器等環節是否存在潛在風險；
-
複查執行環境，看有沒有被忽略的異常因素。
提示
本次日誌完結。