+− THE DAILY DIFFdev & AI news
探索主题

软件故障与事后分析

研究中断背后的部署、基础设施故障和工程决策。这些剧集解释了故障机制、恢复决策以及事件来源支持的经验教训。

postmortem · zh-CN · 2026年9月22日

一次重启让Telstra回到了2006年。九百万部手机受到影响。

墨尔本的一名工程师在凌晨2:50重新启动了一个时序机箱,到早餐时间,澳大利亚最大的移动网络竟然认为现在是2006年11月。2026年7月8日:Telstra的NTP机箱中的一张GPS卡在电源维修期间重启,其固件从未进行过GPS周翻转更新,因此它选择了旧的纪元,回到了1024周之前。由于2025年10月的一个权宜之计,这张卡成为了网络中唯一的层级1(stratum-1)时间源——并且2020年切换到

3:15 ↗
postmortem · zh-CN · 2026年9月19日

Google Cloud 因空白字段而崩溃。历时三小时。

一个包含几个空白字段的策略行触发了一个空指针,导致 Google Cloud 所有区域同时崩溃,随后 Cloudflare 也随之瘫痪。2025 年 6 月 12 日,世界标准时间 17:49:Service Control(批准每个 Google Cloud API 请求的二进制文件)读取了一个配额策略变更,其中包含“意外的空白字段”,触发了两周前发布的代码路径(没有空检查和功能标志),并进入了

2:57 ↗
postmortem · zh-CN · 2026年9月16日

Facebook 从互联网上删除了自己。六小时。

Facebook 从互联网上移除了自己的地址,当其工程师赶到现场恢复服务时,门禁读卡器也失灵了,因为它们也在 Facebook 上运行。2021 年 10 月 4 日,世界标准时间 15:40:一条例行的骨干网维护命令导致 Facebook 数据中心之间的所有链接中断;用于阻止该命令的审计工具存在一个错误;Facebook 的域名服务器,由于无法访问数据中心,根据设计撤回了它们自己的 BGP 路由

3:01 ↗
postmortem · zh-CN · 2026年9月14日

一个多余的字段导致850万台电脑崩溃。78分钟。

2024年7月19日,世界协调时04:09:CrowdStrike向所有在线的Windows Falcon传感器推送了Channel File 291——一个快速响应内容更新。它所输入的模板在2月份声明了21个输入字段;而提供输入的代码构建了一个包含20个字段的数组。四个月以来,没有任何东西读取字段21,因为每个规则都将其留作通配符。这次更新在那里放了一个真实的模式。云端的Content Vali

2:52 ↗
postmortem · zh-CN · 2026年9月13日

十一行 JavaScript 代码搞垮了互联网。一次取消发布。

2016年3月22日,世界协调时21:30:一位开发者在npm将包名“kik”交给即时通讯应用Kik后,取消发布了他所有的273个npm包,Kik的专利代理人曾威胁要“让律师上门找你”。这273个包中有一个是left-pad:十一行代码,用于在字符串前面添加空格,每月下载量达250万次。几分钟之内,Babel、React和Node的构建在全球范围内失败,每分钟数百次。十分钟内出现了一个分支,但没有

2:52 ↗
postmortem · zh-CN · 2026年9月12日

一个正则表达式搞垮了 Cloudflare,持续 27 分钟。

2019 年 7 月 2 日,UTC 时间 13:42:Cloudflare Web 应用程序防火墙的一条新规则在大约两秒钟内在全球 180 多个城市生效。这是一条模拟模式下的 XSS 规则,因此它不会阻止任何内容,但它仍然在每个请求上运行,并且以 .*(?:.*=.*) 结尾。PCRE 回溯,每个处理 HTTP 请求的 CPU 核心都达到 100%,每个由 Cloudflare 代理的网站都在

3:00 ↗
postmortem · zh-CN · 2026年9月11日

向8台服务器中的7台部署导致4.6亿美元损失。45分钟。

美国东部时间2012年8月1日上午9:30:骑士资本(Knight Capital),作为美国股票交易量约十分之一的市场做市商,刚刚向其八台SMARS服务器中的七台部署了新的订单路由代码。第八台服务器仍然运行2003年退役的“Power Peg”代码,新功能重用了这个代码背后的标志。在45分钟内,它发送了永不停歇的子订单:400万次执行,3.97亿股,约70亿美元的头寸,造成4.6亿美元的损失。开

2:52 ↗
postmortem · zh-CN · 2026年9月10日

一位工程师删除了GitLab的生产数据库。300 GB。

2017年1月31日,世界标准时间23:27:一位GitLab工程师在熬夜修复一个损坏的副本时,不小心删除了db1而非db2上的PostgreSQL数据目录。db1是主数据库。GitLab.com大约300 GB的数据库在一两秒内消失了,而且五个备份和复制机制都失效了。事后分析:从垃圾邮件高峰到错误主机名的时间线,pg_basebackup为何看似卡住,pg_dump为何一直静默失败(9.2二进制

2:53 ↗
postmortem · zh-CN · 2026年9月9日

AI 删除了生产数据库。九秒。

一个 AI 编程代理(运行 Claude Opus 4.6 的 Cursor)在暂存环境中遇到凭证不匹配,并通过使用它在一个不相关文件中找到的账户范围令牌,在 Railway 上调用 volumeDelete 来“修复”它。生产数据库和所有卷备份在九秒内消失。事后分析:时间线,确切的 curl 命令,导致这种情况发生的三项架构事实(备份在同一卷上,根范围令牌,一个没有仪表板 48 小时撤销功能的

3:23 ↗