国外互联网企业事故启示录（学习篇）#

发生了什么#

• 涉及域名：gitlab.com（生产环境）、db1.cluster.gitlab.com（主数据库）、db1.staging.gitlab.com（预发布库）
• 时间：2017 年 1 月 31 日 23:00 左右（UTC）

GitLab 的工程师在夜间值班时，发现数据库同步有些问题。他原本的计划是：删除 db2 的数据库目录，让它重新从主库复制数据。

但悲剧的是——他输错了命令，把 db1.cluster.gitlab.com（生产主库）的数据库目录给删了，而不是 db2。

1
# 原本想删这个（预发布/备用库）
2
rm -rf /var/opt/gitlab/postgresql/data/...（db2 目录）
3

4
# 结果实际删了这个（生产主库）❌
5
rm -rf /var/opt/gitlab/postgresql/data/...（db1 生产目录）

为什么备份救不了？#

这才是最扎心的地方。GitLab 号称有 5 套备份机制，结果：

5 套机制，4 套失效——最后只能靠一个比较旧的 LVM 快照 + 从 db1.staging（预发布库）恢复 6 小时前的数据。

整个流程#

1. 23:00 左右，工程师误删生产库目录
2. 发现后立即尝试恢复，发现备份大多失效
3. GitLab 团队公开在 YouTube 直播恢复全过程（这波操作很有勇气）
4. 从 db1.staging 复制数据（预发布环境的数据，比生产少）
5. 通过幸存的 LVM 快照尽量找回更多数据
6. 最终：大部分数据找回，但仍有部分数据永久丢失（主要是 issue、comment 等一段时间内的更新）

教训#

• 备份要定期演练，不是”有了就行”——5 套备份 4 套失效，等于没备份
• 危险命令要防呆：生产库目录删除这种操作，应该有多重确认、双人复核
• 隔离环境：预发布和生产库目录命名要一眼能分清，别让 db1 和 db2 那么像

发生了什么#

• 涉及域名：s3.amazonaws.com（S3 服务）、us-east-1（北弗吉尼亚区域，最大区域）
• 时间：2017 年 2 月 28 日上午 9:37（美西时间）

AWS 工程师在排查 S3 计费系统变慢的问题。按照操作手册，他执行了一条命令，本意是删除少量计费子系统的服务器。

结果：命令的一个参数输入错误，删除的服务器数量远超预期，直接把支撑 S3 核心功能的两套子系统（索引子系统 + 部署子系统）干掉了。

为什么会波及半个互联网？#

因为 S3 是整个 AWS 生态的地基。这次故障发生在 us-east-1——AWS 最大、最老的区域，无数网站和服务的资源都存在这里。

受影响的服务包括：

• S3 本身：所有 GET、LIST、PUT、DELETE 操作全部失败
• AWS 控制台：AWS 自己都进不去控制台，只能用推特发公告（被网友疯狂吐槽）
• EC2 新实例：无法启动新实例
• EBS 卷：依赖 S3 快照的卷受影响
• 大量第三方网站：Quora、Medium、Imgur 等一大批依赖 S3 的网站全部遭殃

整个流程#

1. 9:37 执行命令出错，删除过多服务器
2. S3 索引子系统下线 → 所有读写操作失败
3. AWS 开始紧急恢复，但因为相关子系统好几年没重启过，恢复过程异常缓慢
4. 12:36（美西时间）S3 基本恢复，前后约 4 小时
5. AWS 事后发布详细复盘报告，修复了工具的安全机制

教训#

• 危险命令要有沙盒和复核：一条命令可能删掉几个 GB 的服务器，输入错一个字符就是全球事故
• 核心系统要有快速恢复能力：几年没重启过，重启一次要几个小时
• 依赖链风险：你的服务依赖云服务，云服务一崩，你也跟着崩——多区域冗余很重要

发生了什么#

• 涉及域名：github.com
• 时间：2018 年 10 月 21 日 22:52 UTC

GitHub 工程师在例行更换一个故障的 100G 光模块时，不小心导致美国西海岸数据中心与东海岸主数据中心之间的光纤连接断开。虽然 43 秒后连接就恢复了，但这短暂的断连引发了一连串连锁反应。

为什么会这么严重？#

GitHub 的 MySQL 架构是：写请求直接发给主库，读请求发给从库（副本），用 Orchestrator 做自动故障转移。

光纤断开那 43 秒里：

1. 网络分区导致主从节点失联
2. Orchestrator 检测到主库”失联”，自动触发故障转移
3. 但转移过程中，主从两边都以为自己是主库，数据产生了分歧
4. 网络恢复后，不知道该信哪边的数据——因为无法确定哪个镜像的数据是完整的
5. 只能从磁盘快照从头做数据恢复，非常耗时

整个流程#

• 22:52 UTC 光纤断开 43 秒
• 自动故障转移开始，但数据出现分歧
• GitHub 团队发现无法确定数据完整性，只能手动恢复
• 恢复期间：Webhook 失效、GitHub Pages 无法构建、部分数据展示过时
• 持续 24 小时 11 分钟后才完全恢复正常
• 万幸：用户数据最终没有丢失

教训#

• 自动故障转移是把双刃剑：自动切换可能比不切更糟，要做好”脑裂”（主从都当自己是主）的处理
• 光纤级别的单点故障：跨机房连接要冗余，一根线断 43 秒就够你喝一壶
• 例行维护是事故高发期：换光模块这种”简单操作”，恰恰是最容易出事的时刻

发生了什么#

• 涉及域名：facebook.com、instagram.com、whatsapp.com、messenger.com（全家桶一起挂）
• 时间：2021 年 10 月 4 日 15:51 UTC 起，约 6 小时

Facebook 在例行维护骨干网络时，工程师执行了一条评估骨干网容量的命令，结果这个命令错误地把全球所有骨干连接全部断开了。

更致命的是：Facebook 的内部审计工具还有个 bug，没能拦截这条错误命令。

为什么会”从互联网消失”？#

这是整起事故最精妙（也最尴尬）的部分：

1. Facebook 的 DNS 服务器依靠骨干网连接数据中心
2. 骨干网全部断开后，DNS 服务器以为”网络不健康”
3. 于是 DNS 服务器自动撤回了 BGP 路由宣告——相当于对外宣布”我们没有这些服务器了”
4. 结果：全世界都找不到 facebook.com / instagram.com / whatsapp.com 的 IP
5. Cloudflare 的公共 DNS 1.1.1.1、Google 的 8.8.8.8 全部解析失败
6. 连 Facebook 员工自己都无法远程访问数据中心去修——越是修，越进不去

整个流程#

• 15:51 UTC 骨干网被错误断开
• BGP 路由撤回 → DNS 解析失败 → 全球无法访问
• Cloudflare 最先发现异常，发推分析可能是 BGP 问题
• Facebook 员工被困在”无法远程访问自己数据中心”的尴尬境地，不得不派物理人员进机房
• 约 6 小时后逐步恢复
• Facebook 只能在竞争对手 Twitter 上发文道歉（太尴尬了）

影响有多大#

• 全球 Facebook 家族 27.6 亿日活用户受影响
• 股价下跌近 5%
• 扎克伯格个人财富缩水约 60 亿美元
• 收入损失估计超过 6000 万美元

教训#

• 不要过度集中：DNS、BGP、骨干网全绑在一起，一环断全环断（像圣诞灯串）
• 内部工具要能拦错误：审计工具出 bug 是事故扩大的关键因素
• 自愈机制可能帮倒忙：DNS 自动撤回路由本是好设计，却让事故从”断网”升级为”全网消失”

发生了什么#

• 涉及域名：codespaces.com（代码托管平台，被干到关站）
• 平台：亚马逊 AWS EC2 控制台
• 时间：2014 年 6 月 17~18 日

Code Spaces 是一家提供 SVN/Git 代码托管 的创业公司。6 月 17 日，它遭受了 DDoS 攻击——本来这很常见，他们一般能扛过去。

但这次不一样：攻击者不满足于 DDoS，进一步入侵了他们的 AWS 控制台，还留下信息勒索。

整个流程#

1. 6 月 17 日，遭受组织严密的 DDoS 攻击
2. 攻击者入侵 AWS EC2 控制面板，索要赎金
3. Code Spaces 尝试夺回控制权、修改 EC2 密码
4. 攻击者发现他们在恢复，开始随机删除数据——先删 EBS 快照、S3 桶，再删 AMI、机器实例
5. 所有数据、备份、机器配置、异地备份全部被删
6. 6 月 18 日，Code Spaces 宣布永久关闭——12 小时内，公司没了

最讽刺的地方#

Code Spaces 一直强调自己有完善的备份恢复方案。但问题是：备份和主数据都在同一个 AWS 账号里，攻击者拿到控制台权限后，把备份一起删了。

教训#

• 备份要隔离：备份不能和主数据在同一个账号/权限体系下，否则”删数据”和”删备份”是一键的事
• 控制台权限是命门：云控制台被盗，等于公司被掏空
• 云安全不只是技术：密码管理、多因素认证（MFA）、最小权限，一个都不能少