Roblox 恢复服务

自10月28日起，Roblox经历了一次持续73小时的系统中断，并于10月31日完全恢复正常。¹ 每天有5000万玩家定期使用Roblox，为了打造玩家所期待的游戏体验，我们的系统规模涉及数百项内部在线服务。与任何大型服务一样，我们偶尔会遇到服务中断的情况，但此次中断时间之长使其尤为引人关注。 我们对此次停机向社区致以诚挚的歉意。

我们分享这些技术细节，旨在让社区了解问题的根本原因、我们的处理方式，以及为防止未来发生类似问题所采取的措施。我们重申，此次事件中未发生用户数据丢失，也未出现任何信息被未经授权方访问的情况。

Roblox 工程团队与 HashiCorp 的技术人员通力合作，成功恢复了 Roblox 的服务。我们要特别感谢 HashiCorp 团队，他们调集了强大的资源，并与我们不懈协作直至问题彻底解决。

服务中断概况

此次服务中断在持续时间和复杂性上都具有特殊性。团队必须依次应对一系列挑战，才能查明根本原因并恢复服务。

• 此次服务中断持续了 73 小时。
• 根本原因在于两个问题。在 Consul 启用一项相对较新的流式传输功能时，由于读写负载异常高，导致了过度的资源竞争和性能下降。此外，我们特定的负载条件还触发了 BoltDB 中的病态性能问题。Consul 内部使用开源的 BoltDB 系统来管理用于领导者选举和数据复制的写入前日志（WAL）。 
• 一个支持多种工作负载的单一 Consul 集群加剧了这些问题的影响。
• 诊断这些深埋在 Consul 实现中、且主要互不相关的两个问题所面临的挑战，是导致停机时间延长的主要原因。 
• 本应能更好地揭示停机原因的关键监控系统，却依赖于受影响的系统（如 Consul）。这种组合严重阻碍了故障排查过程。
• 在将 Roblox 从长时间完全停机状态恢复的过程中，我们采取了深思熟虑且谨慎的做法，这也耗费了相当长的时间。
• 我们已加快工程进度，以改进监控、消除可观测性堆栈中的循环依赖，并加速启动过程。 
• 我们正在努力向多个可用区和数据中心迁移。
• 我们正在修复 Consul 中导致此次事件的根本原因。

前言：我们的集群环境与 HashiStack

Roblox 的核心基础设施运行在 Roblox 数据中心内。我们部署并管理自己的硬件，以及基于该硬件构建的计算、存储和网络系统。我们的部署规模庞大，拥有超过 18,000 台服务器和 170,000 个容器。

为了在多个站点运行数千台服务器，我们采用了一套通常被称为“HashiStack”的技术组合。Nomad、Consul 和 Vault 是我们用于管理全球服务器和服务的技术，它们使我们能够协调支持 Roblox 服务的容器。

Nomad 用于任务调度。它决定哪些容器将在哪些节点上运行，以及它们可通过哪些端口访问。它还会验证容器的健康状态。所有这些数据都会被转发到服务注册表（Service Registry），这是一个存储 IP:端口组合的数据库。Roblox 服务通过服务注册表相互定位，从而实现通信。这个过程被称为“服务发现”。 我们使用 Consul 进行服务发现、健康检查、会话锁定（用于构建其上的高可用性系统），并将其作为键值存储。

Consul以机器集群的形式部署，分为两个角色。“投票节点”（5台机器）权威地维护集群状态；“非投票节点”（另外5台机器）则是只读副本，用于协助扩展读取请求。在任何给定时刻，集群都会选举其中一台投票节点作为领导者。领导者负责将数据复制给其他投票节点，并确定写入的数据是否已完全提交。  Consul 采用名为 Raft 的算法进行领导者选举，并以此在集群中分发状态，确保集群中的每个节点就更新内容达成一致。领导者在一天内通过选举更换数次的情况并不少见。

下图是事件发生后 Roblox 上的 Consul 仪表盘近期截图。本文提及的许多关键运营指标均处于正常水平。例如，KV 应用时间在 300 毫秒以内被视为正常，而此时该值为 30.6 毫秒。Consul 领导者在过去 32 毫秒内曾与集群中的其他服务器建立过联系，这表明联系非常近期。

在10月事件发生前的几个月里，Roblox将Consul从1.9版本升级至1.10版本，以利用其新增的流式传输功能。该流式传输功能旨在显著降低在Roblox这类大规模集群中分发更新所需的CPU和网络带宽。

初步检测（10月28日 13:37）

10月28日下午，Vault性能出现下降，且有一台Consul服务器CPU负载过高。Roblox工程师随即展开调查。此时玩家尚未受到影响。

初步排查（10月28日 13:37 – 10月29日 02:00）

初步调查表明，Vault 及许多其他服务所依赖的 Consul 集群状态异常。  具体而言，Consul集群的指标显示，其底层键值存储（Consul用于存储数据）的写入延迟显著升高。此类操作的第50百分位延迟通常低于300毫秒，但此时已达到2秒。在Roblox这种规模的环境中，硬件问题并不罕见，且Consul具备应对硬件故障的能力。然而，如果硬件只是运行缓慢而非完全故障，仍会影响Consul的整体性能。 在此情况下，团队怀疑硬件性能下降是根本原因，并开始更换 Consul 集群中的一个节点。这是我们对此次事件的首次诊断尝试。大约在同一时间，HashiCorp 的员工加入了 Roblox 工程师的行列，协助进行诊断和修复。从此刻起，所有提及“团队”和“工程团队”的地方均指 Roblox 和 HashiCorp 的员工。

即便更换了新硬件，Consul集群的性能仍持续受挫。16:35时，在线玩家数量骤降至正常水平的50%。

此次故障恰逢系统健康状况显著恶化，最终导致系统完全瘫痪。原因何在？当 Roblox 某项服务需要与另一项服务通信时，它依赖 Consul 来获取目标服务位置的最新信息。 然而，如果 Consul 状态异常，服务器将难以建立连接。此外，Nomad 和 Vault 也依赖 Consul，因此当 Consul 状态异常时，系统将无法调度新容器或检索用于身份验证的生产密钥。简而言之，系统故障的原因在于 Consul 作为单点故障，且其状态异常。

此时，团队针对故障原因提出了一个新假设：流量激增。或许是因为系统达到了临界点，导致运行 Consul 的服务器无法再处理如此大的负载，从而使 Consul 运行缓慢？这是我们第二次尝试诊断此次事件的根本原因。

鉴于事件的严重性，团队决定将 Consul 集群中的所有节点替换为性能更强的新机器。这些新机器拥有 128 个核心（性能提升 2 倍）以及更新、更快的 NVMe SSD 硬盘。截至 19:00，团队已将集群的大部分节点迁移至新机器，但集群状态仍未恢复正常。 集群报告显示，大部分节点无法跟上写入需求，且键值写入的第50百分位延迟仍维持在2秒左右，而非通常的300毫秒或更短。

恢复服务尝试 #1（10月29日 02:00 – 04:00）

前两次将 Consul 集群恢复至健康状态的尝试均未成功。我们不仅仍观察到 KV 写入延迟居高不下，还出现了一个无法解释的新症状：Consul 领导者节点会定期与其他投票节点出现不同步。 

团队决定关闭整个 Consul 集群，并使用故障发生前几小时（即故障开始时）的快照重置其状态。我们明白此举可能会导致少量系统配置数据丢失（而非用户数据丢失）。鉴于此次故障的严重性，且我们确信必要时可手动恢复这些系统配置数据，因此认为这是可以接受的。 

我们预计，从系统健康时的快照恢复将使集群恢复正常状态，但还有一项额外顾虑。尽管此时 Roblox 系统中没有用户生成的流量，但 Roblox 的内部服务仍在运行，并会定期向 Consul 查询其依赖项的位置并更新健康状态信息。这些读写操作给集群带来了显著的负载。 我们担心，即使集群重置成功，这些负载也可能立即导致集群再次陷入不健康状态。为解决这一问题，我们在集群上配置了 iptables 来阻止访问。这使我们能够以受控的方式重启集群，并帮助我们判断：在排除用户流量的情况下，我们施加在 Consul 上的负载是否是问题的一部分。

重置过程顺利完成，起初各项指标看起来都很理想。当我们移除 iptables 阻断规则后，来自内部服务的服务发现和健康检查负载如预期般恢复。然而，Consul 的性能开始再次下降，最终我们又回到了原点：KV 写入操作的第 50 百分位数再次达到 2 秒。 依赖 Consul 的服务开始将自身标记为“不健康”，最终系统又回到了那个如今已司空见惯的故障状态。此时已是凌晨 4 点。显然，我们施加在 Consul 上的负载中存在某些问题，但在事件发生超过 14 小时后，我们仍然不知道问题出在哪里。

第二次恢复服务尝试（10月29日 04:00 – 10月30日 02:00）

我们已排除硬件故障的可能性。更快的硬件不仅未见改善，而且后来我们发现，这甚至可能损害了系统稳定性。重置 Consul 的内部状态同样无济于事。 此时虽无用户流量涌入，但 Consul 运行依然缓慢。我们曾利用 iptables 逐步放行流量重返集群。难道仅仅是因为成千上万个容器试图重新连接，其庞大的流量就将集群推回了不健康状态？这是我们第三次尝试诊断此次事件的根本原因。

工程团队决定先减少 Consul 的使用，然后有条不紊地逐步恢复其服务。为了确保有一个干净的起点，我们还屏蔽了剩余的外部流量。 我们整理了一份使用 Consul 的服务详尽清单，并部署了配置变更以禁用所有非必要的使用。由于涉及的系统种类繁多且配置变更类型各异，这一过程耗时数小时。通常运行数百个实例的 Roblox 服务被缩减至个位数。健康检查频率从 60 秒降低至 10 分钟，以给集群提供更多的缓冲空间。 10月29日16:00，即故障发生超过24小时后，团队开始了第二次尝试，试图让Roblox恢复在线。这次重启尝试的初期阶段看起来也很顺利，但到了10月30日02:00，Consul再次处于不健康状态，而这次来自依赖它的Roblox服务的负载明显更小。

至此，显然28日首次发现的性能下降问题，其成因不仅在于Consul的整体使用情况。基于这一认识，团队再次调整了方向。他们不再从依赖Consul的Roblox服务的角度出发，而是开始深入研究Consul的内部机制以寻找线索。

对竞争的调查（10月30日 02:00 – 10月30日 12:00）

在接下来的10小时内，工程团队深入分析了调试日志和操作系统级别的指标。这些数据表明，Consul的键值对写入操作被长时间阻塞，即发生了“竞争”。虽然竞争的具体原因尚不明确，但有一种推测认为，故障初期将服务器从64核升级至128核可能加剧了问题。 在查阅下图所示的 htop 数据和性能调试数据后，团队得出结论：值得恢复到与故障前类似的 64 核服务器。团队随即开始准备硬件：安装 Consul、三遍核对操作系统配置，并尽可能细致地将机器调试至可投入运行的状态。 随后，团队将 Consul 集群重新迁移回 64 核服务器，但这一变更并未奏效。这是我们第四次尝试诊断此次事件的根本原因。

已查明根本原因（10月30日 12:00 – 10月30日 20:00）

数月前，我们在部分服务上启用了 Consul 的一项新流式传输功能。该功能旨在降低 Consul 集群的 CPU 占用率和网络带宽，运行效果符合预期，因此随后几个月里，我们逐步在更多后端服务上启用了该功能。10 月 27 日 14:00，即服务中断的前一天，我们在负责流量路由的后端服务上启用了该功能。 作为此次部署的一部分，为了应对年底通常出现的流量激增，我们还将负责流量路由的节点数量增加了50%。在事件发生前的一天，系统在该规模下配合流式处理运行良好，因此起初并不清楚性能为何发生变化。 然而，通过分析 Consul 服务器的性能报告和火焰图，我们发现流式处理代码路径正是导致 CPU 占用率居高不下的竞争根源。我们随即禁用了所有 Consul 系统（包括流量路由节点）的流式处理功能。配置变更于 15:51 完成传播，此时 Consul 键值写入的第 50 百分位数降至 300 毫秒。我们终于取得了突破。

为何流式传输会成为问题？HashiCorp 解释道，虽然流式传输总体上更高效，但在其实现中使用的并发控制元素（Go 通道）比长轮询更少。在极高负载下——具体而言，即读写负载同时极高时——流式传输的设计会加剧单个 Go 通道上的竞争，从而导致写入期间发生阻塞，使其效率显著降低。 这种行为也解释了高核心数服务器出现异常的原因：这些服务器采用双插槽架构，并具备 NUMA 内存模型。因此，在该架构下，共享资源上的额外竞争变得更加严重。通过关闭流式传输，我们显著改善了 Consul 集群的运行状况。

尽管取得了突破，但我们尚未完全摆脱困境。我们观察到 Consul 会间歇性地选举新的集群领导者，这本属正常；但同时也发现，部分领导者出现了与禁用流式传输前相同的延迟问题，这显然不正常。 由于缺乏指向“迟缓领导者”问题根本原因的明显线索，且有证据表明只要某些服务器不被选为领导者，集群就能保持健康，团队做出了务实的决定：通过阻止问题领导者保持当选状态来绕过该问题。这使团队能够专注于将依赖 Consul 的 Roblox 服务恢复到健康状态。

但这些“慢领导者”究竟怎么回事？虽然我们在事件发生期间未能查明原因，但 HashiCorp 的工程师在停机后的几天内确定了根本原因。 Consul 使用名为 BoltDB 的流行开源持久化库来存储 Raft 日志。它并非用于存储 Consul 内的当前状态，而是用于存储正在应用的操作的滚动日志。为了防止 BoltDB 无限增长，Consul 会定期执行快照操作。该操作将 Consul 的当前状态写入磁盘，然后从 BoltDB 中删除最旧的日志条目。 

然而，由于 BoltDB 的设计机制，即使最旧的日志条目已被删除，BoltDB 在磁盘上占用的空间也从未缩减。相反，所有曾用于存储已删除数据的页面（文件内的 4KB 段）会被标记为“空闲”，并被重新用于后续写入操作。 BoltDB 通过名为“空闲列表”（freelist）的结构来追踪这些空闲页。通常情况下，更新空闲列表所需的时间不会对写入延迟产生显著影响，但 Roblox 的工作负载暴露了 BoltDB 中一个病态的性能问题，导致空闲列表的维护成本极高。 

恢复缓存服务（10月30日 20:00 – 10月31日 05:00）

自服务中断开始已过去 54 小时。随着流式传输功能被禁用，且已实施防止低效领导节点持续当选的机制，Consul 现已保持稳定运行。团队已准备好专注于恢复服务。

Roblox 的后端采用典型的微服务架构。 在微服务“堆栈”的最底层是数据库和缓存。这些数据库未受此次故障影响，但缓存系统却处于不健康状态——该系统在正常运行时，其多层架构每秒需处理约 10 亿次请求。由于我们的缓存存储的是可从底层数据库轻松重新加载的临时数据，因此将缓存系统恢复至健康状态的最简便方法就是重新部署。

缓存重新部署过程遭遇了一系列问题： 

1. 这很可能是由于此前执行的Consul集群快照重置所致，缓存系统存储在Consul KV中的内部调度数据出现了错误。 
2. 小型缓存的部署耗时超出预期，而大型缓存的部署则无法完成。经查，存在一个被任务调度器识别为完全正常（而非异常）状态的故障节点。这导致任务调度器试图在该节点上密集调度缓存任务，但因节点处于异常状态而失败。 
3. 缓存系统的自动化部署工具原本设计用于支持对已处理大规模流量的现有部署进行增量调整，而非从零开始迭代构建大型集群。 

团队通宵达旦地排查并解决了这些问题，确保缓存系统正确部署并验证其运行状态。10月31日05:00，即故障发生61小时后，我们已恢复了健康的Consul集群和缓存系统，并准备好重启Roblox的其余部分。

玩家回归（10月31日 05:00 – 10月31日 16:00）

最终的恢复服务阶段于31日05:00正式开始。与缓存系统类似，在初始故障或故障排查阶段，大量运行中的服务已被关闭。团队需要以正确的容量级别重启这些服务，并验证其运行是否正常。这一过程进展顺利，到10:00时，我们已准备好向玩家开放服务。

鉴于缓存处于冷启动状态且系统稳定性尚存疑虑，我们不希望出现流量洪峰，以免系统再度陷入不稳定状态。为避免流量洪峰，我们采用了DNS分流策略来管控访问Roblox的玩家数量。通过这种方式，我们允许一定比例的随机选定玩家进入，其余玩家则继续被重定向至静态维护页面。 每次提高放行比例时，我们都会检查数据库负载、缓存性能以及整体系统稳定性。工作持续了一整天，访问权限以大约10%的增量逐步放开。 我们很高兴看到一些最忠实的玩家破解了我们的 DNS 引导机制，并在 Twitter 上分享这一信息，以便在服务恢复时获得“提前”访问权限。周日 16:45，即故障发生 73 小时后，100% 的玩家恢复了访问，Roblox 已全面恢复运行。

基于此次故障的进一步分析与调整

尽管玩家已于10月31日重返Roblox，但Roblox与HashiCorp在随后的整个星期里仍在持续深入分析此次故障。 新流媒体协议中的具体竞争问题已被识别并隔离。尽管HashiCorp曾针对与Roblox使用规模相当的流媒体进行过基准测试，但由于该问题源于海量流媒体与高流失率的叠加效应，此前并未观察到这种具体表现。 HashiCorp 工程团队正在创建新的实验室基准测试以复现该特定竞争问题，并进行额外的规模测试。HashiCorp 还致力于改进流式传输系统的设计，以避免在极端负载下发生竞争，并确保在此类条件下保持稳定性能。 

对“慢领导者”问题的进一步分析，还揭示了 Raft 数据写入耗时两秒以及集群一致性问题的主要原因。工程师们通过分析如下所示的火焰图，深入了解了 BoltDB 的内部工作原理。

上述命令的输出结果向我们揭示了以下几点：

• 这个 4.2GB 的日志存储中，实际存储的数据（包括所有索引内部数据）仅为 489MB。其中 3.8GB 是“空闲”空间。
• 空闲列表大小为 7.8MB，因为它包含了近百万个空闲页面 ID。

这意味着，每次日志追加（即经过批处理后的每次 Raft 写入）时，即使实际追加的原始数据仅为 16KB 或更少，系统仍会将一个新的 7.8MB 空闲列表写入磁盘。 

这些操作产生的反向压力还导致 TCP 缓冲区满载，并导致不健康的领导者写入时间延长至 2-3 秒。下图展示了事件期间对 TCP 零窗口的研究。

HashiCorp 和 Roblox 开发并部署了一套流程，利用现有的 BoltDB 工具对数据库进行“压缩”，从而解决了性能问题。

近期改进与未来计划

自服务中断以来已过去 2.5 个月。这段时间我们都在做什么？ 我们利用这段时间尽可能多地从此次故障中吸取教训，根据所学调整工程优先级，并大力强化系统安全性。Roblox 的核心价值观之一是“尊重社区”，虽然我们本可以更早发布公告说明情况，但我们认为，在发布前先在提升系统可靠性方面取得显著进展，才是对社区应尽的责任。 

已完成的及正在进行的可靠性改进措施清单过于冗长且细节繁多，无法在此详述，但以下是关键内容：

遥测系统优化

我们的遥测系统与 Consul 之间存在循环依赖关系，这意味着当 Consul 状态异常时，我们会缺乏本应有助于排查故障的遥测数据。我们已消除这一循环依赖。我们的遥测系统不再依赖于其配置监控的系统。

我们已扩展遥测系统，以更清晰地监控 Consul 和 BoltDB 的性能。如今，一旦系统出现任何接近此次故障诱因的状态迹象，我们便会收到高度精准的警报。此外，我们还扩展了遥测系统，以更深入地洞察 Roblox 服务与 Consul 之间的流量模式。这种对系统多层级行为和性能的额外可视化能力，已在系统升级和调试过程中为我们提供了切实帮助。

向多个可用区和数据中心扩展

将所有 Roblox 后端服务运行在单一 Consul 集群上，使我们面临此类故障的风险。我们已为另一个地理位置独立的数据中心搭建了服务器和网络基础设施，该数据中心将托管我们的后端服务。我们正在推进将服务迁移至这些数据中心内多个可用区的计划；为此，我们已对工程路线图和人员配置计划进行了重大调整，以加速相关工作。

Consul 升级与分片

Roblox 仍在快速增长，因此即使拥有多个 Consul 集群，我们仍希望减轻 Consul 的负载。我们已审查了各项服务对 Consul 的 KV 存储和健康检查的使用情况，并将部分关键服务拆分到各自的专用集群中，从而将中央 Consul 集群的负载降低到更安全的水平。

尽管我们拥有其他可能更合适的存储系统，但部分 Roblox 核心服务仍直接将 Consul 的键值存储用作便捷的数据存储位置。我们正在将这些数据迁移至更合适的存储系统。迁移完成后，这也将减轻 Consul 的负载。

我们发现大量过时的键值对数据。删除这些过时数据后，Consul 的性能得到了提升。

我们正与 HashiCorp 紧密合作，部署新版 Consul，用名为 bbolt 的继任者取代 BoltDB，后者不存在自由列表无限增长的问题。我们特意将此工作推迟到新年，以避免在年底流量高峰期进行复杂的升级。升级目前正在测试中，将于第一季度完成。

引导流程与配置管理的改进

恢复服务的进程因多种因素而延缓，其中包括部署和预热 Roblox 服务所需的缓存。我们正在开发新的工具和流程，以使该过程更加自动化且更少出错。特别是，我们重新设计了缓存部署机制，以确保能够从零开始快速启动缓存系统。此项工作的实施正在进行中。

我们与 HashiCorp 合作，确定了若干 Nomad 增强功能，这些功能将使我们在长时间停机后更容易启动大型任务。这些增强功能将作为我们下一次 Nomad 升级的一部分进行部署，计划于本月下旬实施。

我们已开发并部署了用于加快机器配置变更的机制。

流式传输的重新引入

我们最初部署流式处理是为了降低 Consul 集群的 CPU 占用率和网络带宽。一旦新的实现方案在我们的规模和工作负载下经过测试，我们计划将其谨慎地重新引入系统。

关于公有云的说明

在经历此次服务中断后，大家自然会问：Roblox 是否会考虑迁移至公有云，并让第三方管理我们的基础计算、存储和网络服务？

Roblox 的另一项核心价值观是“着眼长远”，这一理念深刻影响着我们的决策。我们在本地构建并管理自己的基础架构，因为以我们目前的规模，更重要的是，考虑到平台未来将达到的规模，我们相信这是支持我们的业务和社区的最佳方式。 具体而言，通过自建并管理用于后端和网络边缘服务的数据中心，我们得以显著控制成本，相比使用公有云更具优势。这些节省下来的成本直接影响了我们能够支付给平台创作者的报酬。此外，拥有自有硬件并构建边缘基础设施，使我们能够最大限度地减少性能波动，并精细管理全球玩家的网络延迟。 对于玩家而言，稳定的性能和低延迟至关重要——毕竟他们未必位于公有云服务商数据中心的附近。

需要注意的是，我们并非固守某种特定方案：对于对玩家和开发者最有利的场景，我们仍会采用公有云。例如，我们利用公有云处理突发流量、大部分DevOps工作流以及绝大多数内部分析任务。 总体而言，我们认为公共云是处理非性能和延迟关键型应用的理想工具，尤其适用于规模有限的场景。然而，对于那些对性能和延迟要求极高的关键工作负载，我们选择在本地构建并管理自己的基础设施。做出这一决定时，我们深知这需要投入时间、资金和人才，但也确信这将使我们能够构建更优质的平台。这与我们“着眼长远”的核心价值观一脉相承。

停机事件后的系统稳定性

Roblox通常在12月底会迎来流量激增。虽然我们在可靠性方面仍有大量工作要做，但我们很高兴地报告：在12月的流量高峰期间，Roblox未发生任何重大生产事故，且Consul和Nomad在此期间的表现和稳定性均十分出色。看来我们近期在可靠性方面的改进已初见成效，随着长期项目的收尾，我们预计将取得更佳成果。

结语

我们要感谢全球 Roblox 社区的理解与支持。承担责任是 Roblox 的核心价值观之一，我们对此次事件承担全部责任。 我们愿再次向 HashiCorp 团队致以衷心的感谢。在此次史无前例的故障发生之初，他们的工程师便立即伸出援手，并始终与我们并肩作战。即便如今距离故障已过去两个月，Roblox 与 HashiCorp 的工程师仍保持着紧密合作，确保我们共同竭尽全力，防止类似故障再次发生。

最后，我们要感谢 Roblox 的同事们，正是你们印证了这里为何是如此美妙的工作场所。在 Roblox，我们信奉文明与尊重。当一切顺利时保持文明和尊重很容易，但真正的考验在于，当困难来临时我们如何对待彼此。 在长达73小时的停机期间，随着时间一分一秒流逝、压力与日俱增，若有人失态、说出不敬之言，或当众追问责任归属，这本不足为奇。但现实并非如此。 我们相互扶持，全天候团结一致，直至服务恢复正常。当然，我们并不为这次停机及其对社区造成的影响感到自豪，但我们为团队齐心协力让Roblox重获新生而自豪，也为在整个过程中始终以文明和尊重的态度对待彼此而自豪。

我们从这次经历中汲取了宝贵的经验，未来我们将比以往任何时候都更加致力于将Roblox打造为一个更强大、更可靠的平台。

再次感谢大家。