在 2019-10-21 01:38 UTC，docs.rs 网站因托管该应用的服务器磁盘空间耗尽而宕机。由于相同的原因，Crate 构建从 2019-10-20 00:55 UTC 开始失败。

中断的根本原因

docs.rs 需要在将构建的文档上传到数据库之前将其存储在文件系统中，它是在 /opt/docs-rs-prefix/documentations 目录中进行存储的。然而，docs.rs 从未清理过该目录，因此随着时间的推移，它的大小开始增加，直到导致这次中断。虽然存在定期清除临时目录的代码，但从未配置为清除导致这次中断的目录。

解决方案

由于该目录不包含任何持久性数据，我们清空了该目录并重启了 Web 服务器。当我们确信问题已解决后，所有因中断而失败的 crate 都被重新排队进行构建。

事后分析

磁盘使用量的增加是数周内逐渐发生的，缓慢达到 100% 并导致了中断。尽管监控系统已到位并记录了增长图，但未配置任何警报，因此没有人注意到该问题。我们需要在磁盘使用率达到 90% 时添加警报，以便及时调查并处理该问题。

Crate 在一天前开始构建失败，从那时起几乎没有构建成功完成。我们需要在大多数构建失败时设置警报：由于目前我们没有必要的指标来可靠地发出警报，我们还必须添加额外的检测功能。

由于我们服务的轮值响应方面的问题，我们的响应速度较慢。主要联系人没有提升实例磁盘空间所需的访问级别（这是最初调查的临时修复方案，但在发现没有人能够进行操作后被放弃），而备用联系人没有任何生产访问权限或对 docs.rs 的专业知识。

事件时间线

除非另有说明，所有事件均发生在 2019-10-21，所有时间均为 UTC。

• 2019-10-20 00:55: 由于磁盘空间不足，crate 构建开始失败
• 01:38: docs.rs 网站宕机的警报触发，ashleygwilliams（备用联系人）收到通知
• 01:39: QuietMisdreavus 加入了运维频道
• 01:39: QuietMisdreavus 发现了中断的原因（根分区已满）
• 01:52: ashleygwilliams 提议增加磁盘空间，但没有获得所需权限的人员处于清醒状态或可用的状态
• 01:56: ashleygwilliams 联系了 Mark-Simulacrum，他拥有增加磁盘空间所需的访问权限
• 01:57: QuietMisdreavus 找到了占用所有磁盘空间的目录
• 02:00: QuietMisdreavus 删除了占用所有磁盘空间的目录
• 02:03: QuietMisdreavus 重启了 Web 服务器
• 02:06: CDN 传播了更改，docs.rs 恢复在线
• 02:06: Mark-Simulacrum 加入了运维频道
• 08:19: pietroalbini 将中断期间失败的构建重新添加到队列中
• 19:27: 中断期间失败的 crate 构建完成

行动项

• 更新 docs.rs 源代码以自动清理有问题的目录。
• 当服务器上的可用磁盘空间低于 10% 时添加警报。
• 当大多数构建失败时添加警报。
• 重新审视轮值响应，以确保其中的每个人都拥有对事件做出反应或升级的权限。