在 2022-10-28 的 01:52 UTC，rust-lang/cargo#11183 被合并到 Cargo master 分支。它引入了一个 bug，导致 Cargo 无法构建使用特定但非常常见的依赖设置的包。这个更改几乎进入了下一个 nightly 版本。如果它真的进入了，那么对于任何使用该 nightly 版本的用户来说，它将会导致依赖 serde_derive（crates.io 上最受欢迎的 crate 之一）的 3 万个 crate 都无法构建。

在此事件之后，Cargo 团队进行了事后分析，这对于具有（潜在的）广泛影响或其它重大影响的事件来说是合适的。这一次，我们遵循了一个特定的结构化事后分析模板，希望它能使最终的报告更全面、更有见地和更具可操作性，并且我们最终发现它使我们更好地理解了根本原因和失败/缺失的安全措施。因此，我们想与其他 Rust 团队分享我们的经验，以防他们发现部分或全部内容也很有用。

事后分析模板包含四个部分

• 发生了什么： 提供事件上下文的摘要，包括可用的指标或图表来阐明事件的影响。这应该包括对事件期间任何面向用户的冲击或体验的总结。
• 我们如何响应： 一个时间线，描述事件期间发生的所有事件，包括已知的具体日期/时间，以及以下四个问题的答案
  • 事件是如何被检测到的？
  • 如何改进检测时间？
  • 你们是如何到达知道如何减轻影响的程度的？
  • 如何改进缓解时间？
• 事件发生的原因： 这是最精彩的部分。在这里，我们使用五问法深入挖掘，直到确定事件的根本原因。每个答案都意味着产生一个或多个“为什么”问题，直到你确信左边的答案是根本原因。还需要明确指出的是，“操作员错误”绝不是根本原因，并且这不是一个分配责任的过程。相反，任何操作员错误都是缺失或损坏的机制的症状，答案应该侧重于识别那些不足的机制。
• 如何修复它： 五问法的结果是一系列根本原因，应该解决这些根本原因以减少未来发生类似事件的风险。从这些根本原因中，我们制定短期和中期“行动项目”，并尽可能指定具体的负责人。也可以讨论长期解决方案，尽管行动项目的重点应该是更直接的缓解步骤，这些步骤将在相对较短的时间内采取。每个行动项目都被分配一个优先级，然后通常转化为 GitHub 问题（如果适用）。任何被确定为紧急的项目我们都会立即开始处理，而其他行动项目通常属于“尽快”或“一旦可行”的类别。

注意：为了确保重点放在机制和流程上，而不是个人，除非绝对必要，否则不应提及个人姓名。使用诸如“贡献者”、“维护者”、“libs 团队成员”之类的术语。

那么，事不宜迟，这里是上述 Cargo 事件的事后分析。