编者注：太平洋时间 7 月 12 日下午 1:52 – 更新了 Balrog 更新频率并添加了一些背景信息。

正如我在之前的帖子中提到的，我们一直在对附加组件中断进行事后分析。很抱歉这件事花了这么长时间才发布；我们希望在一周内发布，但显然没有实现。需要挖掘的信息比我们预期的要多得多。无论如何，我们现在准备好分享结果了。这篇文章提供了我们发现的高级概述，更多详细信息可在Sheila Mooney 的事件报告和Matt Miller 和 Peter Saint-Andre 的技术报告中找到。

根本原因分析

每个人首先都会问的问题是“你们怎么会让这种情况发生？”从高层次来看，故事似乎很简单：我们让证书过期了。这看起来像是简单的计划失误，但经过进一步调查，事实证明情况更复杂：负责生成签名的系统的团队知道证书即将过期，但错误地认为 Firefox 会忽略过期日期。这种误解的部分原因是在之前的事件中我们禁用了终端实体证书检查，这导致对中间证书检查状态感到困惑。此外，Firefox 的 QA 计划没有包含对证书过期进行测试（或对浏览器在未来日期的行为进行通用测试），因此问题没有被发现。这似乎是我们测试计划中的一个根本性疏忽。

这里的教训是：（1）我们需要更好地沟通和记录系统的这些部分，以及（2）这些信息需要反馈到我们的工程和 QA 工作中，以确保我们没有遗漏任何东西。技术报告提供了更多详细信息。

代码交付

正如我之前提到的，一旦我们有了修复程序，我们就决定通过 Studies 系统（这是我们内部称为“Normandy”的系统的一部分）来交付它。对于这种类型的部署，Studies 系统并不是一个显而易见的选择，因为它旨在部署实验，而不是代码修复。此外，由于 Studies 权限与遥测相关联，这意味着某些用户需要启用遥测才能获得修复，导致 Mozilla 暂时过度收集我们实际上并不需要的数据，然后我们不得不清理这些数据。

这引出了一个自然的问题：“难道没有其他方法可以部署修复程序吗？”答案是“某种程度上可以”。我们用于向用户部署新代码的其他主要机制是点版本和一个名为“Balrog”的系统。不幸的是，这两个机制都比 Normandy 慢：Balrog 每 12 小时检查一次更新（尽管似乎对这个数字是 12 还是 24 有些困惑），而 Normandy 每 6 小时检查一次。因为我们有很多用户受到影响，修复他们是一个非常高的优先级，这使得 Studies 成为最佳的技术选择。

这里的教训是，我们需要一个允许快速更新且不与遥测和 Studies 耦合的机制。我们想要的功能是能够快速将更新部署到任何启用了自动更新的用户。我们的工程师已经在着手解决这个问题了。

不完整的修复

在事件发生后的几周内，我们发布了大量修复程序，包括八个版本的系统附加组件和六个点版本。在某些情况下，这是必要的，因为旧的部署目标需要单独的修复。在其他情况下，这是由于早期修复中的缺陷导致的，然后我们在后续工作中对其进行了修补。当然，软件中的缺陷无法完全消除，但技术报告发现，至少在某些情况下，高度的紧迫性加上缺乏可用的 QA 资源（或至少围绕 QA 的协调问题）导致测试的彻底性不如我们希望的那样。

这里的教训是，在发生此类事件期间，我们需要确保我们不仅要招募管理、工程和运营人员（我们已经这样做了），还要确保我们有 QA 可用于测试不可避免的修复程序。

了解更多信息的地方

如果您想详细了解我们的发现，我邀请您阅读我们编写的更详细的报告。与往常一样，如果这些报告没有回答您的问题，请随时发送电子邮件至 ekr-blog@mozilla.com。