先说结论：8·17 GitHub 宕机，网上流传最广的段子，是 Cursor 员工那句“我们本打算更早发布这个产品，结果 GitHub 宕机了”，但真正难受的不是打不开网页的人，而是构建链挂在 GitHub 上的 Docker 用户。36氪Downdector 的用户报告曲线上，GitHub 那天出现了一波陡峭的报告尖峰。高峰时段，原始文件下载和代码归档下载两条通道的错误率达到 50% 左右。微博翻译一下：如果你的 Dockerfile 里有一行是从 GitHub 拉资源的，那你当天的构建不是“失败”，是“跟你掷骰子”——重试两下，没准能过一次。
先把时间线对齐：很多人只看到了前半段
不少媒体报道的是“宕机约 3 小时”，那只是 GitHub 官方宣布“核心服务已做缓解”的窗口。看官方状态页的事故记录：13:40 UTC 开案，21:15 UTC 才宣布解决，中间隔着 7 小时 35 分钟，余震又持续了 4 个多小时。哔哩哔哩Pull Requests、Issues、Actions、API、Webhooks、Pages、Git 操作陆续异常，Copilot 单独挂了将近 7 个小时。36氪
至于事故根因，GitHub 承诺会发 RCA，截至发稿还没放出来。哔哩哔哩所以网上流传的各种“内部消息”，暂时都别信。
对玩 Docker 的人来说，到底被打中了哪？三条路径
先澄清一个反直觉的事实：这次镜像拉取不是主灾区。Docker Hub 跟 GitHub 本来就没关系，ghcr.io 也没出现在官方事故清单里——当天你如果只是 docker compose pull 更新容器，基本没事。
真正塌的是构建链。GitHub 官方状态账号在通报里写得很明确：web 和 API 流量错误率约 20%，而代码归档下载、原始仓库内容下载这两条通道，错误率达到 50% 左右。钛媒体
对应到 Docker 用户常用的三条路径：
路径一：Dockerfile 里直接从 GitHub 拉资源。比如 ADD 一个 raw.githubusercontent.com 开头的 URL，或者 RUN curl -L 下载 github.com 的 archive 包——正好就是这两条被打中的通道。而且随机失败比全挂更折磨人：重试几次过一次，你以为好了，下一次又挂。当天跑构建的人，心态都是这么被磨掉的。
路径二：GitHub Actions 上构建镜像的 CI。Actions 是这次的核心受损服务之一，checkout 一步趴下，后面构建、推镜像的整条流水线全停。把发布流程绑在 Actions 上的团队，只能干等 7 个多小时。
路径三：curl | bash 的一键安装脚本。很多自建工具的 Docker 一键部署脚本就放在 raw.githubusercontent.com 上，当天跑安装脚本等于掷硬币——这跟脚本本身有没有 bug 无关，不少人第一反应是“项目方又改啥了”，其实是通道病了。
为什么这么频繁？这不是意外
补两个背景。GitHub 的 CTO 今年 4 月公开承认：2025 年 10 月启动的 10 倍容量扩容计划，到 2026 年 2 月就发现远远不够，必须按 30 倍规模重新设计——官方点名的原因，是“代理式开发工作流的急剧加速”。36氪社区还有一个流传的说法：2025 年全年提交量 10 亿次，到 2026 年初变成了每周 2.75 亿次。微博AI Agent 带来的代码洪流，正在改变整个平台的负载结构。
这也不是孤例。4 月 27 日那次 ElasticSearch 事故，让全球瘫痪了约 18 个小时；Vagrant、Terraform 的作者 Mitchell Hashimoto——GitHub 最早期的用户之一——今年开始每天给 GitHub 宕机影响工作的日子打叉，他的原话是“几乎每天都有”，4 月直接把 5 万星项目 Ghostty 迁离了 GitHub。36氪微博上有人总结得直白：自从 AI Coding 爆发，GitHub 几乎天天挂、周周挂。微博所以对我们这些还在靠 GitHub 的 Docker 用户来说，问题不是“会不会再挂”，而是“下次什么时候挂”。
兜底清单：四级，按成本来
不用等 RCA，下面这些事今天就能做，按成本从低到高排：
第一级，零成本：把 Dockerfile 里的 GitHub 外链干掉。常用 raw 文件直接存进构建上下文，或换镜像源；确实要网络拉取的，给构建脚本加重试逻辑。顺手把基础镜像锁定到具体版本号，别用 :latest——至少重建时不会被一次网络拉取卡死。
第二级，十分钟：给关键镜像存档。docker save -o backup.tar 镜像名:tag，天塌下来 docker load 拉回来。自建玩家把 NAS 上十几个核心服务的镜像备一份，宕机那天会比别人从容很多。
第三级，半小时：搭本地缓存。用 registry:2 跑一个 pull-through cache，或者把常用镜像推到 NAS 的私有仓库，日常拉取根本不出外网；顺手保留 BuildKit 的层缓存，构建链断了，缓存层还能复用。
第四级，有团队的：别把 CI 全押在 Actions。关键发布链路准备第二通道（自建 runner + 其他 CI）；代码定期 git clone --mirror 做裸仓库全量备份。整体迁去 Forgejo/GitLab 的隐形成本不低，对多数团队来说，“做兜底”比“跑路”现实。
这不是危言耸听。镜像供应链的脆弱早有先例：去年 10 月，下载量超 10 亿次的开源项目 MinIO 突然停发免费官方 Docker 镜像，Docker Hub 和 Quay.io 上找不到新版本的用户，最后只能自己拉源码构建。36氪兜底清单的意义，不只是防一次 GitHub 宕机，而是任何一环断供时，你都还有饭吃。
再说清楚每一级适合谁：个人玩家和自建用户，一二两级够用；每天跑 CI 构建的，第三级必做；第四级留给靠发布吃饭的团队。
宕机那天，微博上一篇热帖说得挺到位：建立本地镜像和解耦 CI/CD，已经不再是选项，而是生存必备。微博话说得重了点，但方向没错——平台的 SLA 是平台的生意，你自己的构建链能不能活，是自己的工程。
你那天卡在哪了？评论区聊聊，官方 RCA 出来之后我们跟进。
