+− THE DAILY DIFFdev & AI news
SHIP IT

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

2017年1月31日,世界标准时间23:27:一位GitLab工程师在熬夜修复一个损坏的副本时,不小心删除了db1而非db2上的PostgreSQL数据目录。

2017年1月31日,世界标准时间23:27:一位GitLab工程师在熬夜修复一个损坏的副本时,不小心删除了db1而非db2上的PostgreSQL数据目录。db1是主数据库。GitLab.com大约300 GB的数据库在一两秒内消失了,而且五个备份和复制机制都失效了。事后分析:从垃圾邮件高峰到错误主机名的时间线,pg_basebackup为何看似卡住,pg_dump为何一直静默失败(9.2二进制文件在9.6数据库上,失败邮件被DMARC退回),从6小时前暂存快照恢复的18小时过程在YouTube上直播,以及谁应该真正承担责任。对响应的评价:SHIP IT。

阅读书面版(英文) ↗

本视频涵盖的内容

  • 2017年1月31日:在主数据库的数据目录上执行rm -Rvf;约300 GB被删除,留下4.5 GB
  • 5个备份全部失败:S3桶为空(pg_dump版本不匹配),数据库没有Azure快照,副本被清除,每日LVM复制没有Webhooks
  • 2月1日,世界标准时间18:00:GitLab.com从6小时前的手动快照恢复;实时文档、直播、附带修复列表的无责事后分析

翻译的文字记录

译自英文原版旁白。可用音频和字幕由 YouTube 控制。

0:00 GitLab的一名工程师在错误的数据库服务器上运行了 rm -rf, 然后 GitLab.com 的三百吉字节数据在一两秒内消失了, 这大约是读取一个主机名所需的时间。 2017年1月31日,晚上11:27, 世界标准时间。GitLab 发推称其不小心删除了生产数据, 向互联网公开了事故记录,并在 YouTube 上直播了恢复过程, 这是该平台第二热门的直播。 第二天,书面声明:五种备份技术中,

0:25 没有一种能可靠运行。 它是如何发生的,为什么会发生,以及谁应该真正承担责任。 这里是 The Daily Diff,事后分析。 下午5:20:一名工程师制作了生产快照, 以测试暂存环境中的负载均衡器。 晚上7点:垃圾邮件攻击数据库,以及一个硬删除GitLab员工的作业, 该员工因被举报滥用行为。 晚上11点:副本落后太多,以至于主数据库已经丢弃了

0:48 它所需的日志;唯一的修复方法是清除副本并重新复制主数据库。 pg_basebackup 挂起,没有输出。 它实际上是在静默等待主数据库;没有人知道这一点, 操作手册也没有说明。 这位工程师本打算在11点下班,他认为空数据目录是问题所在,并将其删除。 他认为空数据目录是问题所在并将其删除。 在 db1 上。主数据库。 一两秒后他注意到了;大约三百吉字节的数据中,

1:11 剩下4.5 GB。备份。 第一:pg_dump 到 S3,每日执行。 桶是空的。 cron 任务在一个没有数据库的应用服务器上运行,所以软件包选择了 用于 9.6 数据库的 PostgreSQL 9.2 二进制文件,失败,并发送邮件 失败通知,由于缺少 DMARC 而被退回。 第二:Azure 磁盘快照,为文件服务器启用, 而不是数据库。

1:32 第三:副本,一小时前被故意清除。 第四:每日快照,24小时前,所有 webhook 被 暂存同步剥离。第五:下午5:20的手动快照,用于不相关的测试。 这个快照成功了。 恢复意味着以每秒六十兆比特的速度,通过 Azure 的廉价存储将暂存磁盘复制回生产环境: 需要十八个小时。 GitLab.com 于2月1日晚上6点恢复。 世界标准时间,数据落后六小时。

1:58 git blame:两个主机名仅相差一个字符,以及五个从未有人 恢复过的备份系统。 不是工程师的错。 由首席执行官签署的事后报告让他匿名, 将生产提示符设为红色,并为数据持久性指定了负责人, 因为在此之前它没有负责人。 影响范围:停机十八小时,数据丢失六小时, 大约五千个项目,五千条评论,

2:18 七百个新用户,以及五千人看着进度条。 Hacker News 给这份实时文档打了1,162分,并引用了其中一句话 回复他们:五个备份中,没有一个可用。 裁决,事后分析:对响应的评价是 SHIP IT。 他们公开处理了事故,归咎于流程,并发布了带有问题编号的修复列表。 并发布了带有问题编号的修复列表。 周一行动:恢复备份。 如果你从未恢复过它,你就是没有备份。

2:42 把你仍然不被允许谈论的事故发给我, 在评论区,或发送至 the daily diff dot dev。 这就是今天的 The Daily Diff。 我是 Axrisi 的 Niko。 负责任地合并。

来源

  1. GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
  2. GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
  3. @gitlabstatus, "We accidentally deleted production data…"twitter.com
  4. @gitlabstatus, emergency maintenance noticetwitter.com
  5. Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
  6. Hacker News, the postmortem thread (377 points)news.ycombinator.com

相关视频

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

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

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

3:23 ↗
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 ↗