7月27日事件更新

在星期二 UTC 时间 14:18，Deno 组织提供的多项服务发生了 6 分钟的服务中断。在此期间，托管在 Deno Deploy 和 deno.land 网站上的项目均无响应。我们已得出结论，此次中断是由于数据库迁移与 Deno Deploy 中的各种内部服务失去同步所致。这篇文章详细介绍了具体发生了什么、我们如何恢复系统以及我们正在采取哪些措施来防止将来再次发生这种情况。

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

事件时间线

UTC 时间 14:18，启动了一次典型的软件部署。

UTC 时间 14:20，自动警报触发，指示对 deno.land/std 的请求失败。

UTC 时间 14:21，我们通过将流量重定向到我们的备用 Cloudflare Workers 恢复了 deno.land 网站的服务。此时，Deno Deploy 上运行的其他部署仍然无法访问。

UTC 时间 14:24，Deno Deploy 项目的服务已恢复。

根本原因

问题是由我们的数据库模式更改引起的，其中一列被删除并被另一列替换。同时，为了使用新列的代码更改也已推出。

修改 Deno Deploy 基础设施不是原子操作。在数据库更新应用期间，许多运行引用旧列代码的实例仍然在线。这些实例定期轮询修改后的表，但由于预期的列已丢失，它们开始崩溃。

随着更新在接下来的几分钟内进行，所有运行旧代码的实例都被替换，从而恢复了服务。

影响

在这 6 分钟内，对 Deno Deploy 项目的请求失败，包括对 deno.land/x 和 deno.land/std 的请求。尝试从 /x 或 /std 下载模块的 Deno 程序也遇到了故障。

下一步是什么？

这个问题本应在首次部署到 staging 环境时就被发现。我们看到 staging 日志中存在故障，但这些故障并未导致测试失败或警报。我们添加了新的 staging 警报，以便在未来捕获此类故障。