2022-07-18 事件更新

从世界协调时7月18日01:20开始，所有Deno Deploy服务（包括子托管）经历了服务中断，直到大约02:25 UTC（65分钟）。在此期间，用户无法访问托管在Deno Deploy上的项目，无法访问deno.com等Deno网站属性，也无法下载托管在deno.land上的模块。此外，子托管客户在此期间也无法在Deno Deploy上运行工作负载。

我们已得出结论，此次中断是由Deno Deploy使用的服务发现系统故障引起的。本文将详细说明具体发生了什么，以及我们未来将采取哪些措施来防止此类事件再次发生。

所有服务现已恢复正常运行。没有数据丢失。我们非常重视此类中断事件，并对此次中断给您带来的不便深表歉意。

影响

在长达65分钟的时间里，用户无法访问Deno Deploy上的大多数Deno网站属性和部署，其中包括deno.com和deno.land。所有Deno Deploy子托管部署均无法访问。

事件时间线

世界协调时7月18日大约00:51，我们的etcd集群开始记录数据库空间不足的问题。此服务用于Deploy的服务发现，允许服务之间相互协调和发现。

大约在世界协调时01:20，我们收到了内部警报，称基于Deploy的部署和网站属性均不可用。

大约在世界协调时01:25，值班工程师确认了中断，并启动了一个高优先级事件。到世界协调时01:30，我们已有数名人员进行调查，并确认中断是由etcd集群引起的。很快就确认，etcd集群因其内部数据库存储无法扩展而离线。重建集群被认为是恢复服务的最佳选择。

大约在世界协调时02:00，我们尝试重建集群，在此过程中遇到了若干挑战。集群成功重建，服务于大约世界协调时02:25开始恢复在线。

根本原因

根本原因是etcd实例达到了其存储配额限制。它们运行的虚拟机有足够的可用磁盘空间——问题在于etcd有一个2GB的默认存储配额限制。

Deploy使用etcd进行服务发现。在etcd不可用一段时间后，内部Deploy负载均衡器不知道如何将请求发送到何处进行隔离执行。

接下来是什么？

此次事件以及近期其他事件都突出表明，我们的服务发现系统既是关键基础设施，又容易出现故障。我们已经开始着手开发一个更强大的服务发现解决方案，以取代现有系统。

在服务恢复过程中，我们遇到了若干障碍，包括密钥管理以及不应相互依赖的服务之间的共同依赖性。我们将在未来几天解决这些问题。

我们还在完善我们的操作规程和运行手册，并采用更好的内部工具来管理事件。此次事件突显了这些规程和文档中的一些不足之处，如果加以改进，将能更好地升级和解决事件。

我们非常重视此类中断——这也是Deno Deploy仍处于测试阶段的原因。我们希望在未来几个月内宣布正式发布，这部分取决于修复这些关键缺陷。