在 UTC 时间 2020-02-20 21:28，我们收到一位 crates.io 用户的报告，称他们的 crate 在上传 10 分钟后仍未出现在索引中。这是 crates.io Web 应用中的一个错误，由 GitHub 中断导致。
中断的根本原因
在某些极端情况下，将新提交上传到索引的 GitHub 仓库的代码返回了成功状态，即使 push 操作本身失败了。该错误导致作业调度器认为上传实际上是成功的，从而将作业从队列中删除，并导致数据丢失。
中断是由该错误引起的，该错误在 GitHub 中断期间由于意外响应而触发。
解决方案
团队分析了将提交上传到索引的后台作业代码，并找到了报告错误成功的可能原因。一位团队成员编写了修复程序，另一位成员对其进行了审查，然后我们将补丁直接部署到生产环境。
与此同时，一旦看到索引再次开始更新，我们就手动删除了数据库中损坏的条目，并要求报告者再次上传他们的 crate。
受影响的 crate
kaze0.1.6wasmer-runtime-core0.14.0wasmer-win-exception-handler0.14.0
事后分析
部署更改所花费的时间比预期的要长得多：master 中有一些更改已经落地，但仍在等待部署到生产环境，这增加了构建过程的长度以及部署的风险。将来，我们应该通过从当前部署的提交中分支出分支，并在其之上 cherry-pick 修复程序来部署热修复。我们还应努力减少 PR 在 master 中等待而没有上线的时长。
由于此事件，没有人被呼叫，因为我们的监控和警报系统无法发现问题：我们对执行失败的作业进行了监控，但在这种情况下，作业被错误地标记为正确。我们应该实施定期检查，以确保数据库和索引正确同步。
我们很幸运，在中断期间，团队中有两位成员在线，他们可以访问支持电子邮件和生产环境：如果没有可用的呼叫，我们可能会比实际情况晚得多才注意到它。
在事件调查期间，我们还发现我们的日志记录不足以正确诊断问题：当提交被推送到索引时，或者当后台作业被执行时，没有记录任何消息。此外，用于发布新 crate 的 API 调用在其行中不包含 crate 名称。我们应该增强我们的日志记录功能，以便在未来事件中快速找到问题的根本原因。
事件时间线
从事件开始到部署修复程序花费了 1 小时 31 分钟。
2020-02-20
- UTC 时间 21:17：
kaze、wasmer-runtime-core和wasmer-win-exception-handler的作者将它们发布到 crates.io - UTC 时间 21:28：
wasmer-runtime-core和wasmer-win-exception-handler的作者向 [email protected] 报告问题 - UTC 时间 21:31：GitHub 更新其状态页面以报告中断
- UTC 时间 21:33：Pietro 注意到支持邮件，在 Discord 上 ping Sean，Sean 开始调查
- UTC 时间 21:35：Pietro 回复作者说团队正在调查
- UTC 时间 21:37：Sean 和 Pietro 找到了事件的症状
- UTC 时间 21:50：Sean 找到了该错误的可能原因
- UTC 时间 22:01：Sean 从数据库中删除受影响的版本
- UTC 时间 22:09：Sean 打开了包含修复程序的 PR 2207
- UTC 时间 22:16：GitHub 更新其状态页面，表示问题已修复
- UTC 时间 22:17：Pietro 要求对 PR 进行更改
- UTC 时间 22:20：Sean 在 PR 中解决了 Pietro 的担忧
- UTC 时间 22:23：PR 合并，Sean 将其直接部署到 master
- UTC 时间 22:48：修复程序部署到生产环境
2020-02-21
- UTC 时间 09:27：
kaze的作者向 [email protected] 报告他们的 crate 受到影响 - UTC 时间 12:55：Pietro 从数据库中删除
kaze的受影响版本，并回复 crate 的作者 - UTC 时间 14:10：Pietro 分析了 crates.io 数据库，发现没有其他 crate 受到影响