2022-07-18 事件更新

从 7 月 18 日 01:20 UTC 开始，所有 Deno Deploy 服务（包括子托管）均遇到服务中断，持续到大约 02:25 UTC（65 分钟）。在此期间，用户无法访问托管在 Deno Deploy 上的项目，访问 Deno Web 属性（如 deno.com），或下载托管在 deno.land 上的模块。此外，子托管客户在此期间也无法在 Deno Deploy 上运行工作负载。

我们已得出结论，此次中断是由 Deno Deploy 使用的服务发现系统故障引起的。这篇文章详细介绍了具体发生的情况，以及我们正在采取哪些措施来防止将来再次发生这种情况。

所有服务现已恢复正常运行。没有数据丢失。我们严肃对待此类中断，并对由此造成的中断深感抱歉。

影响

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

事件时间线

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

大约 01:20 UTC，我们收到内部警报，表明基于 Deploy 的部署和 Web 属性不可用。

大约 01:25 UTC，值班工程师确认了中断，并提出了高优先级事件。到 01:30 UTC，我们有多人正在调查，并已确定中断是由 etcd 集群引起的。很快确认 etcd 集群由于无法增加其内部数据库存储而离线。重建集群被认为是恢复服务的最佳选择。

大约 02:00 UTC，尝试重建集群，在此期间遇到了一些挑战。集群已成功重建，服务于大约 02:25 UTC 开始恢复在线。

根本原因

根本原因是 etcd 实例达到了其存储配额限制。它们运行所在的 VM 有充足的磁盘空间可用 - 问题是 etcd 具有 2GB 的默认存储配额限制。

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

下一步是什么？

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

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

我们还在不断完善我们的操作程序和运行手册，并采用更好的内部工具来管理事件。此事件突显了这些程序和文档中的一些差距，这些差距本可以使事件的升级和解决得到改善。

我们非常重视此类中断 - 这就是 Deno Deploy 仍处于 Beta 版的原因。我们希望在未来几个月内宣布正式发布 (GA)，部分取决于修复这些关键缺陷。