大家好！我是Robert Neckorcuk, ArenaNet技术保障团队负责人。我的团队负责为激战系列游戏（北美服、欧服、中国服）提供一些后端支持，例如：游戏登录，聊天室，官方网站等。我们经常会和另外2个团队：游戏运营团队和游戏发布团队，有紧密的联系，作为他们坚强的后盾。当然，在日常游戏，数据分析，客服支持等事项中，我们也会为其提供后端支持。但我们最核心的工作内容是确保游戏服务器的工作正常以及丝滑。激战系列游戏的最大特点就是无需日常停机维护和更新。尽管我们很高兴这些基础设施搭建的成功，但是因此在后续的维护中我们也遇到了挑战。今天，我会分享上一次遇到的重大问题，以及我们从中学到的经验教训，这些都在支持着我们持续进步。

2020年5月11日，周一，太平洋时间早上6点，我接到了一个电话。我向你们保证，我不看日历都清楚的记得那个日子，这事到现在都记忆犹新。我们的游戏运营团队发现了一个数据问题，这会导致玩家在游戏时与服务器交互产生数据差异，并且我们的内部工具也提示了相关的报错警报。

啊，我的天呐。

我通常星期一都有周末综合症。事实上，我也更希望周一是平平淡淡的度过。打开了我工作用的电脑，加入了问题调查小组试着去找出根源以及解决方案。作为一个以“永不关机！”为目标的团队，调查结果是我们最担忧的方向 – 我们必须要重启游戏回档数据来修复问题。我也是第一次遇到这样的情况，这导致花了不少时间去确认需要走哪些申请流程与操作。在刚过9点的时候，我关闭欧洲服务器。

持续迭代

这次激战2的欧服问题持续长达了20多小时。要知道再上一次激战2的关服还是在2016年8月23日，只有短短几分钟时间。处理突发的在线问题从来不是一件有趣的事情，不过这也是一个很好的机会可以让我们从中学习，优化我们的基础架构和流程。我们的问题处理流程遵循大部分的游戏行业流程：

    • 确定问题发生所在的范围 — 是服务器出现了问题，或是数据中心，或是其他某个模块？看看我们是否能缩小调查范围。
    • 确定一个方案可以让服务器尽快运作起来 — 这里需要权衡正确方案与可行方案。如果我们只是东拼西凑让服务器变得可工作，那这会不会又对其他某些未知的东西产生影响。
    • 一旦服务器重新工作，就需要开始写报告了 — 这份报告需要写明发生了什么，这会反映出我们的哪些问题，我们采取的措施以及受到的影响。
    • 后续在工作中，与主要负责人开会，回顾这份报告并且核对时是否会对其他以及后续的项目产生相同的问题，优化或改进或重做。

我们不会只在发生问题的时候才去检查我们的流程/程序是否有问题以及是否需优化。在2017年，ArenaNet做出了数据库迁移的决定，使用AWS的云服务（从此没有宕机！）。在2020年，在完成了一些准备工作后，我们的数据分析日志完成了迁移。

所有的这些云服务器迁移是为了灵活性 – 我们有了快速/无感的持续优化我们的基础架构可能。在2020年初，我们开始了AWS云服务的全面升级，检查我们每一台在运作的服务器的成本和选项，从我们开发时所用到的服务器到在线PvP锦标赛的服务器。AWS云服务升级所用到的新服务器和硬件设备是全新的，这些是我们从2017年开始从未接触过的。这个计划将会改善玩家线上的游戏体验，我们游戏开发的环境，和一些后端工具的优化升级。在这次大革新中，我们同时升级了一些从没有改动过的服务器 – 这些服务器甚至从未重启过！

当在处理这样一个巨型项目时，最有效的策略是将它分割成数个容易管理的小板块 – 就好像将一块大披萨切开! 我们想要确认每一个服务器升级到AWS云服务的可能，幸运的是他们早在设计之初就已经合理的分为了数个板块 – 游戏服务器，数据服务器，商店服务器等。我们的计划是每次改动一个板块，完成后再进行下一个。对每一组改动，我们会从迁移内部开发服务器开始。我们会建立一个操作手册文档来记录操作的流程以及行为结果验证，然后根据操作手册步骤迁移我们的测试环境和线上环境。

对任何产品和公司，迭代能力是绝对的关键。在公司的内部，把产品拆成碎片，尽可能频繁和粗暴的蹂躏它。一旦你发现在任何时候所有东西都无比顺畅，那进入公众视野时将会无比的流畅顺滑。对于平台运维和游戏运营团队来说，这就意味着提高我们的服务质量。尽管说了这么多，开发者服务器和线上游戏服务器在规模上还是有着很大的区别，尽管我们希望所有的一切都表现的如我们所设计的一样，但他们仍然会有很多自己的个性。

 一些 (这里大大的简化了！) 我们数据库的背景: 我们有2台服务器，一台主要的和一台辅助的。当我们向数据库写入一条代码 “做出这个改变”，它会被发送到主要服务器中。然后主要服务器会向辅助服务器发送“做出这个改变” ，然后这个变动才开始自动生效。如果在主要服务器出现状况，辅助服务器此时会自动取代成为主服务器。这意味着中间不会出现断档或者数据丢失，当出现状况的服务器恢复后，新的主要服务器会向新的辅助服务器（就是原先出问题的主要服务器此时会降为辅助服务器）发送信息。为了这次升级，我们手动断开了主要数据库和辅助数据库之间的连接，升级辅助数据库然后再重新连接。

一个我们可以追踪到的一个重要的数据点是辅助服务器需要多久接收到所有来自主要服务器的信息，以及数据校验返回所需的时间。再结合其他服务器负载与运营情况，可以告诉我们服务器目前是否健康 – 我个人觉得关注这些图像曲线十分有趣。然后我们交替主要与辅助服务器，不断重复，然后我们就有了更多漂亮的曲线，以及一个完美的升级环境。在Dev测试环境下，所有的一切运行的如丝般顺滑。我们的Stage 测试环境为我们提供了第二次完整运行的机会，如果同样顺滑。我们就会对线上游戏进行更新。如2020年5月6日的欧服更新一样。

问题所在

在5月6日， 游戏更新如期进行。我们断开了2个服务器之间的连接，升级了辅助服务器，然后重新连接。信息被传送了过来，我们切换了主要服务器和辅助服务器，并再次重复了这操作。 信息传送与Dev测试环境下相比慢了一些，当考虑到线上游戏环境下更复杂情况，我们觉得这可能是正常现象。

5月7日,星期四,我们收到了一条 “磁盘空间将满”的警报。 我们在当时对一些数据做了一次备份，那确实占据了一些磁盘空间，但无论如何我们还是需要拓展磁盘空间。使用AWS云服务，存储空间的成本真的很便宜，只需要点击几下鼠标，容量就可以翻一倍。 一位游戏运营团队的小伙伴点击了数次他的鼠标，但是存储空间并没有如期拓展。星期五，我们想AWS云服务寻求了帮助，得到的建议是重启。当时这台服务器是主要服务器，我们在重启前将其切换到辅助服务器。

每当回顾过去，人们总是能很显而易见的发现错误的所在，但是在当时情况下，我们确实对一切一无所知。星期五的下午，我们尝试切换了主要和辅助服务器，这样我们就可以来一发快速重启。 但是，在那时，一些信息还在从主要服务器到辅助服务器缓慢传送中。计算显示，硬盘中的磁盘空间可以挺过周末，所以我们决定等周一回来上班后，再根据信息传送的进度，来切换服务器，并进行重启操作。

我们当然回来了…

当我们发现消息队列的缓慢后(简直是“龟速”), 我们并没有进一步深刻的考虑到后续消息队列的增加速度(那简直是“火箭升天般的速度”!)。 现在大家再一起回想一下当问题发生时主要服务器和辅助服务器是如何运作的。当遇到问题，主要服务器和辅助服务器自动切换，其中的一个可能就是信息列队过大。

在5月11日，周一早上2:41, 问题发生了，数据服务器将主要和辅助进行了切换。由于数据库记录的信息都在出问题的那台服务器中，并且由于信息传送队列的堵塞原因并没有被记录到另一台服务器上，主要与辅助服务器切换后，瞬间，所有玩家一起经历了一次时间旅行（当然是不好的经历），他们周五晚上的所有操作都被回档了。又过了痛苦的3小时，在早上5:40，我们的游戏运营团队路西收到了玩家的反馈。然后，在早上6:00 我被从睡梦中叫醒，然后早上9:00游戏服务器下线。

在游戏服务器下线后，我们第一时间重启了我们的主要服务器，并且正如预期所想，先前的扩展磁盘空间出现了！算是当时的一个好消息。 在新的扩展磁盘中，我们找到了大部分的自动备份文件和信息队列中的内容，直到2:41为止。

保存备份真的是一个好习惯。存储空间便宜，这也给你提供了恢复数据的选项，让你倍感安心，而且做到自动备份也十分便利。事实上使用备份恢复数据, emmmmmm…那是另一个故事了，主要我们并不经常那么做。一方面，数据库的负载原因，所以我们需要把所有东西都解析出来然后将需要的部分重新启用。另一方面，游戏服务器现在在离线中，我们有着很大的压力，想快速恢复数据，让游戏再次开始运行。

（题外话：我尽量将故事集中在主线上，但是这个问题确实也引发出了许多其他的问题，例如交易所，宝石兑换，新账号创建等。不同团队都多少因为这个问题受到了冲击。我感觉我完全能因为这次事件写一篇短篇小说！）

老实说，恢复的过程十分的无聊，我们只需要照着一份指导手册做就可以了。在管理界面中点击几下，剩下的交给机器自己运行即可。在我们开始前，我们必须在辅助服务器中拷贝和备份相同的文件确保我们在2台服务器上都存储着相同的数据。接着服务器将会根据备份的文件来设置数据库。这个操作会持续数个小时。最终将2个服务器的所有的数据记录调整至2:41的状态。这同样需要很长时间。第一个服务器在1:37完成，第二个服务器在4:30完成。

（题外话2：除了你所要做的工作外，将与你一起工作的人也会是你选择一个团队或者是公司的重要因素。我们团队中的几位，在早上5:30 或是 6:00被叫起后，除了睡了一小会儿午觉，不停歇的工作一直到第二天的凌晨。服务器保姆上线了! 每一个人都严阵以待的对待了这个问题并全程乐观的对待这个未知的问题。这支团队所做的一切都十分的出色。)

激战2的基础架构也十分的神奇。它可以支持到不停机维护，各种游戏特色内容，防止漏洞攻击，崩溃，甚至动态事件的难度！在5月12日，我们启用了一项自2016年以来全新的功能， 在线上环境测试游戏，但是并不对外开放游戏。即游戏上线后，只有开发者可以登录，但是普通玩家无法进入。

在4:44，我们开启了游戏，仅针对游戏内部开发者，QA测试人员，和一小部分受邀请的欧服的小伙伴可以登录。让我印象深刻的是，短短几分钟内，就有玩家确认了游戏正在进行线上测试，他们的进度将被恢复至周一凌晨。我推测是因为我们向玩家提供了API支持的原因！

在线上环境下进行了测试来确认数据库的健康状况和信息队列情况后，我们在早上5:37正式对外开放了游戏，在关服后的20个小时。团队中的每一位都很激动，能帮助玩家回到他们热爱的那个世界，包括我自己，我同样很高兴自己又可以去睡几个小时了。

呼呼呼

在几个小时的休息后，我们重新回到工作中，试图找到问题的根源。在那个下午，欧服的警报又一次触发，数据库的信息队列荷载过高。

啊，我的天呐，又来了。

我们针对这些新的报错情况添加了一些预警机制，现在看来都正常工作了。在接下来的2天中，我们一直在手动管理主要和辅助数据库的镜像和连接。我们一直在和数据库开发者，网络工程师，和我们的云服务技术支持经理沟通。我们配置了所有与信息队列，存储日志相关的设置。在经过了数天的无限阅读，知识采集，和尝试优化，我们最终在周五取得了突破。

欢呼！

根本原因是驱动程序。

驱动程序让软件的操作系统和设备之间可以进行正常数据通讯 — 如果你有鼠标或者绘画板之类的外设，你很有可能会需要下载并安装特定的驱动程序后方可使用他们。在这次问题中，服务器的操作系统并没有最新的驱动程序帮助它与硬盘进行高效连接。对于数据库来说从磁盘读写数据占用了99%的使用率，这一点不太对劲… （剩下的1%是 “wow” 因素。Wow，你有数据库. Wow? 酷。）

 当我们升级了服务器，我们从AWS的第四代升级到了他们的第五代服务器， 随之而来的就是服务器与连接设备之间的交互方式的不同(我并不完全了解整个系统如何运作，但是AWS的底层技术有一个很酷炫的名字： Nitro!)。 我们的驱动程序版本相对于AWS所需的版本来说是超前的，所以我们没有想到需要更多的更新。加上，在我们的Dev环境下，这问题完全没有发生！ 但是在线上游戏环境中我们也没有任何地方接近负载。尽管又是一个星期五并且意识到驱动程序更新可能失败后，我们决定继续向前。和先前一样，我们切断了数据库之间的连接，运行了驱动程序，然后重新连接。

信息队列竟然马上就处理完了。

数据读写速度达到了100,000 kb每秒, 之前的龟速那可是只有 700 Kb每秒。

我笑了。 我哈哈大笑 (场面一度失控)。

我们在另一台服务器上重复了这个操作。再一次，队列瞬间处理完毕。

那个周末，我睡了一个好觉。并且在那之后我度过了许多个理想的周一。

展望未来

所以，到底发生了什么，我们错过了什么，以及这个问题为什么发生。下一环节是我个人对于我工作最爱的部分：我们从中学到了什么？ 我们从中可以如何改善自己？我们一路上又遇到了哪些好心人？

好吧, 首先以及最重要的一点，这次事件深刻的提醒了我们Dev测试环境和线上游戏环境的不同。Dev环境非常适合测试，记录特定机制的表现情况等。但是，针对一些改变，比如多个机制下的负载测试和压力测试仍然是有必要的。

第二点，这是一次警示，需要时刻检查假设行为并且在一些行为未能达到预期的话需要退一步回想一下宏观观点。我们是在出现问题前做了测试和检查，但是我们将注意力放在了错误的地方。换一个人来检查也许能为我们提供一个完全不同的切入视角，更容易发现一些不寻常的地方，让我们检查确认这是否是一个潜在的问题。

对于数据库来说，这次问题的最大的进步是增加了许多关键数据的警报，不再仅仅是CPU或者硬盘空间。对于我们的线上运营，我们通过第三方工具添加了数个警报来改善我们在将来面对问题的处理时间。以及在其他一些运营工作中，我们增加了我们AWS 基础架构的操作记录存档，现在会记录下更多的内容。我们的报告现在会包括设备种类，版本号，驱动程序，和存储类型。我们在针对所有新的服务器，建立了一个公共文档，里面会有特定的驱动程序版本。任何未来的迁移计划我们都会更新这个公共文档，确保我们不会再犯这个错误。

我们已经完成了所有剩余数据的迁移，并且选择了更高的性能来优化服务体验。在过去14个月，我们的记录显示99.98%的时间下游戏运行正常，只有5次轻微的波动会影响用户登录。

我们一直致力于为玩家提供最 佳的游戏体验。我们很高兴我的同事们设计的世界一流的架构, 以及这事情后已经超过一年的持续稳定。我们知道可能无法做到一切完美，但是我们在之后的每一个开发和部署中做的更好。当激战2游戏设计和开发团队为你带来的令人兴奋的游戏内容时，我们会一直在幕后，确保你可以随时登录并享受。

Wow, 所以, 我知道我可以写很多的代码; 显然, 我也能写很长的文章。我希望你会喜欢这些与你分享的东西。这篇文章可能会花费你不少时间读完，但是我真的很高兴可以与大家分享这样的故事。

让我们在泰瑞亚见！
Robert