【激戰2】ArenaNet內部——有關遊戲服務器關停的分析

和風議會發布

鳴謝

本文由和風議會搬運翻譯組——風景 翻譯。微信公眾號由和風議會小風箏編輯。本文為激戰2美服官網文章本文所使用的部分譯名為戰火互娛所提供的官方譯名。

嗨！我是Robert Neckorcuk，ArenaNet的平台團隊負責人。我和我的團隊主要為激戰系列遊戲提供一些後端服務：登錄服務器、聊天服務器、網站等等。作為後端服務組，我們與另外兩個團隊（遊戲運營和發布管理）密切合作，同時還和遊戲研發、市場分析、客戶支持等部門協同。不過我們的工作重點還是維護遊戲及其基礎構架的實時狀態。

激戰系列最令人印象深刻的一點就是它強大的的在線服務可用性。盡管迄今為止我們的工作還算成功，但整個過程中仍然有一些小波折。在這裏，我將分享一下上次遊戲停服的細節和經驗教訓，以便我們繼續改進，更好地履行對玩家們的承諾。

太平洋時間2020年5月11日星期一早上6點，我接到了一個電話。我敢向你們保證，這個日期絕對是准確的，因為那天的事情我到現在還記憶猶新。我們的遊戲運營團隊發現激戰2的實時數據庫發生了回檔，玩家從遊戲服務器接收到的信息開始出現錯誤，我們的內部工具顯示了大量其他相關的警報和錯誤。

操蛋了。

我從沒經歷過那麼刺激的周一。事實上，我寧願我的周一過得平淡一點。我登錄到我的工作台，和其他人一起調查到底發生了什麼，以及我們可以做些什麼來讓遊戲恢複正常狀態。對於一個目標是“永遠在線”的團隊和公司來說，我們調查到了最壞的結果：我們必須關閉遊戲才能將數據恢複到良好狀態。由於這是我第一次遇到這樣的事件，我花了一段時間才確定關閉服務器需要經過哪些許可和批複流程。就在上午9點之後，我提交了修改，禁止遊戲登錄，並關停了激戰2的歐洲地區服務器。

不斷地更新迭代

在這次停服期間，激戰2的歐洲數據中心停擺了20多個小時。除了那些幾分鐘的小插曲以外，上次激戰2停服還是在2016年8月23日。雖然處理這些突發狀況從來都不是一件有趣的事，但我們能夠把這些狀況作為一個個學習的機會，從而改進我們的基礎構架和工作流程。

在激戰系列遊戲中，我們對突發事件的處理流程與市場上大多數遊戲公司一致：

確定問題的範圍：是在一台服務器、一個數據中心還是一個編譯版本中。我們可以通過這個來確定是否可以把調查範圍縮小到部分服務或地區。確定一種解決方法以使服務盡快恢複正常，而這將是一次規定和實際之間的權衡：如果我們在某一次通過強行修改某些數據來讓服務器正常工作，我們在之後的事件中還會不會破解其他東西以達到相同的目的？這件事的界線在哪裏？ 當服務恢複以後，我們還要完成事件報告。這個報告應該詳細說明發生了什麼，我們通過哪種途徑得知了這個問題，我們采取了什麼處理方式，以及都有誰受到了影響。在那之後，在正常工作時間，與主要利益相關者召開會議，審查事件報告並為可能出現的後續狀況作出布置。這些工作可以是改進檢測和預警機制、更新說明文檔或自動化流程，抑或是開發新的工具。

我們並非在發生事故時才想起審視自己的流程和程序並做出改變。在2017年，ArenaNet決定利用AWS基礎構架（並且無需停機時間！），從現場數據中心遷移到基於雲技術的數據中心。2020年，在開始進行遠程工作後，我們也完成了分析日志傳輸系統從硬件端到雲端的遷移。

所有這些雲遷移的都是為了更好的靈活性，從而使我們可以選擇快速無縫地不斷更改和修改我們的基礎構架。在2020年初，我們啟動了一次全面的內部AWS升級，考察了我們運行的每台服務器的成本和可用選項，從開發商務服務器到實時PvP調度服務器。AWS一直在提供新的服務和新的硬件類型，但自從2017年以來，我們就沒有進行過全面的自我審查。這項計劃將使我們做出改變，以改善現場遊戲中的玩家體驗，使我們的開發環境與現場遊戲相匹配，並改進一些後端工具。我們還更新了一些自2017年遷移以來從未更改甚至重新啟動過的服務器！

在處理一個大項目時，最有效的策略之一就是把它分解成更小、更易管理的小塊……就像切一個大比薩餅一樣！我們的計劃是審查每個AWS實例，幸運的是，我們手頭已經有了一些基於不同實例類型的玩意兒：遊戲服務器、數據庫服務器、商務服務器等。我們的計劃是依次檢查每一個，進行更改，然後轉到下一組。對於每一系列更改，我們將從遷移內部開發服務器開始。我們將編寫一份運行資料來記錄流程並驗證運行情況，然後按照運行資料逐步遷移我們的過渡環境和線上環境。

對於任何產品和公司來說，迭代的能力都是至關重要的。這就像是在你家裏的後院裏造一件東西，把它砸碎，盡可能經常地、並且用各種奇怪的方式摧毀它。一旦你在發布之前修複了所有東西，當它進入公眾視野時，它將會是具有相當容錯率的。對於平台和遊戲運營團隊來說，這種“實戰研習”的過程是我們的另一個工具，對提高我們的服務質量非常有幫助。盡管如此，研發環境和在線遊戲的服務器在成本和規模上都有很大的不同，所以盡管我們希望一切都“表裏如一”，但它們仍然具有自己的特點。

我先交代一下我們的（極度言簡意賅的）數據庫背景：我們有兩個數據庫，一個主數據庫和一個副數據庫。當我們寫入數據時，一條帶有“實裝這項修改”的消息被發送到主數據庫。然後，主數據庫向副數據庫（或鏡像）發送一條帶有“實裝這項修改”的消息，然後將更改應用於自身。如果主數據庫出現了“故障”，則副數據庫將臨時作為主數據庫自動接管數據並執行報告。這意味著整個過程不會出現停機或數據丟失，新的主數據庫將在新的副數據庫從“故障”中恢複後，將數據依照順序重新備份給它。如果需要升級服務器，我們會手動斷開主數據庫和副數據庫之間的連接，升級副數據庫，然後重新連接它們。

我們可以用來追蹤的一個重要指標就是副數據庫從主數據庫接收所有數據，並回到與主數據庫一致的狀態所需的時間。結合其他負載和運行狀況指標，這可以告訴我們服務器是否正常，我個人覺得這些圖表非常有趣。然後我們交換主副數據庫，重複上面的操作，最後我們就得到了更完美的圖表，以及一個完全升級過後的環境。
在開發環境中，一切都運行順利。我們的過渡環境為我們提供了另一個服務器端到客戶端進行測試流程的機會，而且運行也很順利。隨後我們於2020年5月6日（星期三）開始對歐洲地區服務器進行在線遊戲更新。

問題出現在哪裏

5月6日，在線更新完全按照計劃進行。我們切斷了連接，升級了副數據庫，又重新建立了連接。數據複制過來以後，我們交換了主副數據庫，並再次重複這些操作。數據的拷貝比起我們在開發環境中的實際運行要慢一點，但是考慮到實時遊戲的流量，數據隊列要大得多，所以這個速度也算正常。5月7日，星期四，我們接到了一個“磁盤空間將滿”的警報。我們最近對數據進行了額外的備份，這占用了一些空間，但經驗告訴我們，無論如何都要擴展磁盤卷。擴展存儲的成本很低，如果使用AWS，只需點擊幾下鼠標，日志和備份驅動器的大小就可以增加一倍。遊戲運營團隊的一名成員點了幾下鼠標，但擴展的存儲空間並沒有神奇地出現。周五，我們向AWS提交了一份協助請求，AWS建議重啟服務器以糾正此問題。由於此服務器當前是主數據庫，因此必須先與副數據庫交換，然後才能重新啟動。

如果我們現在回頭去看，認清這樣一個明顯的錯誤是很容易的，但那時我們對這些事情一無所知。星期五下午，我們試圖交換主副數據庫，以便執行快速的重啟。然而，當時從主數據庫向副數據庫發送的數據隊列並不是空的，它仍然在緩慢地進行著備份。我們經過了簡單的計算，認為硬盤在周末並不會完全填滿，所以我們可以在周一早上返回，分析數據隊列，交換服務器，然後重新啟動。

然後等到星期一我們回來的時候……

雖然我們已經意識到了隊列的發送速度十分緩慢（想想“海龜的速度”），但我們沒有考慮到隊列增長的速度（想想“噴氣背包海龜的速度”！）。回想一下之前提到的數據庫狀況，如果主數據庫發生了“故障”，則次數據庫將自動接管作為新的主數據庫。而數據隊列變得太大正是導致數據庫自動轉移的“故障”之一。

5月11日，星期一，淩晨2:41，主副數據庫進行了交換。由於實時更新的數據都在另一台服務器上的隊列中，當數據庫因故障交換時，突然間，玩家們經歷了時間旅行（這並不是好消息），因為他們從周五晚上開始的所有進度都被抹去了。三個小時後，淩晨5點40分，因為大量的玩家報告，我們的遊戲運營團隊接到了電話。早上6點有人打電話給我，到9點，遊戲就停服更新了。

遊戲剛一停服，我們做的第一件事就是重新啟動主服務器。正如預測的那樣，磁盤卷成功擴展了！這是個好消息，如果沒有別的事情發生的話。在新擴展的磁盤上，我們找到了最新的自動備份文件和包含所有數據隊列的日志，截止到淩晨2:41。

保存備份是一種很好的做法。存儲成本低廉，數據可以恢複，這使得開發人員可以安下心來，而且安排自動備份非常便捷。本來直接使用備份數據就萬事大吉，但事情似乎並不像想象的那樣，主要還是因為我們並不經常這樣做。一方面，當時數據庫沒有負載，所以如果需要的話我們完全可以直接清空，從頭運行。另一方面，遊戲已經停擺，我們感到巨大的壓力，需要快速准確地恢複數據，讓遊戲再次開放。

（旁注：我盡量只說故事的主線，但即便如此，我們圍繞著這次故障所進行的其它分析研究仍然不能忽略，例如交易所、寶石商城、注冊新賬戶等等。在這次事件中發生了很多事情，有許多不同團隊的意見。我甚至覺得我可以寫一整本關於這件事的小故事書！）

老實說，恢複過程相當無聊，我們只是遵循著使用指南進行了操作。在管理程序中單擊幾個按鈕，服務器就開始運行了。在開始之前，我們必須將備份文件和日志文件複制到第二台服務器，以確保在這兩台服務器上恢複相同的數據。然後服務器將數據庫的狀態設置為備份文件中包含的所有內容。這個過程花了幾個小時。然後它將應用所有記錄的數據，這樣最終兩個數據庫將回檔到淩晨2:41，這也需要很長時間。第一台服務器在淩晨1:37結束，第二台在淩晨4:30結束。

（旁注2：除了你的實際工作，與你一起工作的人可能是選擇公司或團隊最重要的因素。我們中有一小部分人，從早上5:30或6:00開始在線，只睡午覺，然後一直工作到第二天淩晨。說是服務器的保姆也不為過！我們團隊中每個人都有能力認真對待局勢，同時管理好自己，並有一點娛樂精神，這讓我們平安度過了這一事件，這一點絕不能忽視。這個團隊無論在決策還是執行上都做得非常出色。）

激戰2的基礎構架相當驚人。它能夠在不停機的情況下進行更新，並且包含許多調節工具，可以影響遊戲中的不同功能或內容，以防止漏洞攻擊、崩潰，甚至可以在不需要測試版本的情況下改變動態事件的難度！就比如在5月12日，我們利用了遊戲中自2016年以來從未有過的另一項功能，即無需登錄即可上線。遊戲將完全在線上運行，當然，這只允許開發者參與，不允許玩家參與。

淩晨4點55分，我們“打開”了遊戲，一大批內部開發者、測試工程師和少數歐服合作夥伴登錄了遊戲。讓我印象深刻的是，幾分鐘內，部分玩家們就已經發現遊戲正在進行測試，他們的進度回檔到了周一上午。我想當我們提供程序接口的時候就會發生這種情況！

在對實時環境進行冒煙測試（檢查了數據庫運行狀況和消息隊列）之後，我們在早上5:37向公眾開放了服務器，時間是在關停後的20多個小時。團隊中的每個人都很榮幸，能夠幫助每個人回到他們熱愛的世界，包括我自己。我也很高興又睡了幾個小時。

休息了幾個小時後，我們都重新登錄工作，試圖了解故障的根本原因到底是什麼。當天下午，歐服又觸發了一個警報：數據庫數據隊列容量過高。

又操蛋了。

我們已經正確地識別了這些新發現的故障點，並為它們添加了一些警報機制。在接下來的兩天裏，我們手動管理了數據庫鏡像機制以及主副數據庫之間的連接；與AWS的數據庫管理員、網絡運營商和技術客戶經理都進行了溝通；配置了與消息隊列、磁盤空間、存儲和日志相關的所有設置。經過幾天的閱讀文檔，從專家那裏收集知識，嘗試改變，我們終於在周五取得了突破。

奈斯！

最根本原因，實際上是驅動器。

驅動程序是一種允許軟件操作系統與連接的設備進行通信的玩意，如果你有遊戲鼠標或繪圖板之類的外圍設備，你可能已經下載了特定的驅動程序。在這次事件中，服務器的操作系統沒有最新的通信方法與硬盤連接。在這樣一個數據庫中，讀寫數據到磁盤是它存在的全部原因的99%。（另外1%是“哇”的因素。“哇，你有數據庫嗎？酷。”）

當我們升級服務器時，我們正從AWS的第4代服務器升級到第5代服務器，隨之而來的是服務器與連接設備的交互方式的不同（我不完全理解系統是如何工作的，但AWS對底層技術有一個很酷的名字：Nitro！）。我們的驅動程序版本領先於AWS提供的基本版本，所以我們不希望需要額外的更新。另外，在我們的開發環境中，這種問題根本沒有出現！但我們也沒有任何地方接近負載，因為我們的遊戲始終處於在線運行狀態。盡管又是一個星期五，但意識到驅動程序更新失敗的後果，我們還是決定繼續前進。

和以前一樣，我們切斷了數據庫之間的連接，運行驅動程序更新，然後重新連接。

隊列瞬間被清空。

數據寫入速度為100000kbps，遠遠高於我們之前看到的700kbps。

我笑了。笑出聲來了（甚至有點失控）。

我們在另一台服務器上重複了這個過程。又一次，隊列瞬間被清空。

那個周末我睡得很安詳。從那以後，我度過了許多美好的星期一早晨。

總結與展望

所以，這就是實際的情況，我們犯下的失誤，以及一切的原因。接下來這部分則詮釋了我為什麼熱愛這份工作：我們學到了什麼教訓？我們是如何利用它來成長和提高的？一路上我們交到了哪些朋友？

好吧，首先，這件事狠狠地提醒了我們，開發環境和在線環境的區別究竟有多麼大。開發環境非常適合於練習、記錄特定的性能指標等。但是，對於某些更新的實裝，我們仍然需要在跨多台機器的環境下應用負載測試和壓力測試等關鍵工具。

第二，這提醒了我們永遠要驗證假設，並退一步，看看整體的大局形勢是否有不符合預期的表現。我們按照我們的職責在停服之前進行了調查，但我們搞錯了重點。與其他人溝通將給我們提供一個不同的視角，防範我們偵測到的異常現象，以確保它不會變成更大的問題。

對於我們的數據庫而言，最大的變化是增加了對關鍵數據庫指標的預警機制，而不僅僅是對CPU或硬盤空間等系統指標進行預警。對於我們的在線操作，我們在第三方工具中添加了許多預警系統，以縮短我們對問題的響應時間。而對於一般操作，我們改進了AWS基礎設施的記錄保存模式，現在跟蹤的不僅僅是某個實例。我們的報告現在包括實例類型、生成、驅動程序和存儲類型。我們構建了一個通用包，安裝在所有新服務器上，其中包括特定的驅動程序版本。任何未來的遷移計劃都會更新這個通用包，確保不再重複這個問題。

我們已經完成了所有剩餘數據庫實例和一些其他實例的遷移，為提高服務提供了更好的性能。在過去的14個月中，我們記錄了99.98%的正常運行時間，只有5次輕微的服務中斷影響了用戶登錄。

我們不斷努力的目標始終是為您提供我們服務的最佳體驗和可用性。我們感激在我們之前的人所設計的架構，以及我們用來保持世界級運行效率的工具和流程。很高興地告訴大家，我們的連續正常運行時間已經達到了一年的里程碑。我們認識到，我們可能無法做到完美，但我們一定會在今後的每一項工作和任務中努力奮鬥。當我們期待激戰2研發和設計團隊為您帶來的令人興奮的新功能和項目時，我們一直在幕後工作，以確保您可以隨時登錄並享受。

哇，我知道我能寫很多代碼；但現在我才意識到原來我也可以寫一篇很長的博客文章，真心希望你能夠喜歡它。對一些人來說，這篇文章可能需要很長時間才能完成，但我真的很高興能和大家分享這樣的故事。我們很樂意閱讀您對這類帖子的想法和反饋，所以我們在官方論壇上開了一個討論帖，歡迎大家暢所欲言！

我們泰瑞亞見！

Robert