昨天的兔子CDN中断细节

如果Bunny.net有一个指标，我们痴迷于比性能多，那将是可靠性。我们具有多余的监控，在多个不同级别的自动愈合，三个冗余DNS网络和一个系统设计用于将所有这一切联系在一起并确保您的服务在线停留。

话虽如此，这变得更加困难。经过几乎恒星2年的正常运行时间，于6月22日，Bunny.net经历了2个以上的时间靠近System-宽的中断，由DNS失败引起。在眨眼间，我们损失了超过60％的流量，并淘汰了数百个吞吐量。尽管所有这些系统到位，但一个非常简单的更新将其崩溃，影响超过750.000个网站。

要说我们感到失望会是轻描淡写的，但我们希望借此机会学习，改进和建立更强大的平台。本着透明度的精神，我们也希望分享发生的事情以及我们＆＃39;重新做出解决这一目标。也许甚至帮助其他公司从我们的错误中吸取教训。

我会说这可能是一个常见的故事。这一切都始于常规更新。我们目前正在整个平台的大规模可靠性和性能改进过程，其中一部分正在提高我们的SmartEdge路由系统的性能。 SmartEdge利用了定期同步到我们DNS节点的大量数据。为此，我们利用我们的边缘存储平台，负责通过Bunny CDN分发世界各地的大型数据库文件。

为了减少内存，流量使用和垃圾收集器分配，我们最近将JSON转换为名为BinaryPack的二进制序列化库。几周后，生活很大，内存用法下来，GC等待时间下降，CPU使用率下降，直到它一切都倒了。

6月22日在UTC上午8:25，我们发布了一个新的更新，旨在减少优化数据库的下载大小。不幸的是，这可以将损坏的文件上传到边缘存储。没有问题本身，DNS旨在使用数据或没有数据工作，并且旨在慷慨地忽略任何异常。或者我们想到了。

拒绝，损坏的文件导致BinaryPack序列化库立即使用堆栈溢出异常执行自己，绕过任何异常处理并仅退出该过程。几分钟之内，我们的全球DNS服务器队靠近100台服务器实际上已经死亡。

我们花了一些时间实际上意识到正在发生的事情。 10分钟后，我们意识到DNS服务器正在重新启动和死亡，实际上没有办法将它们带回这种状态。

我们以为我们已经为此做好了准备。我们有能力立即回滚按钮中的任何部署。这是我们意识到的时候，事情比他们似乎更复杂。我们立即回滚了SmartEdge系统的所有更新，但它已经太晚了。

SmartEdge和Deployment Systems都使用依赖Edge Storage和Bunny CDN来将数据分发到实际的DNS服务器。另一方面，我们只是擦除了我们的大部分全球CDN容量。

虽然DNS自身自动治疗，但每次尝试回来时，它都会尝试加载破损的部署并再次崩溃。正如您可以想象的那样，这基本上阻止了DNS服务器到达CDN下载更新并继续在崩溃中。

正如您可以在8:35（15:35）所看到的那样，一些服务器仍在努力跟上请求，但它没有效果，我们将大部分交通放到100Gbit。

8:45我们想出了一个计划。我们手动部署了一个将SmartEdge系统禁用到DNS节点的更新。事情终于似乎正在工作。事实证明我们非常非常错。由于CDN故障，DNS服务器还结束了下载损坏的地理数据库版本，突然，所有请求都进入马德里。作为我们最小的流行音乐之一，它很快被删除了。

要使事情更糟糕，现在100个服务器在循环中重新启动，这开始崩溃我们的中央API，甚至我们能够带回的服务器现在无法正常启动。

我们花了一些时间来实现实际在多次尝试重新建立网络后的实际发生的事情，我们放弃了这个想法。

我们被困了。我们迫切需要尽快在线获取在线，但我们实际上设法用一个简单的损坏文件杀死整个平台。

由于我们的所有内部分配现在遭到损坏并通过CDN服务，我们必须找到替代方案。作为临时措施，在9:40左右，我们决定，如果我们向一个地区发送所有请求，我们也可以向我们最大的地区发送那些。我们准备了一个路由更新，通过法兰克福路由所有请求。

这是我们的第一个成功，而且交通的体面部分正在网上回来。但它不是一个解决方案。我们手动部署到几个DNS服务器，但船队的其余部分仍然向马德里发送一切，所以我们需要快速行动。

我们决定搞砸了大时间，唯一的途径是为了完全停止使用自己的系统。为此，我们去上班，煞费苦心地将所有部署系统和文件迁移到第三方云存储服务。

在10:15，我们终于准备好了。我们重新提供了我们的部署系统和DNS软件，以连接到新的存储和命中部署。交通缓慢但肯定会回来，在10:30，我们回到了比赛中。或者我们想到了。

当然，一切都在火上，当我们尽最大努力赶上这一点，同时也处理数百个支持门票，并使每个人都妥善了解，我们造成了一堆错字和错误。我们知道它在这些情况下保持冷静，但这比完成这更容易。

在我们急于获得此修复过程中，我们部署了一个错误的Geodns数据库版本，因此在我们重新建立DNS集群时，它们仍然向马德里发送请求。我们越来越沮丧，但是是时候冷静下来了，仔细检查一切并进行最终部署。

在10:45，我们做到了。现在将所有内容连接到第三方服务，我们设法同步数据库，部署最新文件集并在线获取内容。

我们煞费苦心地看着交通挑选30分钟，同时确保事情在线回来。我们的存储被推到了它的限制，因为没有SmartEdge系统，我们正在为许多未加工的数据提供服务。终于在11:00开始稳定的东西，Bunny.net在恢复模式下返回。

我们设计了我们所有的系统，共同努力，依赖于彼此，包括我们内部基础架构的关键作品。如果你建造一堆很酷的基础设施，你当地诱惑到尽可能多的系统中。

不幸的是，它允许一些像腐败的文件一样简单，以崩溃多层冗余，没有真正的方式让东西备份。它崩溃了我们的DNS，它崩溃了CDN，它崩溃了存储，最后，它崩溃了优化的服务。

事实上，涟漪效应甚至崩溃了我们的API，我们的仪表板作为数百个服务器被带回了，这反过来又会崩溃了伐木服务。

虽然我们相信这一点永远不会发生在第一个地方，但我们将其作为一种有价值的课程。我们绝对不完美，但我们正在尽力尽可能接近。展望未来，获得的唯一方法就是学习和改善我们的错误。

首先，我们想向任何受影响的人道歉，并安抚大家，我们以最大的紧迫性对待这一点。我们在没有广泛的系统范围内失败的情况下有很多多年的频率，我们决心确保不再发生这种情况。

为此，第一个和最小的步骤将逐步逐步淘汰BinaryPack库，并确保我们在未来工作的任何第三方图书馆运行更广泛的测试。

更大的问题也变得明显。在自己的生态系统内建立自己的基础设施可以有可怕的后果，可以像一组多米诺骨一样摔倒。亚马逊在过去证明了这一点，然后我们认为这是我们的妻子，哦，我们有多错了。

我们目前正计划将内部API的完整迁移到第三方独立服务。这意味着如果他们的系统下降，我们就会失去更新的能力，但如果我们的系统下降，我们将有能力快速且可靠地反应而不会陷入倒塌的基础设施。

最后，我们正在使DNS系统本身运行具有自动故障检测的所有备份数据的本地副本。这样我们就可以添加另一层冗余，并确保无论发生什么事，Bunny.net中的系统仍然可以尽可能彼此独立，并在出现问题时防止纹波效果。

我想对我的支持团队分享，因为我们努力让我们在循环中的所有人身上和我们所有的用户都在与我们联系到我们的态度。

我们理解这一直是一个非常紧张的局面，不仅对自己，而且特别是对我们所有人依靠我们留在网上的人，所以我们确保我们从这些活动中学习和改进，并比以往任何时候都更加可靠。