激战2【激战2】ArenaNet内部——有关游戏服务器关停的分析

嗨！我是Robert Neckorcuk，ArenaNet的平台团队负责人。我和我的团队主要为激战系列游戏提供一些后端服务：登录服务器、聊天服务器、网站等等。作为后端服务组，我们与另外两个团队（游戏运营和发布管理）密切合作，同时还和游戏研发、市场分析、客户支持等部门协同。不过我们的工作重点还是维护游戏及其基础构架的实时状态。

激战系列最令人印象深刻的一点就是它强大的的在线服务可用性。尽管迄今为止我们的工作还算成功，但整个过程中仍然有一些小波折。在这里，我将分享一下上次游戏停服的细节和经验教训，以便我们继续改进，更好地履行对玩家们的承诺。

太平洋时间2020年5月11日星期一早上6点，我接到了一个电话。我敢向你们保证，这个日期绝对是准确的，因为那天的事情我到现在还记忆犹新。我们的游戏运营团队发现激战2的实时数据库发生了回档，玩家从游戏服务器接收到的信息开始出现错误，我们的内部工具显示了大量其他相关的警报和错误。

操蛋了。

我从没经历过那么刺激的周一。事实上，我宁愿我的周一过得平淡一点。我登录到我的工作台，和其他人一起调查到底发生了什么，以及我们可以做些什么来让游戏恢复正常状态。对于一个目标是“永远在线”的团队和公司来说，我们调查到了最坏的结果：我们必须关闭游戏才能将数据恢复到良好状态。由于这是我第一次遇到这样的事件，我花了一段时间才确定关闭服务器需要经过哪些许可和批复流程。就在上午9点之后，我提交了修改，禁止游戏登录，并关停了激战2的欧洲地区服务器。

不断地更新迭代

在这次停服期间，激战2的欧洲数据中心停摆了20多个小时。除了那些几分钟的小插曲以外，上次激战2停服还是在2016年8月23日。虽然处理这些突发状况从来都不是一件有趣的事，但我们能够把这些状况作为一个个学习的机会，从而改进我们的基础构架和工作流程。

在激战系列游戏中，我们对突发事件的处理流程与市场上大多数游戏公司一致：

1. 确定问题的范围：是在一台服务器、一个数据中心还是一个编译版本中。我们可以通过这个来确定是否可以把调查范围缩小到部分服务或地区。

2. 确定一种解决方法以使服务尽快恢复正常，而这将是一次规定和实际之间的权衡：如果我们在某一次通过强行修改某些数据来让服务器正常工作，我们在之后的事件中还会不会破解其他东西以达到相同的目的？这件事的界线在哪里？

3. 当服务恢复以后，我们还要完成事件报告。这个报告应该详细说明发生了什么，我们通过哪种途径得知了这个问题，我们采取了什么处理方式，以及都有谁受到了影响。

4. 在那之后，在正常工作时间，与主要利益相关者召开会议，审查事件报告并为可能出现的后续状况作出布置。这些工作可以是改进检测和***制、更新说明文档或自动化流程，抑或是开发新的工具。

我们并非在发生事故时才想起审视自己的流程和程序并做出改变。在2017年，ArenaNet决定利用AWS基础构架（并且无需停机时间！），从现场数据中心迁移到基于云技术的数据中心。2020年，在开始进行远程工作后，我们也完成了分析日志传输系统从硬件端到云端的迁移。

所有这些云迁移的都是为了更好的灵活性，从而使我们可以选择快速无缝地不断更改和修改我们的基础构架。在2020年初，我们启动了一次全面的内部AWS升级，考察了我们运行的每台服务器的成本和可用选项，从开发商务服务器到实时PvP调度服务器。AWS一直在提供新的服务和新的硬件类型，但自从2017年以来，我们就没有进行过全面的自我审查。这项计划将使我们做出改变，以改善现场游戏中的玩家体验，使我们的开发环境与现场游戏相匹配，并改进一些后端工具。我们还更新了一些自2017年迁移以来从未更改甚至重新启动过的服务器！

在处理一个大项目时，最有效的策略之一就是把它分解成更小、更易管理的小块……就像切一个大比萨饼一样！我们的计划是审查每个AWS实例，幸运的是，我们手头已经有了一些基于不同实例类型的玩意儿：游戏服务器、数据库服务器、商务服务器等。我们的计划是依次检查每一个，进行更改，然后转到下一组。对于每一系列更改，我们将从迁移内部开发服务器开始。我们将编写一份运行资料来记录流程并验证运行情况，然后按照运行资料逐步迁移我们的过渡环境和线上环境。

对于任何产品和公司来说，迭代的能力都是至关重要的。这就像是在你家里的后院里造一件东西，把它砸碎，尽可能经常地、并且用各种奇怪的方式摧毁它。一旦你在发布之前修复了所有东西，当它进入公众视野时，它将会是具有相当容错率的。对于平台和游戏运营团队来说，这种“实战研习”的过程是我们的另一个工具，对提高我们的服务质量非常有帮助。尽管如此，研发环境和在线游戏的服务器在成本和规模上都有很大的不同，所以尽管我们希望一切都“表里如一”，但它们仍然具有自己的特点。

我先交代一下我们的（极度言简意赅的）数据库背景：我们有两个数据库，一个主数据库和一个副数据库。当我们写入数据时，一条带有“实装这项修改”的消息被发送到主数据库。然后，主数据库向副数据库（或镜像）发送一条带有“实装这项修改”的消息，然后将更改应用于自身。如果主数据库出现了“故障”，则副数据库将临时作为主数据库自动接管数据并执行报告。这意味着整个过程不会出现停机或数据丢失，新的主数据库将在新的副数据库从“故障”中恢复后，将数据依照顺序重新备份给它。如果需要升级服务器，我们会手动断开主数据库和副数据库之间的连接，升级副数据库，然后重新连接它们。

我们可以用来追踪的一个重要指标就是副数据库从主数据库接收所有数据，并回到与主数据库一致的状态所需的时间。结合其他负载和运行状况指标，这可以告诉我们服务器是否正常，我个人觉得这些图表非常有趣。然后我们交换主副数据库，重复上面的操作，最后我们就得到了更完美的图表，以及一个完全升级过后的环境。 在开发环境中，一切都运行顺利。我们的过渡环境为我们提供了另一个服务器端到客户端进行测试流程的机会，而且运行也很顺利。随后我们于2020年5月6日（星期三）开始对欧洲地区服务器进行在线游戏更新。

问题出现在哪里

5月6日，在线更新完全按照计划进行。我们切断了连接，升级了副数据库，又重新建立了连接。数据复制过来以后，我们交换了主副数据库，并再次重复这些操作。数据的拷贝比起我们在开发环境中的实际运行要慢一点，但是考虑到实时游戏的流量，数据队列要大得多，所以这个速度也算正常。5月7日，星期四，我们接到了一个“磁盘空间将满”的警报。我们最近对数据进行了额外的备份，这占用了一些空间，但经验告诉我们，无论如何都要扩展磁盘卷。扩展存储的成本很低，如果使用AWS，只需点击几下鼠标，日志和备份驱动器的大小就可以增加一倍。游戏运营团队的一名成员点了几下鼠标，但扩展的存储空间并没有神奇地出现。周五，我们向AWS提交了一份协助请求，AWS建议重启服务器以纠正此问题。由于此服务器当前是主数据库，因此必须先与副数据库交换，然后才能重新启动。

如果我们现在回头去看，认清这样一个明显的错误是很容易的，但那时我们对这些事情一无所知。星期五下午，我们试图交换主副数据库，以便执行快速的重启。然而，当时从主数据库向副数据库发送的数据队列并不是空的，它仍然在缓慢地进行着备份。我们经过了简单的计算，认为硬盘在周末并不会完全填满，所以我们可以在周一早上返回，分析数据队列，交换服务器，然后重新启动。

然后等到星期一我们回来的时候……

虽然我们已经意识到了队列的发送速度十分缓慢（想想“海龟的速度”），但我们没有考虑到队列增长的速度（想想“喷气背包海龟的速度”！）。回想一下之前提到的数据库状况，如果主数据库发生了“故障”，则次数据库将自动接管作为新的主数据库。而数据队列变得太大正是导致数据库自动转移的“故障”之一。

5月11日，星期一，凌晨2:41，主副数据库进行了交换。由于实时更新的数据都在另一台服务器上的队列中，当数据库因故障交换时，突然间，玩家们经历了时间旅行（这并不是好消息），因为他们从周五晚上开始的所有进度都被抹去了。三个小时后，凌晨5点40分，因为大量的玩家报告，我们的游戏运营团队接到了电话。早上6点有人打电话给我，到9点，游戏就停服更新了。

游戏刚一停服，我们做的第一件事就是重新启动主服务器。正如预测的那样，磁盘卷成功扩展了！这是个好消息，如果没有别的事情发生的话。在新扩展的磁盘上，我们找到了最新的自动备份文件和包含所有数据队列的日志，截止到凌晨2:41。

保存备份是一种很好的做法。存储成本低廉，数据可以恢复，这使得开发人员可以安下心来，而且安排自动备份非常便捷。本来直接使用备份数据就万事大吉，但事情似乎并不像想象的那样，主要还是因为我们并不经常这样做。一方面，当时数据库没有负载，所以如果需要的话我们完全可以直接清空，从头运行。另一方面，游戏已经停摆，我们感到巨大的压力，需要快速准确地恢复数据，让游戏再次开放。

（旁注：我尽量只说故事的主线，但即便如此，我们围绕着这次故障所进行的其它分析研究仍然不能忽略，例如交易所、宝石商城、注册新账户等等。在这次事件中发生了很多事情，有许多不同团队的意见。我甚至觉得我可以写一整本关于这件事的小故事书！）

老实说，恢复过程相当无聊，我们只是遵循着使用指南进行了操作。在管理程序中单击几个按钮，服务器就开始运行了。在开始之前，我们必须将备份文件和日志文件复制到第二台服务器，以确保在这两台服务器上恢复相同的数据。然后服务器将数据库的状态设置为备份文件中包含的所有内容。这个过程花了几个小时。然后它将应用所有记录的数据，这样最终两个数据库将回档到凌晨2:41，这也需要很长时间。第一台服务器在凌晨1:37结束，第二台在凌晨4:30结束。

（旁注2：除了你的实际工作，与你一起工作的人可能是选择公司或团队最重要的因素。我们中有一小部分人，从早上5:30或6:00开始在线，只睡午觉，然后一直工作到第二天凌晨。说是服务器的保姆也不为过！我们团队中每个人都有能力认真对待局势，同时管理好自己，并有一点娱乐精神，这让我们平安度过了这一事件，这一点绝不能忽视。这个团队无论在决策还是执行上都做得非常出色。）

激战2的基础构架相当惊人。它能够在不停机的情况下进行更新，并且包含许多调节工具，可以影响游戏中的不同功能或内容，以防止漏洞攻击、崩溃，甚至可以在不需要测试版本的情况下改变动态事件的难度！就比如在5月12日，我们利用了游戏中自2016年以来从未有过的另一项功能，即无需登录即可上线。游戏将完全在线上运行，当然，这只允许开发者参与，不允许玩家参与。

凌晨4点55分，我们“打开”了游戏，一大批内部开发者、测试工程师和少数欧服合作伙伴登录了游戏。让我印象深刻的是，几分钟内，部分玩家们就已经发现游戏正在进行测试，他们的进度回档到了周一上午。我想当我们提供程序接口的时候就会发生这种情况！

在对实时环境进行冒烟测试（检查了数据库运行状况和消息队列）之后，我们在早上5:37向公众开放了服务器，时间是在关停后的20多个小时。团队中的每个人都很荣幸，能够帮助每个人回到他们热爱的世界，包括我自己。我也很高兴又睡了几个小时。

休息了几个小时后，我们都重新登录工作，试图了解故障的根本原因到底是什么。当天下午，欧服又触发了一个警报：数据库数据队列容量过高。

又操蛋了。

我们已经正确地识别了这些新发现的故障点，并为它们添加了一些警报机制。在接下来的两天里，我们手动管理了数据库镜像机制以及主副数据库之间的连接；与AWS的数据库管理员、网络运营商和技术客户经理都进行了沟通；配置了与消息队列、磁盘空间、存储和日志相关的所有设置。经过几天的阅读文档，从专家那里收集知识，尝试改变，我们终于在周五取得了突破。

奈斯！

最根本原因，实际上是驱动器。

驱动程序是一种允许软件操作系统与连接的设备进行通信的玩意，如果你有游戏鼠标或绘图板之类的外围设备，你可能已经下载了特定的驱动程序。在这次事件中，服务器的操作系统没有最新的通信方法与硬盘连接。在这样一个数据库中，读写数据到磁盘是它存在的全部原因的99%。（另外1%是“哇”的因素。“哇，你有数据库吗？酷。”）

当我们升级服务器时，我们正从AWS的第4代服务器升级到第5代服务器，随之而来的是服务器与连接设备的交互方式的不同（我不完全理解系统是如何工作的，但AWS对底层技术有一个很酷的名字：Nitro！）。我们的驱动程序版本领先于AWS提供的基本版本，所以我们不希望需要额外的更新。另外，在我们的开发环境中，这种问题根本没有出现！但我们也没有任何地方接近负载，因为我们的游戏始终处于在线运行状态。尽管又是一个星期五，但意识到驱动程序更新失败的后果，我们还是决定继续前进。

和以前一样，我们切断了数据库之间的连接，运行驱动程序更新，然后重新连接。

队列瞬间被清空。

数据写入速度为100000kbps，远远高于我们之前看到的700kbps。

我笑了。笑出声来了（甚至有点失控）。

我们在另一台服务器上重复了这个过程。又一次，队列瞬间被清空。

那个周末我睡得很安详。从那以后，我度过了许多美好的星期一早晨。

总结与展望

所以，这就是实际的情况，我们犯下的失误，以及一切的原因。接下来这部分则诠释了我为什么热爱这份工作：我们学到了什么教训？我们是如何利用它来成长和提高的？一路上我们交到了哪些朋友？

好吧，首先，这件事狠狠地提醒了我们，开发环境和在线环境的区别究竟有多么大。开发环境非常适合于练习、记录特定的性能指标等。但是，对于某些更新的实装，我们仍然需要在跨多台机器的环境下应用负载测试和压力测试等关键工具。

第二，这提醒了我们永远要验证假设，并退一步，看看整体的大局形势是否有不符合预期的表现。我们按照我们的职责在停服之前进行了调查，但我们搞错了重点。与其他人沟通将给我们提供一个不同的视角，防范我们侦测到的异常现象，以确保它不会变成更大的问题。

对于我们的数据库而言，最大的变化是增加了对关键数据库指标的***制，而不仅仅是对CPU或硬盘空间等系统指标进行预警。对于我们的在线操作，我们在第三方工具中添加了许多预警系统，以缩短我们对问题的响应时间。而对于一般操作，我们改进了AWS基础设施的记录保存模式，现在跟踪的不仅仅是某个实例。我们的报告现在包括实例类型、生成、驱动程序和存储类型。我们构建了一个通用包，安装在所有新服务器上，其中包括特定的驱动程序版本。任何未来的迁移计划都会更新这个通用包，确保不再重复这个问题。

我们已经完成了所有剩余数据库实例和一些其他实例的迁移，为提高服务提供了更好的性能。在过去的14个月中，我们记录了99.98%的正常运行时间，只有5次轻微的服务中断影响了用户登录。

我们不断努力的目标始终是为您提供我们服务的最佳体验和可用性。我们感激在我们之前的人所设计的架构，以及我们用来保持世界级运行效率的工具和流程。很高兴地告诉大家，我们的连续正常运行时间已经达到了一年的里程碑。我们认识到，我们可能无法做到完美，但我们一定会在今后的每一项工作和任务中努力奋斗。当我们期待激战2研发和设计团队为您带来的令人兴奋的新功能和项目时，我们一直在幕后工作，以确保您可以随时登录并享受。

哇，我知道我能写很多代码；但现在我才意识到原来我也可以写一篇很长的博客文章，真心希望你能够喜欢它。对一些人来说，这篇文章可能需要很长时间才能完成，但我真的很高兴能和大家分享这样的故事。我们很乐意阅读您对这类帖子的想法和反馈，所以我们在官方论坛上开了一个讨论帖，欢迎大家畅所欲言！

我们泰瑞亚见！

Robert

再逛逛>>