
多人游戏预启动检查清单
以下检查清单概述了执行预发布“演练”的程序,并提供了“切换”的选项,以帮助您的游戏上线。
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的编排者如何为您的游戏处理扩展”的文章中找到详细信息。
书写者
Edgegap团队
