上星期二我们在纽约的第二个星期二发生了一起事件。这是我们不能接受的，我想亲自向每一个受影响。在DigitalOcean，我们的一个核心信念是，我们的客户应该得到尽可能多的透明度。当我们遇到问题的时候和事情进展顺利时，这同样适用。考虑到这一点，我们想分享一些事件的细节和回应。我们的网络设计有一对核心交换机，每个服务器机架都与之相连。这些核心交换机还相互连接并相互协调，以允许通过两个核心到每个服务器机架的单个绑定逻辑连接。我们在每个核心交换机上始终有足够的可用容量来处理我们的所有流量，以便我们可以继续正常运行，如果任何一个核心交换机失败。在除了拥有完全冗余的核心交换机，我们还在每个核心交换机中都有冗余的路由引擎。路由引擎本质上是交换机的大脑-它处理管理功能和一些更高级的网络协议。这种冗余旨在允许我们继续使用核心交换机冗余进行操作，即使我们的两个核心中有一个路由引擎出现故障打开。打开美国东部时间7月29日星期二13:09，主动路由引擎中的固态磁盘在我们的一个核心交换机上发生故障。这触发了到备份路由引擎的故障转移，但是故障转移没有完全成功。因此，两个核心交换机之间为向服务器机架提供单个绑定链路所需的协调处于不一致状态。这反过来又导致我们网络的一部分无法访问。我们立即发现了发生故障的路由引擎，但是我们花了将近一个小时才完全理解故障转移没有成功完成。一旦我们发现了这一点，我们就决定将断开的核心交换机与网络完全隔离，将所有流量转移到剩余的核心开关。那个最近发现核心交换机上的软件存在问题，这阻碍了恢复工作，我们认为，如果我们移动所有交换机，则可能会导致其余交换机出现问题我们的交通。因为我们刚刚在预生产环境中完成了对新版本软件的鉴定，所以我们决定在隔离出现故障的核心交换机之前将更新应用于未受影响的核心交换机。这增加了大约15分钟的恢复时间，但最终使我们处于一个稳定的位置，可以继续运行，直到我们可以对受影响的设备进行必要的维修切换。我们从星期二开始，我们就日以继夜地工作，以便更好地了解发生的故障，使网络恢复到完全冗余的状态，并对我们的配置和标准操作程序进行更改，以提高我们对未来。第一，我们修复了损坏的核心交换机，并成功地将其恢复到生产，恢复了核心交换机冗余。这项工作在周三晚上顺利完成。当我们将来看到部分网络出现类似的无法解释的流量损失时，我们还决定将单核交换机与网络隔离开来，这是一个标准的故障排除程序。这将使我们能够对这类问题做出快速反应向前。就像周三晚上，网络已经恢复到原来的配置，所有设备都是完全冗余的，功能正常。我们预计目前不会再发生任何问题。我们相信我们的纽约2区稳定了。我们正在与我们的网络合作伙伴密切合作，以了解故障的性质，评估重复事件的可能性，并开始为未来。我们的最初的重点是验证配置，因此我们启动了逐行配置由我们的网络合作伙伴的工程师进行审查，以确认我们的架构具有最佳的设置。除了验证设置之外，我们还要求他们在实验室中测试此配置，以确保它在我们当前的硬件配置和软件版本上按预期执行运行中并行地，我们返回了损坏的路由引擎以进行完整的故障分析，我们希望得到关于这两者的更明确的答案失败的原因以及备份路由引擎无法成功接管的原因。我们期待着在接下来的几天里对此有一些初步的发现天。终于，我们已安排与网络合作伙伴的首席架构师进行全面的网络审查，以确定可以使我们的网络更加稳定的短期战术变化，以及支持我们向前发展的长期架构变化。我们将在下周早些时候审查这些建议，并决定如何继续。我们你要知道你依赖我们一直在线。我们感谢您的耐心和持续的支持。我们会尽一切努力确保你的信任放置好了。谢谢你，Ben Uretsky数字海洋首席执行官