公开事故复盘索引：按根因找同类事故这是一张“按根因找同类事故”的索引，不是 12 篇复盘的摘要合集。每条只保留事故、年份、直接根因、一句话教训和可对照的 Runbook；时间线、影响面、恢复过程和报告边界请回到原复盘。分组按“直接根因”归入一组，但很多事故是多因叠加，组内提示和第二假设同样重要。 事实以各事故的官方报告为准。本页不补写报告没有给出的数字，也不把传播中的简化标签当作根因

这是一张“按根因找同类事故”的索引，不是 12 篇复盘的摘要合集。每条只保留事故、年份、直接根因、一句话教训和可对照的 Runbook；时间线、影响面、恢复过程和报告边界请回到原复盘。分组按“直接根因”归入一组，但很多事故是多因叠加，组内提示和第二假设同样重要。

事实以各事故的官方报告为准。本页不补写报告没有给出的数字，也不把传播中的简化标签当作根因。

怎么用这个索引

1. 先按症状找组。 从你正在看到的症状出发：解析失败、502 或超时、写入失败、延迟飙升、权限告警、控制面不可用。先进入最接近的组，再把其他可疑组记为第二假设。一次事故常常同时命中两组，例如“网络分区触发数据库选主”既像路由问题，也像控制面问题。
2. 再读时间线与根因。 打开组内原复盘，重点看三件事：触发点到用户影响之间经过了哪些放大环节；恢复为什么慢；报告没有给出哪些数字。不要只记一句结论，也不要把传播中的简化标签当成根因，例如把 Cloudflare 2020 叫作“DNS 故障”。
3. 最后回到自己的检查清单。 用文末的“复盘对照问题”逐条对照你的系统，把能落到工程控制的项写成 owner、截止时间和演练记录；再用对应的 Runbook 验证恢复路径是否真的可执行。处置节奏可参考 事故响应手册。

分组索引

路由 / DNS / BGP（2 篇）

症状线索：解析失败、跨地域绕行、单点拥塞、路由宣告异常、流量被吸到某个位置。先区分“DNS 软件故障”“BGP 宣告问题”和“骨干链路中断”，三者排查方向不同。

组内提示：Facebook 2021 的触发点其实是维护命令，把它放在本组，是因为真正让全球不可访问的是 BGP 撤回与 DNS 不可达。按症状进组后，仍要回到原复盘看变更环节。

配置与变更（2 篇）

症状线索：故障紧跟发布、配置、补丁、扩容或运维命令出现；回滚后好转；或者“变更本身没错，但范围超出了预期”。

组内提示：Datadog 2023 的变更不是人工发布，而是自动补丁通道；不要因为“没有发布”就排除变更类根因。

存储与数据（2 篇）

症状线索：数据目录被删、主从复制中断、写入延迟异常、快照或备份不可用、恢复点比预期旧。

组内提示：Roblox 2021 同时是控制面事故；把它放在存储组，是因为两个低层缺陷都落在 Consul 的写入与存储引擎上。排查时不要把“网络慢”当成唯一方向。

容量与性能（3 篇）

症状线索：CPU、内存、线程、连接数或配额触顶；扩容后反而更差；延迟升高但进程没有崩溃；错误集中在高负载时段。

组内提示：Cloudflare 2019 的触发点是配置部署；如果只按“变更”找，会漏掉“性能门禁”和“kill switch”这两个真正的教训。

权限与安全（1 篇）

症状线索：异常登录、会话复用、令牌或密钥疑似泄露、CI 变量被读取、审计日志出现陌生下载或授权。

控制面 / 云依赖（2 篇）

症状线索：服务发现、调度、密钥管理、数据库选主或云网络控制面异常；数据面还在跑，但路由、配置或选主已经失控。

组内提示：Google Cloud 2019 同时有“维护变更”和“BGP 撤回”两层；归入本组是因为控制平面被整体取消调度，数据面才失去维持能力。

复盘对照问题

1. 这次事故的直接触发点是什么？它属于哪一组根因，还是多组叠加？第二嫌疑组是什么？
2. 从触发点到用户影响，中间经过了哪些放大环节：自动切换、健康检查、重试、扩缩容、BGP 撤回、缓存或队列？
3. 如果与变更有关，爆炸半径有多大？是否有灰度、dry-run、二次确认、影响范围预览和独立熔断？
4. 如果与容量有关，扩容模型是否计算了每节点随集群规模增长的线程、连接、内存和云配额？
5. 如果与路由或 DNS 有关，健康判断与路由宣告会不会在总故障时形成正反馈？带外通道是否真的独立？
6. 如果与存储或数据有关，最近一次恢复演练是什么时候？RPO、RTO 是多少？备份是否覆盖附属数据和密钥？
7. 如果与权限或安全有关，长期凭据能否换成短期凭据？2FA 之外是否有会话窃取防护、最小权限和审计日志外送？
8. 如果与控制面或云依赖有关，控制面配置能否本地持久化？fail-static 能撑多久？云厂商自动替换会不会破坏有状态数据？
9. 监控、告警、状态页和应急工具是否与被监控系统共享依赖？故障时还能看见、还能沟通吗？
10. 恢复阶段是否定义了优先级、分批重启、限流和放量门槛？会不会“恢复即二次故障”？

恢复路径与 Runbook

按你手上的恢复动作选 Runbook，不要按事故公司名选。下列 12 篇覆盖本站现有的主要恢复场景：

• 数据库主从切换：对照 GitHub 2018 的跨区域选主与分叉写入。
• PostgreSQL 时间点恢复：对照 GitLab 2017 的误删与备份失效。
• Elasticsearch 快照恢复：索引误删、mapping 损坏或集群重建时使用。
• etcd 快照恢复：对照 Roblox 2021、Google Cloud 2019 的控制面故障。
• Kubernetes 升级：对照 Datadog 2023 的节点更新、回退与验证。
• Kafka 恢复：副本、元数据或消费者位点恢复，可对照 AWS Kinesis 2020 的恢复思路。
• Velero 恢复：命名空间或集群资源误删后的恢复。
• 证书轮换：证书与信任链轮换，凭据轮换可借鉴 CircleCI 2023 的清单化做法。
• Redis 主从切换：缓存/会话主节点故障后的副本提升与客户端重连。
• Kafka broker 替换：broker 退役、分区副本迁移与 ISR 验证。
• DNS 提供商切换：权威 DNS 迁移、TTL 预降与 DNSSEC 验证。
• 备份恢复验证：把“有备份”验证成“能恢复、数据一致”。

相关命令

• journalctl — 复盘时按时间线核对内核、systemd 与服务日志。
• tcpdump — 还原丢包、重传、RST 与路由异常的证据。
• dig — 区分 DNS 解析失败、SERVFAIL 与权威服务器不可达。
• kubectl — 检查事件、Pod 状态、控制面与节点健康。
• etcdctl — 核对 etcd 成员、quorum、快照与告警。

参考链接

• Google SRE Book：Postmortem Culture: Learning from Failure
• Google SRE Workbook：Postmortem Culture: How You Can Learn from Failure

读完自测

合上页面，先回答，再展开对照。

1. 这页为什么按“直接根因”分组，而不是按公司、年份或影响面分组？
2. 为什么不能把 Cloudflare 2020 简单称为“DNS 故障”？
3. 复盘对照问题怎样才算真正落地，而不是写完就归档？