Roblox 服務恢復

自 10 月 28 日起，Roblox 經歷了一場長達 73 小時的服務中斷，並於 10 月 31 日完全恢復正常。¹ 每天有 5,000 萬名玩家定期使用 Roblox，為了打造玩家所期待的體驗，我們的系統規模涉及數百項內部線上服務。如同任何大型服務一樣，我們偶爾會發生服務中斷，但此次中斷時間過長，因此格外值得關注。 我們對此次服務中斷向社群致上誠摯的歉意。

我們分享這些技術細節，是為了讓社群了解問題的根本原因、我們如何處理，以及我們正在採取哪些措施來防止未來發生類似問題。我們想再次強調，在此次事件期間，並未發生任何用戶資料遺失，亦無任何資訊遭未經授權者存取。

Roblox 工程團隊與 HashiCorp 的技術人員通力合作，使 Roblox 恢復服務。我們要特別感謝 HashiCorp 團隊，他們投入了驚人的資源，並與我們不懈合作直至問題解決。

服務中斷摘要

此次服務中斷無論在持續時間或複雜程度方面都極為罕見。團隊必須依序解決多項挑戰，才能釐清根本原因並恢復服務。

• 此次服務中斷持續了 73 小時。
• 根本原因源於兩項問題。在 Consul 啟用一項相對較新的串流功能時，因面臨異常高的讀寫負載，導致過度競爭與效能不佳。此外，我們的特定負載條件觸發了 BoltDB 中的病態效能問題。Consul 內部使用開源的 BoltDB 系統來管理用於領導者選舉和資料複製的預寫日誌。 
• 單一 Consul 叢集同時支援多項工作負載，進一步加劇了這些問題的影響。
• 診斷這些深埋於 Consul 實作中、且原本互不相關的兩項問題所面臨的挑戰，是導致停機時間延長的主要原因。 
• 本應能提供更清晰停機原因檢視的關鍵監控系統，卻依賴於受影響的系統（例如 Consul）。這種組合嚴重阻礙了故障分類流程。
• 我們在將 Roblox 從長時間完全停機的狀態恢復時，採取了深思熟慮且謹慎的策略，這也耗費了相當長的時間。
• 我們已加快工程進度，以改善監控、移除可觀察性堆疊中的循環依賴關係，並加速我們的初始化流程。 
• 我們正致力於遷移至多個可用區域和資料中心。
• 我們正在修復 Consul 中導致此次事件的根本原因。

前言：我們的叢集環境與 HashiStack

Roblox 的核心基礎架構運行於 Roblox 資料中心內。我們自行部署並管理硬體設備，並在此硬體基礎上建置專屬的運算、儲存及網路系統。我們的部署規模龐大，擁有超過 18,000 台伺服器與 170,000 個容器。

為了在多個據點運行數千台伺服器，我們採用了一套通稱為「HashiStack」的技術套件。Nomad、Consul 和 Vault 是我們用來管理全球伺服器與服務的技術，並讓我們能夠協調支援 Roblox 服務的容器。

Nomad 用於工作調度。它決定哪些容器將在哪些節點上運行，以及它們可透過哪些埠號存取。它同時也驗證容器的運作狀態。所有這些資料都會傳遞至服務註冊表（Service Registry），這是一個儲存 IP:Port 組合的資料庫。Roblox 服務透過服務註冊表相互定位，以便進行通訊。這個過程稱為「服務發現」。 我們使用 Consul 進行服務發現、健康檢查、會話鎖定（用於其上建構的高可用性系統），並作為鍵值儲存庫。

Consul 以機器叢集的形式部署，並分為兩種角色。「投票者」（5 台機器）權威性地維護叢集的狀態；「非投票者」（另外 5 台機器）則是唯讀複本，用於協助擴展讀取請求。在任何時刻，叢集都會選出其中一位投票者作為領導者。領導者負責將資料複製給其他投票者，並判定寫入的資料是否已完全提交。  Consul 採用名為 Raft 的演算法進行領導者選舉，並以此方式在叢集中分發狀態，確保叢集中的每個節點都能就更新達成共識。領導者在一天內透過領導者選舉更換數次的情況並不少見。

以下是事件發生後，Roblox 系統中 Consul 儀表板的近期截圖。本篇部落格文章中提及的許多關鍵營運指標均顯示在正常水平。例如，KV 套用時間若低於 300 毫秒即被視為正常，而此時該數值為 30.6 毫秒。Consul 領導者在過去 32 毫秒內曾與叢集中的其他伺服器建立聯繫，這顯示聯繫非常近期。

在 10 月事件發生前的數個月間，Roblox 將 Consul 從 1.9 版本升級至 1.10 版本，以利用其新增的串流功能。此串流功能旨在大幅降低在 Roblox 這種大型叢集環境中分發更新所需的 CPU 資源與網路頻寬。

初步偵測 (10/28 13:37)

10月28日下午，Vault 效能出現下降，且有一台 Consul 伺服器 CPU 負載過高。Roblox 工程師隨即展開調查。此時玩家尚未受到影響。

初期分流 (10/28 13:37 – 10/29 02:00)

初步調查顯示，Vault 及許多其他服務所依賴的 Consul 叢集狀態異常。  具體而言，Consul 叢集的監控指標顯示，其底層的 KV 儲存庫（Consul 用於儲存資料的儲存庫）寫入延遲顯著升高。此類操作的第 50 百分位延遲通常低於 300 毫秒，但此時已達 2 秒。以 Roblox 的規模而言，硬體問題並不罕見，且 Consul 具備承受硬體故障的能力。然而，若硬體僅是運作緩慢而非完全故障，仍可能影響 Consul 的整體效能。 在此情況下，團隊懷疑硬體效能下降是根本原因，並開始更換其中一個 Consul 叢集節點。這是我們對該事件的首次診斷嘗試。大約在同一時間，HashiCorp 的員工加入 Roblox 工程師的行列，協助進行診斷與修復。從此處開始，所有提及「團隊」和「工程團隊」之處，均指 Roblox 與 HashiCorp 的員工。

即使更換了新硬體，Consul 叢集的效能仍持續受影響。在 16:35 時，線上玩家數量驟降至平時的 50%。

此次故障發生時，系統健康狀態已顯著惡化，最終導致系統完全中斷。原因為何？當 Roblox 某項服務需要與其他服務通訊時，會仰賴 Consul 來獲取目標服務位置的最新資訊。 然而，若 Consul 狀態異常，伺服器便難以建立連線。此外，Nomad 和 Vault 皆依賴 Consul，因此當 Consul 狀態異常時，系統便無法調度新容器，也無法取得用於驗證的生產環境機密。簡而言之，系統故障的原因在於 Consul 成為單點故障，且 Consul 當時狀態異常。

此時，團隊針對問題成因提出了一項新假說：流量激增。或許是因為系統達到臨界點，導致 Consul 運行緩慢，而託管 Consul 的伺服器已無法負荷這份負載？這是我們第二次嘗試診斷事件的根本原因。

鑑於事件的嚴重性，團隊決定將 Consul 叢集中的所有節點更換為性能更強的新機器。這些新機器擁有 128 個核心（性能提升 2 倍），並配備了更新、更快的 NVMe SSD 硬碟。截至 19:00，團隊已將叢集的大部分遷移至新機器，但叢集狀態仍未恢復正常。 叢集回報顯示，多數節點無法跟上寫入需求，且 KV 寫入的第 50 百分位延遲仍維持在約 2 秒，而非通常的 300 毫秒或更短。

恢復服務嘗試 #1（10/29 02:00 – 04:00）

前兩次嘗試將 Consul 叢集恢復至正常狀態均未成功。我們不僅仍觀察到 KV 寫入延遲偏高，還出現了一種無法解釋的新症狀：Consul 領導節點會定期與其他投票節點失去同步。 

團隊決定關閉整個 Consul 叢集，並使用數小時前（即故障發生之初）的快照來重置其狀態。我們明白此舉可能會導致少量系統配置資料的損失（非使用者資料）。鑑於此次故障的嚴重性，加上我們有信心在必要時能手動恢復這些系統配置資料，因此認為這是可接受的。 

我們預期從系統正常運作時的快照還原，應能使叢集恢復正常狀態，但仍有另一項顧慮。儘管此時 Roblox 系統中並無任何用戶產生的流量，但 Roblox 內部服務仍處於運行狀態，並持續向 Consul 查詢其依賴項的位置以及更新健康狀態資訊。這些讀寫操作為叢集帶來了顯著的負載。 我們擔心，即使叢集重置成功，這份負載仍可能立即將叢集推回不健康狀態。為解決此疑慮，我們在叢集上配置了 iptables 來封鎖存取。此舉能讓我們以受控方式重新啟動叢集，並協助我們釐清：在排除用戶流量的情況下，我們施加在 Consul 上的負載是否為問題的一部分。

重置過程順利，初期指標看起來也相當理想。當我們移除 iptables 封鎖後，來自內部服務的服務發現與健康檢查負載如預期般恢復。然而，Consul 的效能開始再度惡化，最終我們又回到了原點：KV 寫入操作的第 50 百分位數延遲再次回到 2 秒。 依賴 Consul 的服務開始將自身標記為「不健康」，最終系統又回到了如今已相當熟悉的異常狀態。此時已是凌晨 04:00。顯然我們對 Consul 的負載存在某種問題，但在事件發生超過 14 小時後，我們仍未能找出問題根源。

恢復服務嘗試 #2 (10/29 04:00 – 10/30 02:00)

我們已排除硬體故障的可能性。升級硬體不僅無助於改善狀況，事後更發現可能反而損害了系統穩定性。重置 Consul 的內部狀態同樣無濟於事。 此時並無用戶流量湧入，但 Consul 仍運行緩慢。我們曾利用 iptables 逐步讓流量重新進入叢集。難道叢集只是因為數千個容器試圖重新連線的龐大流量，而再次被推回不健康的狀態嗎？這是我們第三次嘗試診斷事件的根本原因。

工程團隊決定先減少 Consul 的使用量，再謹慎且有系統地逐步重新啟用它。為了確保有個乾淨的起點，我們也封鎖了剩餘的外部流量。 我們彙整了一份使用 Consul 的服務完整清單，並推送配置變更以停用所有非必要的使用。由於涉及的系統種類繁多且配置變更類型各異，此過程耗時數小時。通常運行數百個實例的 Roblox 服務，現已縮減至個位數。健康檢查頻率從 60 秒降低至 10 分鐘，以給予叢集更多緩衝空間。 在服務中斷開始超過 24 小時後的 10 月 29 日 16:00，團隊展開第二次嘗試，試圖讓 Roblox 恢復線上運作。這次重啟嘗試的初期階段看似順利，但到了 10 月 30 日 02:00，Consul 再次陷入不健康狀態，而這次來自依賴它的 Roblox 服務的負載已大幅降低。

至此，顯而易見的是，整體 Consul 使用量並非我們於 28 日首次察覺的效能下降唯一肇因。基於此認知，團隊再次調整策略。不再從依賴 Consul 的 Roblox 服務角度審視，而是開始深入 Consul 內部機制尋找線索。

競用現象的調查（10/30 02:00 – 10/30 12:00）

在接下來的 10 小時內，工程團隊深入分析了除錯日誌與作業系統層級的指標。這些數據顯示，Consul 的 KV 寫入操作會被長時間阻塞，也就是所謂的「競態」。雖然競態的成因並非立即可知，但有一種假設認為，在故障初期將伺服器從 64 核心切換至 128 核心，可能加劇了問題。 在檢視下方截圖所示的 htop 數據與效能除錯資料後，團隊認為值得回歸至與故障前相似的 64 核心伺服器。團隊隨即開始準備硬體：安裝 Consul、三遍確認作業系統設定，並以最細緻的方式將機器備妥以投入服務。 隨後，團隊將 Consul 叢集重新遷移回 64 核心伺服器，但此變更並未改善狀況。這是我們第四次嘗試診斷該事件的根本原因。

已查明根本原因 (10/30 12:00 – 10/30 20:00)

數月前，我們在部分服務上啟用了 Consul 的新串流功能。此功能旨在降低 Consul 叢集的 CPU 使用率與網路頻寬，運作效果符合預期，因此在接下來的幾個月裡，我們逐步將此功能擴展至更多後端服務。在服務中斷的前一天，即 10 月 27 日 14:00，我們在負責流量路由的後端服務上啟用了此功能。 作為此次部署的一部分，為了因應年底通常會增加的流量，我們也將負責流量路由的節點數量增加了 50%。在事件發生前的一天，系統在這個層級的串流運作良好，因此起初並不清楚為何效能會發生變化。 然而，透過分析 Consul 伺服器的效能報告與火焰圖，我們發現證據顯示，正是串流處理的程式路徑導致了競態衝突，進而造成 CPU 使用率飆升。我們隨即停用了所有 Consul 系統（包含流量路由節點）的串流功能。配置變更於 15:51 完成傳播，此時 Consul 鍵值寫入的第 50 百分位數降至 300 毫秒。我們終於迎來了突破。

為何串流會成為問題？HashiCorp 解釋道，雖然串流整體上更有效率，但其實作中使用的並發控制元件（Go 通道）比長輪詢（long polling）更少。在極高負載下——具體而言，即讀取負載與寫入負載同時極高時——串流的設計會加劇單一 Go 通道上的競用程度，導致寫入時發生阻塞，使其效率大幅降低。 這種行為也解釋了高核心數伺服器所產生的影響：那些伺服器採用雙插槽架構，並具備 NUMA 記憶體模型。因此，在這種架構下，共享資源的額外爭用情況變得更加嚴重。透過關閉串流功能，我們顯著改善了 Consul 叢集的運作狀態。

儘管取得了突破，我們仍未完全脫離險境。我們觀察到 Consul 會間歇性地選出新的叢集領導者，這雖屬正常現象，但同時也發現部分領導者出現了與停用串流功能前相同的延遲問題，這便不正常了。 由於缺乏指向「遲鈍領導者」問題根本原因的明顯線索，且有證據顯示只要特定伺服器未當選為領導者，叢集便能維持健康狀態，團隊遂做出務實的決策：透過防止問題領導者持續當選來繞過此問題。這使團隊得以專注於將依賴 Consul 的 Roblox 服務恢復至健康狀態。

但這些遲鈍的領導者究竟發生了什麼事？我們在事件發生期間並未釐清箇中原因，但 HashiCorp 的工程師在停機事件後的數天內，成功釐清了根本原因。 Consul 使用名為 BoltDB 的熱門開源持久化函式庫來儲存 Raft 日誌。它並非用於儲存 Consul 內的當前狀態，而是用於儲存正在執行的操作之滾動日誌。為防止 BoltDB 無限增長，Consul 會定期執行快照。快照操作會將 Consul 的當前狀態寫入磁碟，然後從 BoltDB 中刪除最舊的日誌條目。 

然而，由於 BoltDB 的設計特性，即使刪除了最舊的日誌條目，BoltDB 在磁碟上佔用的空間也不會縮小。相反地，所有曾用於儲存已刪除資料的頁面（檔案內的 4KB 區段）會被標記為「可用」，並重新用於後續的寫入作業。 BoltDB 透過稱為「空閒清單」（freelist）的結構來追蹤這些空閒頁面。通常，更新空閒清單所需的時間並不會對寫入延遲造成顯著影響，但 Roblox 的工作負載卻揭露了 BoltDB 中一個病態的效能問題，導致空閒清單的維護成本極高。 

恢復快取服務（10/30 20:00 – 10/31 05:00）

自服務中斷開始已過去 54 小時。隨著串流功能停用，並實施了防止遲滯領導節點持續當選的機制，Consul 現已保持穩定運行。團隊已準備好專注於恢復服務。

Roblox 的後端採用典型的微服務架構。 在微服務「堆疊」的最底層是資料庫和快取。這些資料庫雖未受停機影響，但快取系統卻處於異常狀態——該系統在正常運作時，其多層架構每秒需處理 10 億次請求。由於我們的快取儲存的是可從底層資料庫輕鬆重新載入的暫存資料，因此將快取系統恢復至正常狀態最簡單的方法就是重新部署。

快取重新部署過程遭遇了一系列問題： 

1. 很可能是由於先前執行的 Consul 叢集快照重置，導致快取系統儲存於 Consul KV 中的內部排程資料出現錯誤。 
2. 小型快取的部署時間比預期更長，而大型快取的部署則無法完成。經查，有個狀態異常的節點被工作排程器視為完全正常（而非異常）。這導致工作排程器試圖在該節點上大量排程快取工作，但因節點狀態異常而失敗。 
3. 該快取系統的自動化部署工具，原本是為了支援對已處理大規模流量的部署進行增量調整而建構，而非用於從頭開始反覆嘗試初始化大型叢集。 

團隊徹夜工作以識別並解決這些問題，確保快取系統正確部署，並驗證其正確性。在 10 月 31 日 05:00，即服務中斷開始後的 61 小時，我們已擁有一個運作正常的 Consul 叢集和一個運作正常的快取系統。我們已準備好啟動 Roblox 的其餘部分。

玩家回歸（10/31 05:00 – 10/31 16:00）

最終的服務恢復階段於 31 日 05:00 正式開始。與快取系統類似，在最初的服務中斷或故障排除階段，有相當一部分的運行服務已被關閉。團隊需要以正確的容量水準重新啟動這些服務，並驗證其運作是否正常。此過程進行得相當順利，到了 10:00，我們已準備好向玩家開放服務。

鑑於快取狀態已清空，且系統運作狀況仍存有變數，我們不希望湧入過量流量，以免導致系統再度陷入不穩定狀態。為避免流量洪峰，我們採用 DNS 導向機制來管控能存取 Roblox 的玩家數量。此舉讓我們得以讓一定比例的隨機選取玩家進入，同時將其餘玩家持續導向靜態維護頁面。 每次提高開放比例時，我們都會檢查資料庫負載、快取效能以及整體系統穩定性。工作持續了一整天，我們以大約 10% 的增量逐步放寬存取限制。 我們很高興看到部分最忠實的玩家破解了我們的 DNS 導向機制，並開始在 Twitter 上分享這項資訊，以便在我們恢復服務時能獲得「提前」存取權限。週日 16:45，即服務中斷開始後的 73 小時，100% 的玩家已恢復存取權限，Roblox 也全面恢復運作。

停機事件後的進一步分析與調整

雖然玩家已於 10 月 31 日獲准重返 Roblox，但 Roblox 與 HashiCorp 在隨後的一週內持續深入釐清此次中斷的成因。 團隊已識別並隔離了新串流協定中的特定競用問題。雖然 HashiCorp 曾針對與 Roblox 使用量相近的規模進行過串流效能測試，但由於此特定行為源於大量串流與高流失率的雙重影響，先前並未觀察到此現象。 HashiCorp 工程團隊正建立新的實驗室基準測試，以重現該特定競用問題，並進行額外的規模測試。HashiCorp 同時致力於改進串流系統的設計，以避免在極端負載下發生競用，並確保在此類條件下維持穩定效能。 

對「緩慢領導者」問題的進一步分析，亦揭示了 Raft 資料寫入耗時兩秒及叢集一致性問題的關鍵成因。工程師們透過分析如下所示的火焰圖，以更深入理解 BoltDB 的內部運作機制。

前述指令的輸出結果告訴我們幾件事：

• 這個 4.2GB 的日誌儲存空間中，實際僅儲存了 489MB 的資料（包含所有索引內部資料）。其餘 3.8GB 屬於「空閒」空間。
• 自由清單（freelist）佔用 7.8MB，因為其中包含近百萬個空閒頁面 ID。

這意味著，每次日誌追加（每次 Raft 寫入後經過批次處理），即使實際追加的原始資料僅有 16KB 或更少，系統仍會將一個新的 7.8MB 空閒清單寫入磁碟。 

這些操作產生的回壓也導致 TCP 緩衝區滿載，進而造成不健康的領導節點寫入時間長達 2-3 秒。下圖顯示了事件期間針對 TCP Zero Windows 的研究。

HashiCorp 與 Roblox 已開發並部署了一套流程，利用現有的 BoltDB 工具來「壓縮」資料庫，從而解決了效能問題。

近期改進與未來規劃

自服務中斷以來已過了 2.5 個月。這段時間我們做了些什麼？ 我們利用這段時間盡可能從此次服務中斷事件中汲取教訓，根據所學調整工程優先順序，並積極強化系統安全性。Roblox 的核心價值之一是「尊重社群」，雖然我們本可以更早發布文章說明事件經過，但我們認為有責任在發布前，先在提升系統可靠性方面取得顯著進展，以此回報各位社群成員。 

已完成及正在進行中的可靠性改進項目清單過於冗長且細節繁多，無法在此篇貼文中完整列出，但以下是關鍵項目：

遙測系統優化

我們的遙測系統與 Consul 之間存在循環依賴關係，這意味著當 Consul 狀態異常時，我們便無法取得有助於釐清問題根源的遙測數據。我們已移除此循環依賴關係，使遙測系統不再依賴其設定監控的對象。

我們已擴展遙測系統，以提供更清晰的 Consul 和 BoltDB 效能監控視圖。如今，若系統出現任何接近此次中斷成因狀態的徵兆，我們便會收到高度精準的警示。此外，我們也擴展了遙測系統，以更深入地掌握 Roblox 服務與 Consul 之間的流量模式。這項對系統行為與效能的多層級額外可視性，已在系統升級與除錯過程中為我們提供了實質協助。

擴展至多個可用區域與資料中心

將所有 Roblox 後端服務運行於單一 Consul 叢集，使我們容易遭受此類中斷的影響。我們已建置好伺服器與網路基礎架構，用於支援另一個地理位置上相互獨立的資料中心，該資料中心將託管我們的後端服務。我們正致力於將服務遷移至這些資料中心內的多個可用區域；為加速此項工作，我們已對工程路線圖及人力配置計畫進行重大調整。

Consul 升級與分片

Roblox 仍在快速成長，因此即使擁有多個 Consul 叢集，我們仍希望降低對 Consul 的負載。我們已檢視服務如何使用 Consul 的 KV 儲存庫與健康檢查機制，並將部分關鍵服務拆分至專屬叢集，將中央 Consul 叢集的負載降低至更安全的水平。

儘管我們擁有其他可能更合適的儲存系統，但部分 Roblox 核心服務仍直接將 Consul 的 KV 儲存庫作為便捷的資料儲存位置。我們正將這些資料遷移至更合適的儲存系統。一旦完成，這也將減輕 Consul 的負載。

我們發現了大量過時的 KV 資料。刪除這些過時資料後，Consul 的效能有所提升。

我們正與 HashiCorp 密切合作，部署新版 Consul 以取代 BoltDB，改用名為 bbolt 的後繼版本，該版本不會出現自由清單無限制增長的問題。我們刻意將此工作延至新年後進行，以避免在年底流量高峰期間進行複雜的升級作業。目前升級作業正在測試中，預計將於第一季完成。

啟動程序與配置管理的改進

服務恢復進度因多項因素而延遲，包括 Roblox 服務所需快取的部署與預熱。我們正在開發新工具與流程，以使此過程更自動化且減少出錯機率。特別是，我們已重新設計快取部署機制，確保能在完全停機狀態下快速啟動快取系統。相關實作目前正在進行中。

我們與 HashiCorp 合作，識別出數項 Nomad 增強功能，這些功能將使我們在長時間停機後更容易啟動大型工作。這些增強功能將作為我們下一次 Nomad 升級的一部分進行部署，預計於本月下旬實施。

我們已開發並部署了機制，以加速機器配置變更。

重新導入串流技術

我們最初部署串流功能，是為了降低 Consul 叢集的 CPU 使用率與網路頻寬。一旦新實作方案在我們的規模下，針對我們的負載完成測試，我們預計將謹慎地將其重新引入我們的系統中。

關於公有雲的說明

在經歷此類服務中斷事件後，自然會有人詢問 Roblox 是否會考慮遷移至公有雲，並讓第三方管理我們的基礎運算、儲存及網路服務。

Roblox 的另一項核心價值觀是「放眼長遠」，這項價值觀深刻影響著我們的決策。我們在本地環境中自行建置並管理基礎架構，是因為在當前的規模下——更重要的是，在我們預見平台未來將達到的規模下——我們相信這是支援業務與社群的最佳方式。 具體而言，透過自行建置並管理用於後端及網路邊緣服務的資料中心，相較於公有雲，我們得以顯著控制成本。這些節省下來的資金，直接影響我們能支付給平台創作者的報酬金額。此外，擁有自有硬體並建置專屬的邊緣基礎設施，讓我們能將效能波動降至最低，並精準管控全球玩家的延遲狀況。 對於未必位於公有雲供應商資料中心附近的玩家而言，穩定的效能與低延遲是遊戲體驗的關鍵。

請注意，我們並非抱持任何特定理念而固守某種做法：對於對玩家和開發者而言最合理的應用場景，我們仍會採用公有雲。例如，我們會將公有雲用於突發性容量需求、大部分的 DevOps 工作流程，以及多數的內部分析任務。 總體而言，我們認為公有雲是適用於非性能與延遲關鍵型、且運行規模有限的應用程式的良好工具。然而，針對我們最重視性能與延遲的工作負載，我們選擇在本地架設並管理自己的基礎設施。我們明知此舉需要投入時間、金錢與人才，但同時也深知這將使我們能夠打造更優質的平台。這與我們的「長遠視野」核心價值觀一脈相承。

停機事件後的系統穩定性

Roblox 通常會在 12 月底迎來流量高峰。雖然我們仍有許多可靠性工作待完成，但很高興能報告：在 12 月的流量高峰期間，Roblox 未發生任何重大生產環境事故，且 Consul 與 Nomad 在此期間的效能與穩定性皆表現優異。看來我們近期實施的可靠性改善措施已初見成效，隨著長期專案陸續完成，我們預期將獲得更佳的成果。

結語

我們要感謝全球 Roblox 社群的理解與支持。承擔責任是 Roblox 的核心價值之一，我們對此次事件承擔全部責任。 我們要再次向 HashiCorp 團隊致上最誠摯的謝意。在這場前所未有的服務中斷事件發生之初，他們的工程師便立即伸出援手，並始終與我們並肩作戰。即使事隔兩個月，Roblox 與 HashiCorp 的工程師仍持續緊密合作，確保我們共同竭盡所能，防止類似中斷事件再次發生。

最後，我們要感謝 Roblox 的同事們，再次印證了為何這裡是如此棒的工作場所。在 Roblox，我們信奉文明與尊重。當一切順利時，保持文明與尊重並不難，但真正的考驗在於，當事情變得艱難時，我們如何對待彼此。 在長達 73 小時的服務中斷期間，隨著時間流逝、壓力累積，若有人失去冷靜、說出不敬之言，或當眾質疑誰該為此負責，其實並不令人意外。但實際情況並非如此。 我們相互扶持，全天候齊心協力，直到服務恢復正常。當然，我們並不為這次服務中斷及其對社群造成的影響感到自豪，但我們為團隊齊心協力讓 Roblox 重獲新生，以及在整個過程中始終以文明與尊重相待的態度感到自豪。

我們從這次經歷中獲益良多，並比以往任何時候都更加致力於讓 Roblox 成為一個更強大、更可靠的平台。

再次感謝大家。