UTC 时间 2022 年 10 月 28 日 01:52，rust-lang/cargo#11183 被合入 Cargo 的 master 分支。它引入了一个 bug，导致 Cargo 无法构建使用特定（但非常常见）依赖项设置的软件包。这个改动差点进入下一个 nightly 版本。如果它进入了 nightly 版本，那么对于使用该 nightly 版本的任何用户来说，任何依赖了 serde_derive（这是 crates.io 上最流行的 crate 之一）的 3 万个 crate 都将无法构建。

在此事件发生后，Cargo 团队进行了事后分析，这对于影响范围广泛或具有重大影响的事件来说是适当的。这一次，我们遵循了一个特定的结构化事后分析模板，希望它能使最终的分析报告更全面、更有洞察力、更具操作性。我们最终发现，这让我们更好地理解了潜在的根本原因以及失效/缺失的安全措施。因此，我们希望与其他 Rust 团队分享我们的经验，以防他们也觉得它有用，无论是部分还是全部。

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

• 发生了什么： 对事件的总结，提供事件的背景信息，如果可用，还包括说明事件影响的指标或图表。这应该包括对事件发生期间任何用户端影响或体验的总结。
• 我们如何应对： 一个时间线，描述事件发生期间发生的所有事件，包括已知范围内的具体日期/时间，以及以下四个问题的答案
  • 事件是如何被检测到的？
  • 如何缩短检测时间？
  • 你们是如何确定减轻影响的方法的？
  • 如何缩短减轻影响的时间？
• 为什么会发生： 这是关键部分。在这里，我们使用五问法深入挖掘，直到找出事件的根本原因。每个答案都应该引发一个或多个“为什么”的问题，直到你确信剩下的答案是根本原因为止。还需要明确指出的是，“操作员错误”绝不是根本原因，这也不是一个追究责任的过程。相反，任何操作员错误都是某种缺失或失效机制的表现，答案应该侧重于识别那些不足的机制。
• 如何解决： 五问法的练习结果是一个根本原因列表，应加以解决以降低未来发生类似事件的风险。根据这些根本原因，我们制定了短期和中期的“行动项”，并在可能的情况下指明了具体的负责人。也可以讨论长期解决方案，尽管行动项的重点应放在相对较快实施的更紧急的缓解措施上。每个行动项都被赋予一个优先级，然后通常会转化为一个 GitHub Issue（如果适用）。任何被确定为紧急的行动项我们立即开始处理，而其他行动项通常属于“近期”或“可行时”类别。

注意：为确保焦点放在机制和流程上，而不是个人，除非绝对必要，否则不应提及个人的名字。使用诸如“某位贡献者”、“维护者”、“libs 团队成员”等称谓。

言归正传，以下是上述 Cargo 事件的事后分析。