2022-07-18 事件更新

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

我们已经确定，这次中断是由 Deno Deploy 使用的服务发现系统故障引起的。这篇文章详细介绍了究竟发生了什么，以及我们正在采取哪些措施来防止将来再次发生。

所有服务现在已恢复正常运行。没有数据丢失。我们非常重视这类中断，并对由此造成的不便表示诚挚的歉意。

影响

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

事件时间线

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

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

UTC 时间约为 01:25，值班工程师确认了中断，并启动了高优先级事件。到 UTC 时间 01:30，我们有几个人在调查，并已确定中断是由 etcd 集群引起的。很快就被证实，etcd 集群因为无法扩展其内部数据库存储而脱机。重建集群被认为是恢复服务的最佳选择。

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

根本原因

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

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

下一步

这次事件，再加上最近发生的几次其他事件，凸显了我们的服务发现系统既是关键基础设施，又容易出现故障。我们已经开始着手开发更强大的服务发现解决方案来替代现有系统。

我们在恢复服务时遇到了一些障碍，包括密钥管理和不应相互依赖的服务之间的相互依赖。我们将在未来几天解决这些问题。

我们还一直在完善我们的运营程序和运行手册，并采用更好的内部工具来管理事件。这次事件突出了这些程序和文档中的一些差距，这些差距本可以使事件的升级和解决更加顺利。

我们非常重视这类中断 - 这就是 Deno Deploy 仍在测试阶段的原因。我们希望在未来几个月内宣布正式发布，这在一定程度上取决于解决这些关键差距。