實現大規模平台的可靠性

營運任何可擴展的分散式平台，都必須致力於可靠性，以確保客戶在需要時能獲得所需服務。 依賴關係可能相當複雜，特別是像 Roblox 這樣規模龐大的平台。建立可靠服務意味著，無論依賴關係的複雜程度與狀態如何，任何特定服務都不會中斷（即高可用性），運作時無漏洞（即高品質），且不會發生錯誤（即容錯性）。

為何可靠性至關重要

我們的帳戶識別團隊致力於提升可靠性，因為我們建置的合規服務是平台的核心組件。合規性的失效可能造成嚴重後果。阻礙 Roblox 正常運作的代價極高，不僅需要額外資源來進行故障恢復，更會削弱使用者體驗。

傳統的可靠性方法主要聚焦於可用性，但在某些情況下，相關術語常被混淆或誤用。多數可用性指標僅評估服務是否處於運行狀態，而分區容錯與一致性等面向則時常被忽略或誤解。 

根據 CAP 定理，任何分散式系統僅能同時滿足這三個面向中的兩個，因此我們的合規服務為了實現高可用性與分區容錯能力，犧牲了一部分一致性。儘管如此，我們的服務實際犧牲甚微，並透過下文所述的合理架構調整，找到了實現良好一致性的機制。

提升可靠性的過程是迭代式的，透過嚴密的指標監控配合持續性工作，以在事件發生前預防、發現、偵測並修復缺陷。我們的團隊發現以下實踐具有顯著價值：

• 正確的衡量標準 — 建立全面的可觀察性，以掌握品質如何交付給客戶，以及依賴項如何為我們提供品質。
• 主動預判 — 執行架構審查與依賴項風險評估等活動。
• 優先修正 — 對與我們服務相關的服務及依賴項，在事件報告的解決上給予更高關注。

建立更高的可靠性需要一種品質文化。我們的團隊早已投入績效導向的開發，並深知流程的成功取決於其採納程度。團隊全面採納此流程，並將這些實踐作為標準來應用。下圖突顯了該流程的組成部分：

正確衡量的力量

在深入探討指標之前，有個關於服務水準（SLO）的測量概念需要先做個簡要說明。

• SLO（服務水準目標）是我們團隊所追求的可靠性目標（例如 99.999%）。
• SLI（服務水準指標）是指在特定時間範圍內達成的可靠性（例如：去年二月的 99.975%）。
• SLA（服務水準協議）是指在特定時間範圍內，我們承諾提供且用戶所期待的可靠性（例如：每週 99.99%）。

SLI 應反映可用性（無未處理或遺漏的回應）、容錯能力（無服務錯誤）以及達成的品質（無意外錯誤）。因此，我們將 SLI 定義為成功回應數相對於發送至服務的總請求數之「成功率」。所謂成功回應，是指那些在時間與形式上皆正確發送的請求，意即未發生連線、服務或意外錯誤。

此 SLI 或成功率是從使用者（即客戶端）的角度收集而來。其目的是衡量實際提供給使用者的端到端體驗，以便我們確信服務水準協議（SLA）已獲得滿足。若未如此執行，將產生一種虛假的可靠性感，而忽略了與客戶端連接時所有基礎架構方面的考量。與使用者 SLI 類似，我們亦收集依賴項 SLI 以追蹤任何潛在風險。 實際上，所有依賴性 SLA 應與服務 SLA 保持一致，且兩者之間存在直接的依賴關係。其中一項的失敗意味著所有項目的失敗。我們也會追蹤並回報來自服務本身（即伺服器）的指標，但這並非實現高可靠性的實際來源。

除了 SLI 之外，每次建置都會透過我們的 CI 工作流程收集並回報品質指標。此做法有助於嚴格執行品質門檻（例如程式碼覆蓋率），並回報其他有意義的指標，例如程式碼標準遵循情況與靜態程式碼分析。此主題先前已在另一篇文章《以效能為導向的微服務建構》中探討過。 在探討可靠性時，對品質的嚴謹把關至關重要，因為我們投入越多心力追求卓越的評分，就越有信心確保系統在惡劣條件下不會發生故障。

我們的團隊擁有兩個儀表板。其中一個提供對「消費者 SLI」與「依賴項 SLI」的全面可視化檢視；另一個則展示所有品質指標。我們正致力於將所有內容整合至單一儀表板，以便將我們關注的所有面向集中管理，並能隨時針對特定時間區間進行報告。

預見故障

進行架構審查是確保系統可靠性的基礎環節。首先，我們會確認系統是否具備冗餘設計，以及當依賴項發生故障時，服務是否具備存活機制。 除了常見的複製方案外，我們多數服務都採用了改良的雙重快取預載技術、雙重復原策略（例如本地佇列故障轉移），或是資料損失應對策略（例如交易支援）。這些主題內容相當廣泛，值得另撰一篇部落格文章探討，但最終的最佳建議是：實施那些能考量災難情境並將效能損失降至最低的解決方案。

另一個需預先考量的重要面向，是任何能提升連線能力的措施。這意味著必須積極追求低延遲的客戶端體驗，並透過快取控制技術、側車（sidecars）以及針對超時、斷路器和重試的高效能策略，讓客戶端做好應對極高流量的準備。 這些做法適用於任何客戶端，包括快取、儲存庫、佇列，以及 HTTP 和 gRPC 中的相互依賴客戶端。這也意味著需改善服務發出的正常運作訊號，並理解健康檢查在所有容器編排中扮演著重要角色。我們多數服務會將退化狀態的訊號作為健康檢查回饋的一部分，並在發送正常運作訊號前，先驗證所有關鍵元件是否正常運作。

將服務拆解為關鍵與非關鍵部分，已被證實有助於聚焦於最重要的功能。我們過去曾將僅供管理員使用的端點放在同一個服務中，雖然這些端點使用頻率不高，卻影響了整體延遲指標。將它們移至獨立的服務後，各項指標均呈現正向改善。

依賴項風險評估是識別依賴項潛在問題的重要工具。這意味著我們會找出 SLI 較低的依賴項，並要求其服務水準協定 (SLA) 進行對齊。在整合階段，這些依賴項需要特別關注，因此我們會投入額外時間進行基準測試，以確認新依賴項是否已足夠成熟，能符合我們的計畫需求。一個很好的例子就是我們早期採用 Roblox 儲存即服務 (Storage-as-a-Service) 的案例。 與此服務的整合需要提交錯誤單，並透過定期同步會議來溝通發現的問題與回饋。所有這項工作都標記了「可靠性」標籤，以便我們能快速識別其來源與優先級。在我們確信新依賴項已準備就緒之前，我們頻繁地進行特性分析。這項額外的工作有助於將依賴項提升至我們期望的可靠性水準，讓我們能為共同目標齊心協力。

為混亂建立架構

發生事故絕非樂見之事。但當事故發生時，其中蘊含著值得收集並汲取教訓的寶貴資訊，藉此提升可靠性。我們的團隊除了一般全公司通報外，另設有專屬的團隊事故報告機制，因此無論影響規模大小，我們都會聚焦於所有事故。 我們會釐清根本原因，並為所有工作設定優先級，以期未來能有效緩解問題。作為此報告的一部分，我們會邀請其他團隊以高優先級處理依賴項事件，並跟進確認妥善解決、進行回顧，以及尋找可能適用於我們的模式。

團隊針對每項服務編製《每月可靠性報告》，內容涵蓋本文所述的所有 SLI 指標、因可靠性問題而開啟的工單，以及與該服務相關的任何潛在事件。我們已習慣生成這些報告，因此下一步自然是實現資料擷取的自動化。執行這項定期工作至關重要，它提醒我們在開發過程中，可靠性始終是被持續追蹤與考量的重點。

我們的監控系統包含自訂指標與改良的警示機制，確保在已知或預期問題發生時，能盡快收到通知。所有警示（包括誤報）皆會每週進行審查。此時，完善所有文件至關重要，讓使用者清楚了解警示觸發或發生錯誤時會出現什麼情況，進而讓所有人都知道該如何應對（例如：應變手冊與整合指南需保持一致並經常更新）。

歸根結底，將品質理念融入企業文化，是實現更高可靠性最關鍵且決定性的因素。我們已能觀察到，這些應用於日常工作的實踐正逐步展現成效。 我們的團隊對可靠性極度執著，這也是我們最重要的成就。我們已更清楚意識到潛在缺陷可能造成的影響，以及這些缺陷可能在何時產生。實施這些實踐的服務，始終如一地達成了其服務水準目標（SLO）與服務水準協議（SLA）。協助我們追蹤所有工作的可靠性報告，不僅是團隊成果的最佳證明，更是提供給其他團隊的重要參考與寶貴經驗。這就是可靠性文化如何滲透到我們平台各個環節的方式。

邁向更高可靠性的道路並非坦途，但若想打造一個能重新定義人際互動方式、值得信賴的平台，這條路是必經之路。

Alberto 是 Roblox 帳戶身分識別團隊的首席軟體工程師。他在遊戲產業深耕多年，參與過多款 AAA 級遊戲及社交媒體平台的開發，並專注於高度可擴展的架構設計。如今，他正透過應用最佳開發實踐，協助 Roblox 實現成長與成熟。