Firebase 全球宕机事件复盘：Google 的故障管理为何失水准

大家好，我是Gergely，这是《务实工程师通讯》的免费特刊。在每一期中，我都从资深工程师和工程领导者的视角来报道大型科技公司和初创企业。今天，我们涵盖上周《The Pulse》中四个话题中的一个上周的The Pulse。完整订阅者已在七天前收到下面的文章。如果你是通过转发收到这封邮件，你可以在此订阅。

Firebase——由Google打造——本周遭遇了一次严重故障，其事件管理之糟糕令人震惊，与Google自身通常处理高严重性事件的方式大相径庭。

故障始于周二（9月29日）下午5:41（太平洋夏令时），当时使用Firebase SDK的iOS应用在首次打开时开始崩溃；所有启用了分析功能并使用Firebase SDK的iOS应用都受到了影响。受影响应用的开发者开了一个GitHub工单，因为别无他法。在工单上，“我也崩溃了！”的消息被反复提及。

下午6:51（太平洋夏令时）：确认。崩溃开始一小时十分钟后，Firebase团队的一名工程师确认他们已意识到这次故障。

目前尚不清楚Firebase团队是通过这个有100多条开发者评论的工单收到警报，还是Google自己的监控工具显示了问题。我两天前询问了Google/Firebase，尚未收到回复。

除了等待Google解决问题别无他法，于是梗图开始涌现：

其他人试图通过指出潜在问题来帮助Firebase团队。事实上，在Google工程师确认事件之前，一位外部开发者于太平洋夏令时下午6:37找到了根本原因；是一个零长度条目导致SDK崩溃：

由于标志是由后端下发的，出问题的变更是一个后端变更，最简单的解决方案是回滚，社区几乎是在恳求Google这样做：

以下是另一位开发者对事件的精辟总结：

下午7:24（太平洋夏令时）：开始回滚。事件发生一个半小时后，Firebase团队开始回滚有问题的后端变更：

下午8:16（太平洋夏令时）：回滚完成。回滚在大约50分钟后完成：

Firebase团队的软件工程师Nick Cooke发布了一份带有更准确时间戳的总结：

我们可以从中推断出：

• TTD（检测时间）：一小时？Firebase 团队从未透露他们花了多长时间才检测到几乎所有使用 Firebase 的 iOS 应用都开始崩溃。在 GitHub 工单上，他们在事件开始 70 分钟后才确认。 更新：在团队后来发布的复盘报告中，他们写道，团队在发布后 20 分钟就通过崩溃警报和 GitHub 问题收到了警报。不过，为什么又花了 50 分钟才确认问题，这是个好问题。
• TTM（缓解时间）：2-6 小时。推出修复程序花了 2 小时 11 分钟，但由于缓存（缓存了错误服务器响应的应用会继续使用该缓存额外四个小时，因此持续崩溃长达六个小时。）

事件管理基础

Firebase 团队自己用一份简短报告结束了这次故障，实际上就是说发生了故障，但现在已经解决了，所以感谢你的耐心，祝你愉快。

这种对高影响事件的处理方式绝对不是 Google 的典型做法，毕竟正是这家公司创造了“站点可靠性工程师”一词并撰写了 SRE 书籍。

首先，Firebase 从未费心更新其状态页面。奇怪的是，Firebase 官方状态页面显示所有系统均为绿色——尽管已确认发生故障。事实上，在故障期间及之后，他们都没有更新状态页面来表明这次长时间的故障：

但状态页面的存在是有充分理由的，包括：

1. 在故障期间和之后与客户沟通
2. 提供服务稳定性的透明度

值得一问：如果一次导致大多数（或全部？）使用 Firebase 的 iOS 应用崩溃的故障都不值得更新状态页面，那还有什么值得！

Google 四天后发布了复盘报告，解答了故障是如何发生的问题。10 月 2 日星期五，Google 在Firebase 博客上发布了一份复盘报告。是一次配置更改导致如此多 iOS 应用崩溃。复盘报告中写道：

“On September 28, 2026, a routine configuration cleanup unexpectedly caused a large number of iOS applications using the Google Analytics for Firebase (GA4F) SDK to crash.

2026‑09‑28 17:38 (PST)：清理了一个陈旧的遗留配置标志。
2026‑09‑28 17:41 (PST)：格式错误的配置负载开始在全球范围内向生产服务器推出。故障开始：获取新负载的客户端在启动时开始崩溃。

SDK 未能验证某个标志的名称不为 nil，最终导致崩溃。后端数据异常不应导致应用端崩溃。”

在复盘报告中，Google 指出，工程师是通过外部开发者提交的 GitHub 报告以及内部监控得知故障的。又花了一个小时才确定原因是遗留配置标志清理。

Firebase 表示他们无法为客户端故障更新状态页面。在复盘报告中，Google 解释说，他们的仪表板上没有地方可以标示客户端故障（强调为我所加）：

“Throughout the outage, both the Firebase and Google Ads status dashboards remained green. Because these dashboards rely primarily on server-side health metrics, they did not register client-side SDK crashes.

承诺：展望未来，我们正在积极努力：将 SDK 相关故障信息整合到我们的状态仪表板中，简化手动更新流程，并改善 Firebase 仪表板中 GA4F 状态的表现。”

很高兴看到 Google 没有完全放弃，并认识到他们的仪表板和事件管理流程都需要改进。

不过，问一句也合理：为什么只有 iOS 崩溃，而 Android 没有？ Firebase 的 Android SDK 似乎比 iOS 更健壮，因为移除功能标志并没有导致 Android 设备崩溃。

尤其是现在有了 AI，比以往任何时候都更容易比较 iOS 和 Android 的实现，以确保它们完全一致——这正是 Shopify 在原生重写期间所做的——这对 Google 来说，是不是一个错失的机会，去审计 iOS 和 Android SDK 之间的差异？对我来说，这里没有行动项感觉像是错失了一个机会。

不过，这对所有发布 iOS 和 Android 应用的人来说都是一个很好的提醒：要努力加固它们，并在可能的情况下用畸形负载运行测试，然后修复这些负载导致的崩溃。

似曾相识：2020 年 Facebook SDK 崩溃

上一次发生类似崩溃是在 2020 年，涉及 Facebook。 那年 5 月，Spotify、TikTok、Pinterest 等应用也突然开始崩溃，原因是 Facebook SDK 导致所有使用它的应用崩溃。当时，开发者们也在一个 GitHub 工单上跟进，他们也发现了那个 bug：一个本应是字典的值却成了布尔值：

当时和现在一样，开发者们被迫等待修复，也少不了调侃：

以及不要再“快速行动，打破东西”的请求：

对这种情况的轻松调侃：

还有对解决方案的期待：

最终，Facebook 回滚了后端更改，但这次分享的细节比 Google 这次的最低限度还要少。这就是我们对 2020 年那次中断所知道的全部，那次中断可以说比 Firebase 这次影响范围更广：

我想知道是否有些人认为面向公众的事件管理不再重要或有价值，即使是对面向开发者的产品也是如此。 Facebook/Meta 从未费心就他们的中断进行太多沟通，我并不感到震惊，因为开发工具不是那里的 DNA。

但就 Firebase 而言，我感到惊讶的是，一个多星期后，事后分析仍然没有显示在 Firebase 状态页面上。

也许这就是 Google“发布他们的组织架构图”的现场上演。 这次中断从技术上讲是由 Google Analytics（做出了功能标志更改）引起的，但责任在于 Firebase SDK（其 iOS SDK 不够健壮，无法处理这个新负载）。中断本身被埋在一个Google Ads 仪表板（！！）里，这表明被认为应对中断负责的团队属于 Google Ads 组织。

最终，尽管 Firebase 团队承诺“改善状态仪表盘的延迟和覆盖范围”，上周，这些团队并不急于开展这项工作。AI 智能体或许正在让许多工作变得更高效，但在 Google，跟进待办事项似乎仍像 AI 出现之前一样慢如蜗牛！

阅读本文出自的《The Pulse》完整一期，或查看本周的《The Pulse》。本周内容涵盖：

1. 新趋势：中型公司构建内部 vibe-coding 平台。Ramp 和 Stripe 为非工程师构建了用于搭建内部网站和工具的平台，两者在这些公司内部都迅速流行起来。我预计会有更多公司效仿。
2. 我们工程师真的喜欢难题吗？还是我们其实只是喜欢用后端问题做模式匹配？Cloudflare 工程师 Sunil Pai 的一篇颇具挑衅性的文章提出，背后还有其他动机。
3. 新的开放模型在欧盟和美国发布。Kolibri、Mistral Large 4 以及 Reflection 的 Beam 可能挑战中国在开放权重模型领域的主导地位。
4. 行业脉搏。为什么 Figma 不允许任何智能体使用其 MCP 服务器；Google Cloud 在服务端新增 Swift 支持；Anthropic 为期两周的冲刺以加速 Claude Code；Coinbase 在 Shopify 宣布之后不久便弃用 React Native；Claude Opus 5.5 格式化 C: 盘，等等。

订阅我的每周通讯，即可在收件箱中收到这样的文章。内容相当值得一读——而且是 Substack 上排名第一的软件工程通讯。