在 2023-01-25 星期三的 09:15 UTC，我们为 crates.io 部署了生产环境的变更。在部署期间，static.crates.io 的 DNS 记录在大约 10-15 分钟内无法解析。用户在此期间经历了构建失败，因为无法下载 crate 包。大约在 9:30 UTC，DNS 记录开始再次传播，到 9:40 UTC，流量已恢复正常水平。

中断的根本原因

Rust 基础设施使用 Terraform 进行管理，这是一个用于配置和部署基础设施即代码的工具。基础设施团队最近对此配置进行了更改，以分离 crates.io 的 staging 和 production 环境，以便两者可以彼此独立部署。

此功能用于在 staging 环境中开发和测试 static.crates.io 的第二个内容分发网络 (CDN) 的基础设施。当配置准备就绪后，我们安排并宣布了 1 月 25 日的推出。

部署到 production 环境包含了两个更改，这两个更改在 staging 环境中单独开发、部署和测试：当前内容分发网络的新 TLS 证书和更新的 DNS 记录。

当我们把这个配置部署到 production 环境时，Terraform 首先删除了当前的证书和 DNS 记录。然后开始颁发新的证书，这大约花费了 10 分钟。在此期间，没有 static.crates.io 的 DNS 记录，用户经历了构建失败。在新证书配置完成后，Terraform 重新创建了 DNS 记录。

解决方案

在 Terraform 完成部署并为 static.crates.io 创建新的 DNS 记录后，中断自行解决。对于某些用户，由于其 DNS 服务器中的缓存，中断持续了几分钟。

事后分析

通过单独部署对 TLS 证书和 DNS 记录的更改，可以避免中断。我们已经确定了为什么没有这样做的两个原因以及我们从中吸取的教训。

这是我们首次使用围绕环境的新工具来将更改部署到 production 环境。它的一个特点是 production 环境被锁定到特定的 Git 提交。在过去部署时，我们将其设置为 master 分支上的最新提交。这里也同样如此，结果是部署同时应用了多个更改。

另一种看待这个问题的方式是，production 和 staging 随着时间的推移差异过大，因为我们在将更改合并到主分支时没有部署它们。如果我们在将更改合并到主分支时就部署了这些更改，我们将隔离 DNS 更改。但考虑到 crates.io 对 Rust 生态系统的重要性，我们犹豫是否在没有事先向社区宣布更改的情况下多次部署。

我们从这次事件中吸取的教训如下：

• 我们需要记录将更改部署到生产环境的过程，特别是如何选择 Git 提交以及如何审查变更集。定义一个流程将使我们能够迭代并随着时间的推移改进它，并避免将来出现相同的问题。
• 在 staging 环境中单独开发和测试的更改应单独且按顺序部署到 production 环境。我们需要将其添加到文档中。
• 当我们将更改合并到主分支时，我们需要确保它们也部署到 production 环境。这避免了 Git 中的配置与已部署的配置之间的偏差。