本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

GAMEOPS03-BP04 採用部署策略，將對玩家的影響降至最低

為您的遊戲軟體和基礎設施整合部署策略，將讓玩家無法玩遊戲的停機時間降到最低。雖然某些類型的更新可能需要對遊戲用戶端安裝新的更新，但請設計遊戲，以盡可能減少或避免在部署期間停機。

未建立此最佳實務時的曝險等級：高

實作指引

開發遊戲部署策略時需要考慮的最重要步驟之一，就是判斷如何管理遊戲基礎設施。使用基礎設施即程式碼 (IaC) 工具管理遊戲基礎設施， AWS CloudFormation例如 或 Hashicorp 的 Terraform，以減少環境準備期間的人為錯誤。基礎設施範本可以在自動化管道中部署和測試，這可在不同遊戲環境的組態中建立一致性。

有數種部署策略可用於遊戲：

滾動替換

部署的滾動替換主要目標是執行版本，而不關閉遊戲，也不會影響玩家。要執行的升級或變更必須回溯相容，且將與先前版本的系統相鄰運作。

在此部署中，執行更新版本的執行個體會逐步取代 （取代或推出） 伺服器執行個體。此滾動替換可以透過幾種不同的方式執行。例如，若要對專用遊戲伺服器機群實作滾動更新，典型的方法是建立新的 EC2 執行個體 Auto Scaling 群組，其中包含部署到這些執行個體的新遊戲伺服器建置版本，然後逐步將玩家路由到這個新伺服器機群上託管的遊戲工作階段。如果有相關聯的遊戲用戶端更新是使用新遊戲伺服器建置的必要條件，則您必須包含驗證檢查，以確認只有安裝了此新遊戲用戶端更新的玩家才能路由到這些遊戲工作階段。

包含舊遊戲伺服器建置版本的伺服器機群 （例如 EC2 Auto Scaling 群組） 只有在以正常方式耗盡作用中玩家工作階段後才會從服務中移除，通常是透過設定個別化伺服器指標來允許遊戲操作團隊自動化此程序。或者，為了減少基礎設施數量和執行滾動部署的時間，可以執行替代方法，其中現有生產執行個體從服務中移除，使用新的遊戲伺服器建置進行更新，然後放回生產機群。這種方法可減少所需的基礎設施數量，但也會增加風險，因為隨著伺服器被取代，玩家可用的即時遊戲伺服器數量也會減少。

此模型也可用於對後端服務執行滾動部署，例如資料庫、快取和未託管遊戲的應用程式伺服器。只要這些服務在多個叢集執行個體中以高可用性的方式部署，那麼部署到這些服務的複雜性應該小於部署到專用遊戲伺服器。

藍/綠部署

遊戲中藍/綠部署的主要目標是將停機時間降至最低，同時在發現問題時允許安全回復到先前的部署。它適用於兩個版本的遊戲後端相容且可同時為玩家提供服務的部署。

在藍/綠部署策略中，會設定兩個相同的環境 （藍和綠）。現有的遊戲版本會標示為藍色，而做為部署目標的新遊戲版本則會標示為綠色。當綠色環境準備好進行遷移時，您可以將路由層設定為將流量翻轉至綠色環境，同時在需要容錯回復時保持舊環境 （藍色） 可用。在此案例中，路由更新可能需要更新配對服務，以將其設定為開始將遊戲工作階段傳送至新機群，或者如果是遊戲後端服務，這可能會更新您的服務 Amazon Route 53 中的 DNS 記錄，或 轉移應用程式負載平衡器權重以將流量傳送至新目標群組。

由於執行部署時所需的額外基礎設施，藍/綠部署策略的缺點之一是待命環境的固有成本。降低此額外基礎設施成本的選項是考慮採用藍/綠部署的變體，其中新的遊戲軟體部署到已部署到生產環境的相同伺服器上。在此案例中，新的綠色伺服器程序可以使用新軟體 搭配現有的藍色伺服器程序啟動，並在伺服器程序之間進行切換，而不是在單獨的實體基礎設施之間進行切換。這種方法也可以透過消除在雲端中等待新伺服器啟動的需求，加速大量基礎設施的遊戲部署。如需此部署方法的最佳實務，請參閱 上的藍/綠部署 AWS。

Canary 部署

Canary 部署對於遊戲開發人員很有用，因為該策略可以套用來發行遊戲的早期 Alpha 或 Beta 建置，或遊戲功能，例如新遊戲模式、地圖或挑戰在生產中的受限或小型玩家。這種部署稱為 Canary。此版本可能有額外的追蹤和報告，因此當真正的玩家玩該遊戲或功能時，會收集和分析其遊戲遙測是否有異常和問題。

對於新功能，玩家不會持續收到通知，而且遊戲遙測是用來判斷玩家是否遇到問題的主要來源，並且應該復原發行版本。同時，如果未發現重大問題，則此功能可以進一步推出給更多玩家以取得其他資料。如果玩家收到通知，則可以要求他們定期提供有關其體驗的意見回饋。這類測試活動最好是由即時操作團隊協調。

作為策略，Canary 部署也可以用於標準版本，逐步為玩家提供新功能。與標準藍/綠環境相比，潛在的優勢是不需要完整規模的第二個環境。新縮減規模環境的容量決定要加入多少玩家加入新功能。在新增更多玩家之前，必須適當擴展容量。即使此自訂藍/綠技術預期成本低於標準藍/綠，但仍估計會產生的成本可能高於金絲雀部署的滾動替代技術。

只對生產環境執行單一 Canary，並針對其資料和意見回饋聚焦。如果部署了多個 Canary，它會使生產環境中問題的疑難排解和隔離更為複雜，並損害所收集資料集和意見回饋的品質。

Canary 的變化是當一或多個實驗 （通常是 UI 測試） 透過目標部署執行時，其中一組遊戲後端伺服器提供一個版本的功能，另一組相同大小的套件提供另一個版本的相同功能。系統不會為此建立其他或特殊基礎設施，而且只有所選的後端伺服器插槽會收到這些更新。實驗的結果是觀察玩家如何對相同特徵的每個版本做出反應，判斷整體上是否贊同，並觀察其可用性或功能是否發現問題。這種策略實驗也稱為 A/B 測試，而整體程序稱為 A/B 測試。完成這些實驗後，在還原至用於測試的伺服器上的遊戲後端系統目前版本之前，會 收集必要的測試資料。

傳統傳統部署

在傳統的部署風格中，在排定的維護時段期間，遊戲會關閉，並在遊戲後端內的伺服器執行個體更新為最新的程式碼建置之前，先捨棄或耗盡連線的玩家。此部署每次執行時都會影響玩家，而且必須提前通知玩家。因此，此模型對玩家的影響最大，應盡可能避免。

部署遊戲更新之後，遊戲可以在向玩家開放遊戲之前進行煙霧測試，玩家會等待遊戲重新開啟。當玩家在短時間內嘗試登入和玩遊戲時，這可能會導致流量激增。因此，如果遊戲的設計無法處理這類流量峰值，您可以選擇逐步允許玩家分批返回遊戲。

或者，您可以選擇過度佈建基礎設施，以維持流量的高峰，並在遊戲流量穩定之後，將資源縮減。如有必要，請在玩家數量最低的離峰時段執行此類部署。經常排程的維護以及延長的維護，本質上會有玩家流失和收入損失的風險。玩家也預期在新版本之後會有變更，而且在停機一段時間後返回時，可能會失去對遊戲的信任。

實作步驟