以下检查清单概述了执行预发布“演练”的程序，并提供了“切换”的选项，以帮助您的游戏上线。

Edgegap建议您仔细执行每个列出的步骤，以帮助您避免潜在的问题。然而，这并不是强制要求使用Edgegap。

另外，这个列表中的每一步并不是每个步骤都需要。如果您的游戏已经上线，并且您正在从另一个平台迁移流量，您可能想要审查大部分步骤。如果游戏尚未发布并且很快就会发布，则可能只需一部分步骤。我想说的就是选择最适合您情况的步骤，但没有“准备得过于充分”的说法。

免责声明

使用状态和上下文API端点
为了确保平台稳定性，我们默认对您的组织进行每秒10个请求的速率限制，适用于上下文和状态API端点。超出此限制将返回错误请求过多 429。在可能的情况下，请考虑使用无限的注入环境变量和Webhook。

预发布“演练”前

在发布/补丁/事件前的两到三周，请确保讨论以下项目：

• 分享您的开发/后端团队与Edgegap之间的架构和通信流程（即，网络序列图）

• 提供基于玩家的预测流量（即基于之前版本/补丁、市场和玩家获取预算、将参与的主播等）

• 确保游戏在当前版本和Edgegap的平台上运行良好（即QA团队在Edgegap上使用游戏。）

• 列出KPI并分享双方用以跟踪指标的工具，即Steam统计、Elastic/Prometheus、Datadog等。

• 确保在演练前收集关键指标的数据（即CPU使用率、峰值CCU、平均比赛时长以及您跟踪一切正常所需的任何有用指标）在游戏服务器和服务下正确设置或编程（如果当前不可用）。

• 列出玩家通常使用的沟通渠道（即特定Discord服务器、Reddit等），以帮助监控玩家问题。

• 提供您如何在您的端产生负载的详细信息。Edgegap拥有生成游戏服务器部署的工具，但如果您有内部工具或想要邀请一组玩家/QA团队，请告知我们。

• 如果可能，请提供几个游戏密钥，以便Edgegap团队在整个程序中进行测试。

• 在Edgegap帐户上启用调试模式（如果可用）。

• 确定双方谁将是控制者（控制者是处理沟通和发出指令的主要人员；把它想象成机场控制员）。

• 写下所需步骤的清单（在双方）以从当前状态迁移到新状态。这个称为“程序方法”或“MOP”。（即发布、从另一个平台迁移、应用补丁等。）每个控制者（Edgegap和游戏团队）都应手边有清单。

  • 有关详细信息，请参阅本文档底部的部分）

• 是否可以回滚？如果可以，则需要写下双方的回滚活动清单。

演练

演练旨在精确重现发布程序。双方团队将在计划的日期共同协作，执行在发布期间的相同步骤系列。

• 在两组之间设置网络会议

• 确定来自每一方的关键联系点（即控制者）

• 打开所有正确的工具、仪表板和监控元素。

• 各控制者与其各自团队一起逐步进行“MOP”，在“上线”点停止

• 在继续之前，双方控制者获取“准备好去”的确认。

• 工作室的控制者继续通过“MOP”，在他们的端传递“上线”过程（即从其他供应商迁移流量、发布游戏/补丁等）

• 负载测试工具或QA团队被调动以产生流量。

• 双方团队监控指标，控制者如有情况发生立即发出警报。

• 继续/不继续回滚：如有需要，如果发布未按预期进行，可以请求回滚。

• 要求负载测试/QA团队停止。

演练结束后

• 列出收集的KPI并进行评估。

• 列出发布日之前需要修复的关键项目

• 双方控制者将更新他们的“MOP”，以解决任何缺陷/需要关注的元素

• 列出应在发布日期之后修复的很不错但不关键的项目。

• 对发布日期进行继续/不继续决策。

发布前1天（“T-1”）

• 双方确认发布所需的内容已准备好，即最新的源代码、发布期间没有其他活动、开启了正确的监控工具等。尤其是需要几个小时来设置的任何事项。

发布前1小时

• 与双方团队开始网络会议。

• 双方控制者开始执行他们的“MOP”。

• 跟踪双方的关键指标。

发布

• 双方控制者达成继续/不继续的共识。

• 工作室的控制者执行“MOP”以上线。

• 双方团队开始监控。

发布后1小时

• 识别任何影响游戏体验的错误/问题，这些需要尽快修复。

• 在需要的情况下进行修复/补丁。

• 检查发布前（在可能的情况下）与指标的比较。

• 如果可能，进行继续/不继续的回滚决策。

• 沟通双方的支持渠道。

发布后1天

• 列出所需的非关键更改。

• 计划/安排非关键更改/补丁。

• 评估持续的KPI和趋势。

这就是我们推荐的完整检查清单，以便您的游戏工作室为重大里程碑做好准备。

有关Edgegap如何处理您的游戏在意外流量激增情况下的流量的更多详细信息，您可以在这篇标题为“管理意外流量激增 - Edgegap的编排者如何为您的游戏处理扩展”的文章中找到详细信息。