2026 年 9 月 17 日 Forever 測試服開放的夜晚，玩家被踢下線，任務開啟要等一分鐘，伺服器不得不重新啟動。資深製作人 Tom Ellis 拆解了這三次故障——沒有一個與遊戲本身有關。

2026 年 9 月 17 日 Forever 測試服開放的那個夜晚不太好過：玩家被踢下線，任務和寶物開啟要花整整一分鐘，伺服器還得在進度歸零的情況下重啟。暴雪發布了一份事故分析——裡面沒有一句對遊戲本身的抱怨。

整套東西跑在哪裡

測試服跑在 PTR 環境上，不是正式服。這種環境只有一個，而且是區域的。從歷史上看，WoW 的測試期對基礎設施幾乎沒什麼負擔，所以硬體從來沒有認真地為它做過容量規劃。Forever 上線也是按這個思路來的。

那天晚上的三個問題，全是從這裡長出來的。

第一件：大規模斷線

找了三十分鐘——其實沒什麼好找的。所有服務的 CPU 和記憶體都正常。Battle.net Game Service 團隊從他們那邊看到的也一樣。兇手最後是一個用來保護 BGS 免於崩盤的負載計數器：一個小型的區域環境用兩條連線硬塞進了海量的登入流量，而這個計數器判斷是否該拉警報的算式當場失靈。

把連線調到八條之後——斷線就停了。據資深製作人 Tom Ellis 所述，這是計數器第一次在沒有伴隨 CPU 負載的情況下被觸發。他在 X 上的帖子因為一句「20 years, always something new」傳開了。

第二件：撿寶和交任務時卡頓

寶物開得很慢，任務也要很久才能接到。兇手是 PTR 的資料庫：新資料表加上大量 insert 流量，讓查詢規劃器抱著過時的資料假設不放。Oracle 的工程師手動跑了一次統計，並打開自動重算。速度立刻就回來了。

第三件：重啟

幾個小時之後，所有人都得被踢出去。真正跑遊戲的 WORLD 池把 CPU 燒得發燙、又撞到記憶體上限，而 OOM killer 已經開始收割第一批虛擬機——還可能連帶把 hypervisor 一起拖下水。

Classic 的工程師找到了原因：空白的地圖沒有正確關閉，伺服器在慢慢吃自己的資源。修補程式通過了驗證，但需要重啟。順便也加了備援 WORLD 池和第二個區域服務實例。這之後夜晚就平靜下來了。

為什麼沒算到負載

容量是按過去 WoW 測試期的經驗規劃的。可是這次來的是上市首日規模的人潮——這樣的數字已經很久沒見過了。首席設計師 Josh Greenfield（Aggrend）在 X 上寫道：「在 Blizzard 的 17 年、Classic 團隊的近 8 年裡，我從沒見過這樣的數字。」

對 11 月 4 日來說這意味著什麼

直接來說——什麼都不意味。正式服環境跟測試期沒關係，這三次故障沒有一個能說明遊戲本身的準備程度。間接來說——倒是說明了一些事：實際需求比暴雪內部預測更高，這代表上市時的排隊情況值得事先納入考量。

實務上

• 測試期的故障是 PTR 測試環境的問題，不是遊戲本身的問題；到了 11 月 4 日已經不相干。
• 如果上市當天要排隊——這就是 9 月 17 日測試期同樣的故事：需求比暴雪預期的高。
• 如果 11 月 4 日開服頭幾個小時你被踢下角色——這已經不是「壞掉的上市」，而是伺服器過載的正常劇情，就像過去 WoW 上線時那樣。