本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

GAMEOPS03-BP04 采用可最大限度地减少对玩家影响的部署策略

为游戏软件和基础架构制定部署策略，最大限度地减少让玩家无法进入游戏的停机时间。虽然某些类型的更新可能需要在游戏客户端上安装新的更新，但设计游戏时要最大限度地减少或避免部署期间的停机时间。

在未建立这种最佳实践的情况下暴露的风险等级：高

实施指导

制定游戏部署策略时要考虑的最重要步骤之一是确定如何管理游戏基础架构。使用基础设施即代码 (IaC) 工具（例如 Hashicorp 的 Terraform）管理游戏基础架构，以减少环境准备期间的人为错误。AWS CloudFormation基础设施模板可以在自动化管道中部署和测试，从而在不同游戏环境的配置中保持一致性。

有几种部署策略可用于游戏：

滚动替换

滚动替代部署的主要目标是在不关闭游戏和不影响玩家的情况下进行发布。重要的是，要执行的升级或更改必须向后兼容，并且能够与系统的先前版本相媲美。

在此部署中，服务器实例被运行更新版本的实例逐步替换（替代或推出）。这种滚动替换可以通过几种不同的方式进行。例如，要实现对一组专用游戏服务器的滚动更新，一种典型的方法是创建一个新的 Auto Scaling EC2 实例组，其中包含部署在其上的新游戏服务器编译版本，然后逐步将玩家路由到托管在这组新服务器上的游戏会话中。如果相关的游戏客户端更新是使用新游戏服务器版本的先决条件，则必须包括验证检查，以验证只有安装了此新游戏客户端更新的玩家才能进入这些游戏会话。

包含旧游戏服务器构建版本的服务器队列（例如 EC2 Auto Scaling 组）只有在以优雅的方式耗尽活跃玩家会话后才会从服务中移除，通常是通过设置允许游戏运营团队自动化此过程的个性化服务器指标。或者，为了减少基础设施数量和进行滚动部署的时间，可以采用另一种方法，将现有生产实例从服务中移除，使用新的游戏服务器版本进行更新，然后放回生产队列中。这种方法减少了所需的基础设施数量，但也增加了风险，因为随着服务器的更换，可供玩家使用的直播游戏服务器数量会减少。

此模型还可用于对不托管游戏的数据库、缓存和应用程序服务器等后端服务执行滚动部署。只要这些服务以高度可用的方式部署到多个集群实例，那么部署这些服务的复杂性应该低于部署到专用游戏服务器的复杂性。

Blue/green 部署

游戏中 blue/green 部署的主要目标是最大限度地减少停机时间，同时还允许在发现问题时安全地回滚到之前的部署。它适用于两个版本的游戏后端兼容并且可以同时为玩家提供服务的部署。

在 blue/green 部署策略中，设置了两个相同的环境（蓝色和绿色）。现有游戏版本标记为蓝色，而作为部署目标的新游戏版本标记为绿色。当绿色环境准备好进行迁移时，您可以配置路由层以将流量转移到绿色环境，同时保持旧环境（蓝色）在需要故障恢复时可用。在这种情况下，路由更新可能需要更新配对服务以将其配置为开始向新队列发送游戏会话，或者对于游戏后端服务，这可能是更新您的服务的 Amazon Route 53 中的 DNS 记录，或者转移应用程序负载均衡器的权重以将流量发送到新的目标群组。

blue/green 部署策略的缺点之一是由于执行部署时需要额外的基础架构，因此备用环境会产生固有的成本。降低额外基础设施成本的一个选择是考虑采用一种 blue/green 部署方式，将新游戏软件部署到已部署到生产环境中的相同服务器上。在这种情况下，可以在现有的蓝色服务器进程旁边使用新软件启动新的绿色服务器进程，切换发生在服务器进程之间，而不是在单独的物理基础架构之间。这种方法还可以省去等待新服务器在云端启动的麻烦，从而加快在大量基础设施上的游戏部署。有关此部署方法的最佳实践，请参阅Blue/Green部署 AWS。

金丝雀部署

Canary部署对游戏开发者很有用，因为该策略可以应用于发布游戏的早期Alpha版或测试版，也可以应用于发布游戏功能，例如新游戏模式、地图或向正在制作的受限或少数玩家发起挑战。这样的部署被称为金丝雀。该版本可能有额外的跟踪和报告，因此，当真实玩家玩该游戏或功能时，会收集他们的游戏遥测数据，并分析异常和问题。

对于新功能，玩家不会持续收到有关此事的通知，游戏遥测是用于确定玩家是否遇到问题以及是否应推迟发布的主要来源。同时，如果没有发现重大问题，则可以进一步向更多玩家推出该功能，以获取更多数据。如果玩家收到通知，则可以要求他们定期提供有关其体验的反馈。理想情况下，此类测试活动将由现场运营团队进行协调。

作为一种策略，Canary部署也可以用于标准版本，以逐步向玩家提供新功能。与标准 blue/green 环境相比，一个潜在的优势是不需要全面的第二环境。新的缩小环境的容量决定了有多少玩家加入新功能。在添加更多玩家之前，必须适当扩展容量。即使预计这种定制 blue/green 技术的成本相对低于标准技术，但据估计 blue/green，其成本仍可能高于金丝雀部署的滚动替代技术。

仅在生产环境中运行单个金丝雀，并集中精力获取数据和反馈。如果部署多个 Canarie，则会使生产中的问题排除和隔离变得复杂，并会降低数据集和所收集反馈的质量。

金丝雀的一个变体是通过定向部署运行一个或多个实验（通常是用户界面测试），其中一组游戏后端服务器提供功能的一个版本，而另一组大小相同的服务器则提供同一功能的另一个版本。没有为此创建任何额外或特殊的基础架构，只有选定的后端服务器部分才能收到这些更新。实验的结果是观察玩家对同一功能的每个版本的反应，确定总体上是否存在赞成或不喜欢的共识，并观察其可用性或功能是否存在问题。这样的战略实验也称为 A/B 测试，整个过程称为A/B 测试。完成这些实验后，将收集必要的测试数据，然后在用于测试的服务器上恢复到当前版本的游戏后端系统。

传统的传统部署

在传统的部署方式中，在定期维护时段内，游戏将关闭，连接的玩家被丢弃或耗尽，然后游戏后端中的服务器实例使用最新的代码版本进行更新。这种部署每次执行都会影响玩家，必须提前通知玩家。因此，该模型对玩家的影响最大，应尽可能避免。

部署游戏更新后，可以在向等待游戏重新开放的玩家开放游戏之前对游戏进行烟雾测试。当玩家尝试在短时间内登录和玩游戏时，这可能会导致流量激增。因此，如果游戏的设计不是为了应对这种高峰的流量，你可以选择逐步允许玩家分批重返游戏。

或者，你可以选择过度配置基础设施以维持开放流量的高峰，在游戏流量稳定下来之后，可以缩减资源。如有必要，在玩家数量最低的非高峰时段进行此类部署。频繁的定期维护以及长时间的维护本质上会带来玩家流失和潜在收入损失的风险。玩家还期望在新版本发布后发生变化，并且在停机一段时间后回来后可能会失去对游戏的信任。

实施步骤