大家好，我是程式設計師魚皮，8 月 19 日下午，網易雲音樂突發嚴重故障，並登頂微博熱搜，跟黑神話悟空搶了熱度。
根據使用者的反饋，故障的具體表現為：使用者無法登入、歌單載入失敗、播放資訊獲取失敗、無法搜尋歌曲等等，幾乎是無法使用了，妥妥的 P0 級事故！
根據官方釋出的說明，本次故障的主要原因是基礎設施，導致網易雲音樂各端無法正常使用：
什麼是基礎設施？是指支援整個系統執行的基礎性服務和資源，包括伺服器、網路裝置、資料庫、儲存系統、內容分發網路（CDN）、各種雲服務、快取、DNS、負載均衡等等。像之前 B 站和小紅書大規模故障，就是因為某雲服務商的網路出了問題，可見基礎設施的重要性。
我不是內部人員，所以具體的故障原因不得而知，網上有很多猜測，什麼 “開發刪庫跑路”、“搬遷到新機房產生了問題”、“裁員導致降本增笑” 等等，但這些說法被官方否認了。
根據網上的訊息，這次的故障可能與網易雲自研的 Curve 儲存系統有關，當時網易官方稱該儲存系統上線 400 多天，從未出現資料不一致和丟資料的情況，資料可靠性達到 100%，服務可用性高達 4 個 9（99.99%）。
按理說穩定執行了這麼久的系統不應該自己出問題，據說是一位同學按照前人的文件執行了一個運維操作，導致了儲存系統的故障。一般來說，這麼重要的基礎設施的變更釋出需要走非常完備的流程，而且不會讓不熟悉的人按照前人的文件執行，除非有一種情況，就是 “前人” 已經不在了。根據網上訊息，該部門曾經歷過裁員，更有小道訊息說，該部門僅存的人員寥寥無幾。
真相我們不得而知，不過聽上去挺合理的。因為一般情況下，大廠內部是有灰度釋出、容災演練的，不會直接影響到所有使用者。
-
灰度釋出是指在更新 IT 基礎設施時，採用逐步部署的方式，先在一部分裝置上進行變更，觀察其效果。如果一切正常，才逐步擴大變更範圍。
-
容災演練是指對基礎設施在災難發生時的應急響應和恢復能力進行測試和驗證，確保在關鍵的基礎設施發生故障或災難時，系統能夠迅速恢復，減少業務中斷的影響。
大廠的架構師，尤其是基礎設施團隊的人員，一定是知道這些操作的，但為什麼沒有執行呢？可能是因為人手不夠、也可能是因為懶、還可能是因為現在的人缺失經驗、還有可能是前人留下的文件不全。總之，系統的穩定性和 “人” 有很大的關係。
讓我又想到了上次微軟全球藍色畫面的事情，果然嚴重的 Bug 往往只需要一兩名程式設計師、或者一些小的操作。
整個故障恢復歷時整整 2 個小時，已經是比較慢了，採用預備方案恢復服務、或者遮蔽部分故障、或者回滾釋出，應該都要不了這些時間，估計是資料出了問題吧。如果在故障中資料出現了損壞或不一致，恢復服務的難度的確會大大增加，為了確保資料完整性，可能需要進行資料恢復、重建索引、同步資料等操作，而這些都可能會延長故障恢復的時間。
目前還沒有看到官方的故障報告，所以這一切只是猜測了。
故障恢復後，網易雲音樂很快釋出了補償措施 —— 使用者可以免費領取 7 天會員權益！ 注意，只能在 8 月 20 日領取！
進入雲音樂就能在搜尋條看到領會員的入口了，雖然只有 7 天，差點兒意思，但作為一名網易雲音樂 10 級會員，我必須領爆！
從這個事情也能看出來，一旦故障發生了，頭大的可不只有開發和運維人員！產品同學需要快速制定補償策略，確保使用者滿意；運營和客服要緊急應對使用者的疑問和投訴，安撫情緒；而公關則必須迅速應對輿論壓力，控制事態發展，防止負面影響擴散。同時，管理層還需統籌協調各部門，確保問題得到全面處理。
我們自己也做了很多產品，也發生過故障，我們這小規模應對起來都汗流浹背了，很難想象網易雲音樂這種國民級產品背後的團隊，昨天承受了多大壓力。勞力越戴，責任越大呀！
朋友們，你們怎麼看待這次故障，有懷疑過自己網路或裝置的問題麼？