世界标准时间（UTC）5月30日（星期一）22:12，Deno 公司提供的多项服务发生了持续70分钟的服务中断。在此期间，Deno Deploy 上托管的项目（包括许多 Deno Land 网站）在某些区域无法响应；此外，尝试部署新 worker 也会失败。
我们得出结论，此次中断是由于我们的服务发现数据库 (etcd) 内存耗尽造成的。本文将详细说明具体发生了什么、我们如何恢复系统以及我们未来将采取哪些措施来防止此类事件再次发生。
所有服务现已恢复正常运行，未丢失任何数据。我们对这类中断事件高度重视，并对由此造成的不便深表歉意。
影响
在这70分钟内，Deno Deploy 管理控制台 https://dash.deno.com/ 无法访问。此外，对 Deno Deploy 项目（包括 deno.com、deno.land、doc.deno.land、lint.deno.land、deno.news、examples.deno.land）的请求在某些区域会失败。
除了在事件结束时出现了一些延迟增加外，子托管流量并未受到影响。
事件时间线
世界标准时间（UTC）22:12，Deno Deploy 整个网络启动了一项负载测试。一分钟后，即世界标准时间（UTC）22:13，负载测试成功结束。
世界标准时间（UTC）22:15，我们的正常运行时间监控系统检测到 Deno Deploy 托管的某些属性不可用并触发了警报。
世界标准时间（UTC）22:25，发现 etcd 集群已解体。多个实例陷入重启循环，因为 etcd 守护进程在启动后不久就耗尽了虚拟机（VM）上所有可用的 RAM，随后被 OOM killer 终止。
在世界标准时间（UTC）22:50 到 23:01 之间，etcd 集群被重新创建，并使用了具有更多内存的不同虚拟机（VM）实例大小。
世界标准时间（UTC）23:25，我们网络中的所有服务都已向新的 etcd 集群注册，系统再次正常运行。
根本原因
在负载测试期间，Deno Deploy 基础设施自动扩容以应对增加的负载。当负载测试结束后，基础设施又缩容。这触发了对作为我们服务发现数据库的 etcd 集群的大量更新。
在处理这些更新时，etcd 守护进程使用的内存超过了它们运行的虚拟机（VM）上的可用内存。这触发了 Linux OOM killer 终止 etcd 守护进程。由于多个 etcd 实例同时宕机，导致仲裁（quorum）丢失，服务发现数据库变得不可用。
下一步计划？
etcd 集群现在使用具有更多内存的不同虚拟机（VM）实例大小。
我们正在增加额外的 etcd 健康检查，并将设置警报，以便在 etcd 内存使用接近限制时通知我们。