网络断了 43 秒。自动 failover 完全按配置正确地执行了。然后是 24 小时 11 分钟的服务降级——不是因为他们修不好，而是因为他们选择了不快点修好。
2018 年 10 月 21 日 22:52 UTC。一次例行维护——更换出故障的 100G 光设备——导致 GitHub 的美东网络枢纽与美东主数据中心之间失去连通性 [S1]。
连通性在 43 秒后恢复 [S1]。
但这短短 43 秒触发了一连串事件，最终造成 24 小时 11 分钟的服务降级 [S1]。
先交代背景。GitHub 用 MySQL 存非 Git 的元数据（PR、issue、认证、后台任务等），集群规模从数百 GB 到近 5 TB，每个集群带最多数十个只读副本 [S1]。拓扑管理与自动 failover 交给 Orchestrator，它基于 Raft 做共识 [S1]。
官方复盘在讲事故之前，先自己点了一句隐患——请记住它，因为整场事故都长在这句话上：
43 秒里发生的事，一步都不违反设计：
网络分区发生。原本在主数据中心活跃的 Orchestrator 按 Raft 共识开始"卸任"流程 [S1]——这是 Raft 该做的事。
美西数据中心与美东公有云的 Orchestrator 节点凑齐了法定人数（quorum），开始把集群 failover 过去，让写入指向美西 [S1]——这也是 Raft 该做的事：多数派还在，就该选出新领导。
应用层立刻开始把写流量打向美西的新主库 [S1]——这同样是应用层该做的事：主库在哪就写哪。
美东的数据库上有一小段还没复制到美西的写入；而美西正在持续接收新写入。两边都有对方没有的数据，因此无法安全地把主库切回美东 [S1]。
这里要精确一点，因为这是最容易被讲错的地方：官方复盘并没有证据表明两地数据库「同时」作为主库持续接受写入。它更准确的名字是跨区域自动 failover 之后的数据分叉——美东留着 failover 前没来得及复制出去的写，美西接管后产生了新的写。但一旦进入恢复阶段，它和病历卡 No.14 面对的是同一道难题：
未复制到美西的写入总量其实很小——官方举的例子是：最繁忙的一个集群，在受影响窗口里有 954 次写入 [S1]。
954 条。接下来的 24 小时，都是为这 954 条（以及其它集群里同类的少量写入）付的账。
A 是 GitHub 实际的选择，而且他们说清楚了这是一笔明码标价的交易。官方原文：美西已写入 30 多分钟的数据，使他们「没有别的选择，只能向前修复以保住用户数据」[S1]。代价被写得同样明确：跑在美东、却要写美西 MySQL 的应用扛不住跨洲往返延迟，这个决定会让服务对很多用户不可用 [S1]。最后是那句表态——「我们认为，为了确保用户数据的一致性，长时间的服务降级是值得的。」[S1]
B 是压力最大时最诱人的选项，因为它能让站点立刻变快。但它的实质是：把 40 分钟里所有用户的 issue、评论、PR、推送记录悄悄抹掉。这类损失有一个恶劣特性——用户不会立刻发现，他们会在几天后困惑地问"我那条评论去哪了"，而那时你已经没有证据链了。可用性的损失是当场可见、可解释、可道歉的；一致性的损失是延迟爆炸、不可解释、不可挽回的。这就是 D3 那句表态背后的算术。
C 的方向是对的，作为唯一方案则不可行。GitHub 确实做了这件事——他们捕获了 MySQL binlog 里那些未复制的写入，逐条分析哪些可以自动对账、哪些需要联系用户 [S1]。但这是并行进行的后续工作，不是恢复路径：站点不可能停在那里等人工对账完成。C 的正确定位是 A 的补充，而不是替代。
D 是脑裂里最危险的想法，因为它看起来最"务实"。让两边继续各自写入，等于让分叉持续扩大——每多一分钟，需要对账的数据就多一分钟，而两份数据的合并难度随分叉时长非线性上升。第 15 章讲过的那条铁律在这里生效：发现脑裂后的第一动作是让其中一边停止写入，而不是让两边都活着。
B 是 GitHub 做的，而且它的机理值得单独记住。他们在美东公有云增开只读副本；这些副本可用后，读请求得以摊到更多机器上，降低了副本整体的利用率，复制才追得上来 [S1]。为什么有效？因为副本要同时干两件事：服务读请求 和 重放主库日志。当读负载吃满它的资源时，重放就没有余量——这正是第 3 章讲的「接收位点追上了、应用位点追不上」，只不过瓶颈不在单线程重放，而在利用率。第 2 章的 ρ 在这里第二次索命。
A 忽略了一个已经被观测到的事实：延迟在上升。官方记录明确写着当时「复制延迟在增加而不是朝一致状态收敛」[S1]。一个正在发散的量不会因为等待而收敛。这也是本书最反直觉的数字课之一：GitHub 原本按线性外推给出了「两小时」的恢复预期，但实际的追赶曲线遵循的是幂衰减而非线性，加上欧美用户陆续开始工作带来写负载上升，恢复比原估计更久 [S1]。
C 会把局部问题变成全局崩溃。把落后副本摘掉，等于把它们的读流量压到剩下那几台已经追上的副本上——那几台的利用率随即飙升，重放开始落后，然后它们也要被摘掉。这是第 7 章级联故障（病历卡 No.09）的标准剧本，只不过发生在副本层。正确方向和 B 相反：不是减少承载者，是增加。
D 有实际价值，GitHub 也一直在做（webhook 与 Pages 构建从 23:19 起就停了 [S1]）。它之所以只是次优，是因为它处理的是写侧和异步任务的负载，而此刻的瓶颈在读副本的利用率。降级能争取时间，但不增加重放余量。最好的组合是 B + D：一边加承载，一边减负载。
B。GitHub 明确写道：作为优先保数据完整性而非缩短事故窗口的自觉决定，他们在开始处理积压时仍然保持红色状态 [S1]，直到 23:03 UTC 全部积压处理完毕、系统完整性与运行状态得到确认，才转绿 [S1]。这个选择的深层理由在后面一句：他们不想进一步侵蚀状态播报本身的可信度 [S1]。状态页是一种承诺，提前转绿是透支它。
A 犯的是一个定义错误：把"页面能打开"当成了"服务正常"。此时排队的还有超过 500 万个 hook 事件和 8 万次 Pages 构建 [S1]。对依赖 webhook 的用户来说，服务此刻和挂着没有区别——他们的 CI 没被触发，部署没有发生。可用性要按用户完成任务的能力定义，不按你的仪表盘定义。
C 在直觉上最合理，可惜当时办不到。官方复盘专门检讨了这一点：他们当时只有 green / yellow / red 三档，无法准确表达"哪些部分能用、哪些不能用"，因此事后加速了状态播报机制的改造 [S1]。这条对你的意义很直接：如果你的状态页只有三档，你迟早会被迫在"撒谎"和"过度悲观"之间二选一。
D 是最微妙的错误：它把责任从系统转移给了用户的阅读能力。绿色是一个会被机器和人快速消费的信号，公告是需要人主动去读的文本。当两者矛盾时，人们相信颜色。不要用注释去纠正一个错误的状态值。
16:45 UTC 重新处理积压时，有约 20 万个 webhook 载荷因为超过内部 TTL 被丢弃；团队发现后暂停处理并上调了 TTL [S1]。
第 9 章算过的那条式子在这里有了新含义：积压不只是「要多久才能追平」，还有一个隐藏条款——队列里的东西会过期。追平之前就过期的消息，追平也救不回来。
此刻的「秒抢」：约 7000 万用户、295 人，第 15 章刚经历过一次演练变真故障的脑裂。GitHub 这一关几乎逐条对应你刚学的东西——但它最重要的贡献是指出了下一步该往哪走。
| GitHub 的失效点 | 「秒抢」的对应物 | 动作 | 关联 |
|---|---|---|---|
| 自动 failover 跨区提主 | 数据库高可用组件、注册中心、配置中心的自动选主 | 明确写死选主的地理边界；并回答一个问题：跨机房提主之后，应用还连得动吗 | 第 15 章 |
| 954 条分叉写入 | 订单、库存扣减、支付回调 | 确保关键写入可逐条追溯（binlog / 事件日志留存），数据分叉后能对账而不是靠猜 | 第 10 · 11 章 |
| 副本利用率吃满导致追不上 | 只读副本、缓存回填、消费者组 | 给副本留重放余量：读利用率红线设在 70%，而不是等它追不上再加机器 | 第 2 · 3 章 |
| 积压消息过期被丢 | MQ 里的订单通知、出票任务 | 盘一遍所有队列的 TTL：TTL 必须大于你最坏情况下的追平时间，否则积压追平之日就是数据丢失之时 | 第 9 章 |
| 状态只有三档 | 「秒抢」的服务状态页 | 按功能模块分别播报（购票 / 支付 / 出票 / 查询），而不是整站一个颜色 | 第 14 章 |
GitHub 复盘的结尾，写的不是技术改进，是一段组织层面的结论。他们说这次事故改变了他们对站点可靠性的思维方式：在这样复杂的服务体系里，更严的运维管控或更快的响应时间，都不足以保障可靠性 [S1]。
所以他们决定开始一件事——系统性地在故障有机会影响用户之前，主动验证失效场景；并为此投入故障注入与混沌工程的工具建设 [S1]。
逐句核对清单见构建仓库 sources/FACTS-level4.md；来源原文留档见 sources/raw/github-2018-post-incident.txt。第三方转述未被采信为事实依据。