開服被打、半夜故障怎麼活？遊戲容災設計的四步
凌晨兩點半，值班的工程師把一張監控截圖丟進群組：登入服務的錯誤率豎成一堵牆，下面一排健康檢查全部轉紅，落點都在同一個區域。
截圖還沒看完，玩家群已經開始洗版。接下來半小時會發生什麼，其實在事故之前就已經決定：備援資料同步到幾點、第二區（備份所在的另一個城市據點）有沒有東西在跑、值班的人有沒有演練過切換。
容災這個詞聽著大，落到遊戲團隊就是兩個數：出事到玩家能再進來，要多久；這中間丟掉的資料，幾分鐘的量你承受得起。這兩個數定了，後面每一步才有判準：選哪一檔備援、要不要上多雲、DDoS 防護買多厚，全是照它反推。
所以容災不是多買一套機器放著，是先定「出事那天你丟得起什麼」，再反推架構和錢。 這篇把這件事拆成四步：定目標、選形態、把防護接進架構、開服前演練一次。
先定丟得起什麼，再談架構
兩個縮寫先說成人話。RTO（Recovery Time Objective，恢復時間目標）：出事到玩家能再進來，你承諾多久。RPO（Recovery Point Objective，恢復點目標）：能接受丟掉多少時間的資料，比如最近五分鐘的存檔可以重打，帳務記錄一行都不能少。目標定在哪，直接決定備援形態的檔位和帳單。
定目標有個討巧的順序：別猜原因，按「壞多大」準備。Google Cloud 的容災規劃指南就是這樣教的，把故障按範圍分成三檔：單一可用區（一個機房）、整個區域（一座城市級的雲據點）、跨區域。明天壞的是光纜還是程式沒人知道，壞多大卻可以事先分檔準備。
再按服務分層。官網掛一小時，看熱鬧的人少一些；房間伺服器掛五分鐘，香港和台北的對局裡立刻出現罵聲。同一個遊戲裡，不同服務的目標本來就不該是同一個。Google Cloud 的指南甚至明說，多數應用的恢復時間落在一小時到一天之間，不必全部追求零。目標的價值在於定得符合業務，後面每一檔形態都是照它選的。
為什麼值得認真定？Uptime Institute 的 2025 年停機分析裡，54% 的受訪者最近一次重大停機損失超過十萬美元，20% 超過一百萬；53% 的營運方三年內遇過停機。金額隨規模放大，但小團隊的比例只會更痛：收入斷流的每一小時都是真金白銀。停機不是小機率事件，容災的錢是編給兩種日子的：大概率的小事故，和小機率的大事故。
數據來源: Google Cloud〈Disaster recovery planning guide〉（按故障範圍定義 RTO/RPO、分級目標與成本優先檔示例），2026-09-19 擷取。
數據來源: Uptime Institute〈Annual Outage Analysis 2025〉（54% 最近一次重大停機損失逾 10 萬美元、20% 逾 100 萬美元、53% 三年內遇過停機），2026-09-19 擷取。
四檔備援形態：從關機到雙活
目標有了，形態往哪檔選就有依據。AWS 的容災白皮書把選型講成一條原則：先看你的 RTO 與 RPO 目標，再在這些做法之間挑。它列的四檔，從最省到最貴：
| 形態 | 平時長什麼樣 | 出事那天 | 目標量級 |
|---|---|---|---|
| 備份還原（backup & restore） | 只有備份，沒有常開資源 | 從備份重新拉起系統，等到能接人 | 小時級，最長一天 |
| 試點燈（pilot light） | 資料層常開同步，應用機器關著 | 先開應用層、擴容，再接流量 | 小時級 |
| 暖備援（warm standby） | 縮小版全功能常開 | 直接接新玩家，事後再擴容 | 分鐘級 |
| 雙活（multi-site active/active） | 兩個區同時服務玩家 | 大部分情況玩家無感 | 秒級 |
落到遊戲，四檔不是平均分配。更新包分發與官網，備份還原就夠，掛一天玩家罵兩句，不傷筋骨；若官網同時是下載與儲值入口，檔位自己往上調。登入與配對是進場的門，門關著全服務停擺，值得上暖備援：香港主區正常時，新加坡備區的縮小版登入與配對本來就在跑。對局伺服器最微妙：進行中的對局遷不過去，備援接的是新開的局；把房間也做成雙活的團隊極少，狀態同步的工程量和持續成本，多數遊戲撐不住。雙活那行「玩家無感」也別讀成零丟失——AWS 自己標了但書：資料寫壞了，仍得靠備份救回來。
實際搭起來常見的做法是混著用：登入與配對用暖備援常開，對局伺服器降到試點燈，資料照同步、應用機器平時不開，出事再按需拉起。主區與備區平時各自在跑什麼、錢花在哪條線上，畫在同一張圖裡。
數據來源: AWS 白皮書〈Disaster Recovery of Workloads on AWS〉（四檔策略定義、各檔 RTO 量級與按 RTO/RPO 選型的原則），2026-09-19 擷取。
多雲是不是更穩？先過狀態同步這關
整區故障的新聞、對單一廠商漲價的擔憂、怕被雲廠商斷供（停服、斷資源），讓遊戲多雲容災成了架構討論裡最常出現的詞。先把判斷擺前面：對多數遊戲團隊，多雲的難度在狀態同步，收益比想像小。
對局進度、帳號、虛寶庫存，這些狀態要在兩家雲之間保持一致，兩家的資料庫產品、網路工具、部署工具鏈都不通用，等於同一套東西做兩遍，還要讓它們對得上。常見的返工場景是：容災專案做到後來，第二朵雲（比如東京）上只放了一個關機的複製品，從沒驗證過能不能接流量；帳單是兩份，容災是半份。
真正該上多雲的理由有三種：監管要求資料落在特定司法區、單一廠商的斷供風險真實存在、要同步的只是官網、客服、論壇這類低頻寫入、晚幾秒對上帳也無所謂的系統。共同點都是「不得不」。所以這裡的建議很直接：別為了「更穩」兩個字上多雲，先把單雲多區加暖備援做紮實，穩定性問題它已經能解。
還有一個容易被冒充的東西要拆掉：接入分散。有些架構把同一個入口 IP 在多個地域同時掛牌——玩家和攻擊都就近被接走，騰訊雲的 Anycast 方案是典型做法。這解的是攻擊與延遲；但接進來的流量最後還是集中送回一處真正的後端，區域故障那天，入口再多，集中的後端一樣全倒。接入分散是防護設計，容災是另一件事，兩筆錢別互相冒充。
數據來源: 騰訊雲〈Anycast 公網加速實踐教程〉（一個 IP 多地宣告、後端集中回源的架構說明），2026-09-19 擷取。
DDoS 防護放進架構的哪一層
防護商品怎麼選、報價單怎麼核，遊戲伺服器 DDoS 防護採購那篇已經講完；這節只回答架構問題：買來的防護，接在架構的哪裡才算數。清洗（把攻擊垃圾從流量裡沖掉、只留正常玩家）這個動作，是防護商品在做；商品之外，架構要補的是另外半邊。
先說位址。真實伺服器（源站）不能露面：清洗的價值建立在攻擊打不到源站上，位址一洩漏，攻擊繞過清洗直接打源站，防護形同虛設。防護資源本身也要有備，單個高防 IP 壞了，防護就整個下線。剩下的告警與處理流程要事先配好：誰收到告警、收到之後按什麼順序動手，攻擊那天靠的是事先寫好的 runbook（處理手冊），不是臨場反應。Cloudflare 給遊戲行業的建議是防護常開（always-on），不是被打才開。
還有一個事實值得貼在架構圖旁邊。2022 年 10 月《鬥陣特攻 2》開服，Blizzard 官方事後說明確認當天確實遭到 DDoS，同時講清楚：攻擊加重了環境的困難，主因卻是登入資料庫過載、玩家要排兩次隊的雙層排隊機制，以及帳號合併問題。大廠的啟動日也會翻車，而且翻車點常不在攻擊本身；容量、狀態設計與防護，得當成一件事來設計。
香港或台北的開服日子已經定死的，防護和架構要一次談完，別分兩次補課；開服防護評估就是照這個順序走的。
數據來源: Blizzard〈Overwatch 2 Launch Status Update〉（DDoS 為加重項、主因為登入資料庫與排隊架構），2026-09-19 擷取。
數據來源: Cloudflare Spectrum 產品頁（遊戲行業 always-on 防護建議），2026-09-19 擷取。
備援的帳單，平時也在走
備援的錢有三塊，只有一塊顯眼。顯眼的是閒置資源：第二區的機器平時沒人用，帳單月月來。四檔形態本身就是成本檔位：非核心服務降到備份還原，沒有常開算力，只剩備份儲存與跨區拷貝費；暖備援把備區縮到最小可接容量，出事再擴；試點燈介於兩者之間，資料庫常開那筆錢省不掉。
看不見的兩塊更要記帳。一筆是同步費：香港到新加坡的主備之間，資料複製按流量持續計費。以 AWS 為例，同一區域內跨可用區每 GB 每方向一美分；跨區域按區域對逐對定價，官方知識庫的美國示例是每 GB 兩美分，香港、新加坡這類亞太區域對的價格要逐格查官方表，別拿美國數字當估價基準。這筆錢買的是「備區的資料是新鮮的」，砍了它，你定的 RPO 就作廢。另一筆是演練的人力：挑停機維護時段把主區關燈半天，工程師的時間也是錢，但比出事那天便宜得多。報價單上這些行話怎麼讀，計費字典那篇逐行翻譯過。
數據來源: AWS re:Post〈Cost effective methods for accessing S3 buckets cross-region〉（美國區域對跨區域傳輸 $0.02/GB 的官方示例）與 AWS NLB 資料傳輸成本部落格（跨可用區 $0.01/GB 每方向），2026-09-19 擷取。
演練過的容災才算數
演練之前先記一條原則：事故當下最靠不住的，是需要登入控制台臨時操作的東西。Google Cloud 的指南把它講成規矩——故障切換只能依賴資料面（data plane，平時就在跑的資料通路），不能依賴控制面（control plane，開機器、改權限這類管理動作）。試點燈那幾檔靠開機部署來還原，屬於計畫內的重建，目標才會落在小時級；要分鐘級接住玩家，切換路徑就必須長在資料面上。演練驗證的，就是這條路徑真的通。
挑停機維護時段做，三步起步：
- 關掉香港主區，模擬整區失聯，看新加坡備區接不接得住新登入與新配對。
- 計時。從關掉到玩家能再進來的實際時長，是 RTO 的下界——真實事故還要加上偵測與決策的時間，目標別定得比量出來的還緊。
- 驗告警與流程。告警送到誰手上、runbook 照著能不能一次跑完，錯在哪記下來改。
Uptime 的同一份分析裡，近四成機構三年內遇過人為錯誤導致的重大停機，其中 85% 源自沒按程序操作或程序本身有缺陷，這類占比還在上升。演練練的首先是人，其次才是機器。開服前做一輪，之後每個大版本前重跑；遊戲版本迭代會改動服務結構，容災路徑不跟著驗，會悄悄失效。
切換的邊界，演練也會順手量出來：備援接得住新進來的玩家，接不住已經在打的對局，玩家裝置裡存的舊地址（DNS 快取）也要等它過期。把這幾段時間疊起來，才是對玩家誠實的恢復目標；這條邊界的細節，台灣玩家那篇拆過，這裡就不重講。
容災的取捨到這裡就齊了：目標定得誠實，形態就選得省；演練跑過一遍，這筆錢才算真的花了。
先跟工程師要兩樣東西：現狀架構圖，和各服務現在的備援方式；再把你打算答應玩家的恢復時間寫在旁邊。形態選高了一檔，每月白花的是閒置帳單；選低了一檔，出事那天補回來的是罵聲和流失。這個取捨值得在 Telegram 上過一遍再定，通常一次就能聊清方向。
關於新星雲
容災做得好不好，要到出事那天才兌現；能在那天之前把取捨談清楚的，只有平時。新星雲是我一個人的顧問生意，不簽任何一家雲的代理，站上的比較才不用留情面；英文工單跟原廠來回的事，也能替你盯。你想照這篇的方法自己做，就從兩個數開始，這一步不需要任何人。
相關閱讀
- 遊戲伺服器 DDoS 防護怎麼買？先列攻擊面，再對報價單：防護商品與報價單的採購判斷，本篇防護段的下半場。
- 遊戲節點延遲不只看距離：封包走的是電信商買到的路：主區與備區之間的線路怎麼選，延遲數字怎麼測才作數。
- 香港遊戲伺服器節點怎麼選？延遲、頻寬、防護與備援實測：防護四層結構與節點評估的整張表。
- 雲端報價單為什麼看不懂？把行話逐行翻譯完，才輪到比單價：同步費、頻寬、資源包這些帳單行話的逐行翻譯。
- 開服防護評估與遊戲伺服器節點選型：本篇對應的兩個服務頁。
- 回到部落格總覽看其他選型與防護文章。
FAQ
多雲是不是一定比單雲多區穩？
不一定。多雲要把資料和狀態在兩家生態之間同步，資料庫、網路、工具鏈都不通用，難度和持續成本比單雲多區高得多；多數團隊做到最後是兩座各管各的孤島。穩定性問題，單雲多區加暖備援已經能解；真正該上多雲的理由是監管要求或真實的斷供風險，不是「更穩」。
RTO／RPO 怎麼定才不是拍腦袋？
先把兩個詞翻譯成錢和體感：RTO 是出事到玩家能再進來要多久，RPO 是能接受丟幾分鐘的資料。然後按服務分層定：官網壞一小時沒人管，房間伺服器壞五分鐘就炸，兩者的目標不該是同一個。Google Cloud 的官方指南明說，多數應用的恢復時間落在一小時到一天之間，目標該按業務定，不必全部追求零。
全球同服能不能做多區容災？
做不了傳統意義的雙活。全球同服的全服狀態只認一套說了算的主伺服器（權威伺服器），它壞了沒有第二套能頂。這時容災目標要降級：帳號、庫存這類持續進度，靠備份與資料複製恢復到幾分鐘前；正在打的對局救不回來。把「無感切換」說成全球同服也能上，是最常見的過度承諾。
DDoS 防護買了，架構上還要配什麼？
真實伺服器（源站）的位址不能露面，不然攻擊繞過清洗直接打源站；防護資源本身要有備援，單個高防 IP 壞了，防護就整個下線；告警和切換流程要先寫好、先演練，攻擊當天靠的是 runbook 不是臨場反應。防護商品管「進不來」，這些架構配置管「恢復得了」，缺一半就是缺一半。
備援平時閒置，帳單太貴怎麼省？
先把閒置壓下來：非核心服務降到備份還原，只剩儲存與拷貝費；暖備援縮到最小可接容量，試點燈的資料庫常開費省不掉。真正按 GB 走的是同步費：先估主備之間每個月同步多少資料，再判斷這筆買「備區資料新鮮」的錢值不值。
容災演練要做哪些、多久做一次？
最少三步：關掉主區模擬故障，看備援接不接得住新登入；把實際恢復時間記下來，對照定過的目標；檢查告警送到誰手上、處理手冊跑不跑得完。開服前做一輪，之後每個大版本前重跑。行業調查裡，人為錯誤停機的 85% 源自沒按程序或程序本身有缺陷，這類占比還在上升，演練練的首先是人。