7月13日犹他州服务中断更新

自世界标准时间（UTC）7月13日（星期三）18:00左右开始，Deno 公司提供的多项服务在犹他州（us-west3）经历了区域性服务中断，持续了24小时多。在此期间，犹他州地区的用户在访问 Deno Deploy 上托管的项目时遇到故障，其中包括许多 Deno 自己的网站。

我们得出结论，此次服务中断是由我们的负载均衡服务引起的。本文将详细说明具体情况，以及我们未来将采取哪些措施来防止此类事件再次发生。

在尝试恢复 us-west3 区域的服务后，7月15日世界标准时间15:30至16:00之间也发生了一次较短的服务中断。新创建的负载均衡器正常工作了几个小时，但最终遇到了同样的问题。在此期间，Deno Deploy 上托管的项目（包括许多 Deno 自己的网站）在该区域均无法访问。

目前所有服务均已恢复正常运行。没有数据丢失。我们非常重视此类服务中断，并对由此造成的不便深表歉意。

影响

在大约24小时内，us-west3 区域的部分用户无法访问 dash.deno.com 和 Deno Deploy 项目，包括 deno.com 和 deno.land。该区域位于犹他州，为周边地区（包括一些邻近州）提供服务。在第二次事件中，影响相同，但持续时间短得多；不到30分钟。

只有 us-west3 区域受到影响。在整个事件期间，所有其他区域均正常运行。此外，子托管服务未受影响。

事件时间线

7月13日世界标准时间18:45左右，我们开始收到少量用户关于服务中断的报告。我们调查了服务的状态，但无法证实任何报告。我们所有的状态监控和测试都显示一切正常运行。

在服务中断期间，我们持续监控服务状态，并与部分受影响用户合作，以缩小问题来源的范围。

7月14日世界标准时间19:14，我们确认问题出在我们的 us-west3 区域，随后我们将其下线，并将流量导向其他附近的区域。

7月15日世界标准时间11:30，我们尝试使用新的负载均衡器实例将该区域恢复上线。

7月15日世界标准时间16:00，负载均衡器再次进入了与之前相同的故障状态，我们再次禁用了该区域。该区域将保持禁用状态，直到我们的监控系统得到改进并且问题得到更永久的解决。

根本原因

进入 Deno Deploy 网络的最终用户请求会经过多个负载均衡器，最终到达能够执行 JavaScript 代码以响应请求的服务。

负载均衡器和后端服务的不同层级使用 etcd 来执行服务发现。当服务的可用性状态发生变化时，它们会向 etcd 集群通告自己。其他服务（如这些负载均衡器）从 etcd 获取健康后端服务的列表。它们还会 监视 已通告的服务列表，以便在给定服务变为可用或下线时获得通知。负载均衡器随后使用此列表来决定将流量路由到哪些后端服务。

在本次服务中断期间，其中一个区域性负载均衡器在应用程序未察觉的情况下断开了与 etcd 的连接。我们预计这种连接会因网络故障、超时等原因而定期断开。因此，应用程序被编程为自动重新连接，如果失败则自行关闭。

没有此连接，负载均衡器无法从 etcd 接收更新。这导致它与系统其余部分“不同步”，并且不知道有任何健康的后端可以导流。

负载均衡器没有健康的后端服务的情况并不少见，因此负载均衡器知道如何处理这种情况。如果没有健康的后端，它将从网络中取消通告自己，以防止请求到达这个“死胡同”。

由于负载均衡器的一个设计疏忽，在这种特定情况下它没有从系统中取消通告自己。这导致负载均衡器继续接收来自上游负载均衡器的流量，但却没有地方可以导流。这导致流量完全被丢弃。

后续计划？

此次事件清楚地表明，我们的监控系统存在一些盲点。我们正在研究如何减少这些盲点，并改进各个区域的监控能力。

此外，我们很难确定是哪个区域导致了服务中断，因为发生故障的负载均衡器位于网络堆栈的非常早期阶段（一个 TCP 负载均衡器）。它不记录任何关于连接丢弃的诊断信息，也没有返回通道向用户返回诊断信息（与可以返回响应头的 HTTP 负载均衡器不同）。我们正在努力改善这一环节的监控状况。

我们目前还在对负载均衡系统进行一些架构改进，以完全防止此类故障的发生。