周一晚上（8 月 17 日，北京时间 21:28 开始），GitHub 结结实实挂了 7 小时 47 分钟。Issues、Pull Request、Actions、API、Webhooks、Pages 挨个出问题，企业 SSO 认证受影响，连 Copilot 都一起趴窝。36氪如果你平时在终端里干活，当晚的感受应该很直接：gh 命令一条接一条报错，CI 卡在流水线中间，靠 Copilot 辅助写代码的团队按知乎网友的说法是"直接回到了石器时代"。知乎
更戏剧的是，Cursor 恰好赶在同一时间窗口上线了自己的代码托管平台 Origin，"Cursor 杀死 GitHub"的说法刷了一天屏。36氪但热闹归热闹，对 GitHub CLI 用户来说，真正值得花十分钟想清楚的是一个很实际的问题：我们的整条工作流都押在 github.com 在线这件事上，下次宕机之前，能做点什么。
先复盘：官方已经交代了根因，两个细节和 CLI 用户直接相关
根据 GitHub 官方状态页的复盘（北京时间 8 月 18 日凌晨恢复服务），这次事故的时间线是 8 月 17 日 13:28 到 21:15（UTC），持续 7 小时 47 分钟。高峰时段，网页和 API 请求的错误率大约 20%，代码归档和原始内容下载的错误率一度冲到约 50%。微博
根因链条大致是三步：美国中部数据中心的负载均衡网络先出现饱和；接着 Istio sidecar 代理达到并发上限，而扩容策略没有正确观察到这个指标；最后，客户端的重试行为把压力进一步放大——据国内技术日报对官方复盘的转述，VS Code 的一个潜在重试缺陷把 Copilot Token Service 的请求量从常态的每秒 7–9K 一路推到了 70–100K，放大了约 10 倍。GitHub 列出的整改项包括 sidecar 扩容、重试退避、容量监控和区域故障转移。知乎
这里面有两个细节，终端用户值得记住：
第一，盲目重试会放大故障。这次事故的恶化，客户端重试风暴"功不可没"。所以下次遇到 gh 疯狂报错，第一反应不应该是写个循环疯狂重试，而是先看一眼状态页——这个习惯这次真的能救命。
第二，这次连 Git 操作本身都受影响了。以往多数 GitHub 故障里，纯 git 协议（clone/push）往往还能撑住，但这次官方通报里 Git Operations 也在异常服务列表里。36氪也就是说，故障最严重的时候，连最原始的 push 都推不上去。这直接推翻了很多人心里的兜底假设：“API 挂了没关系，我还有 git。”
为什么终端用户是这次的重灾区
把 gh CLI 拆开看就明白了：gh 本质上是 github.com REST/GraphQL API 的命令行客户端。gh pr、gh issue、gh repo、gh api、gh run……几乎所有命令都在敲 api.github.com 的门。API 错误率 20% 意味着什么？意味着 gh 的大部分能力直接不可用，而且报的还是各种看起来像本地配置问题的错。
Copilot CLI 这类 AI 编程工具同样依赖 Copilot 后端，这次一并中断。再加上 Actions 停摆，那些把 Copilot CLI 非交互模式塞进 CI 流水线做 code review、自动修复的玩法，也全部停转。
换句话说，越是把"终端 + GitHub"玩得深的人，这次被卡得越死。这不是工具不好，而是我们的工作流把太多环节押在了单一平台的在线状态上。
宕机当晚，哪些事其实还能干
也不是全无还手之力。把当晚还能做的事列一下，你会发现它们全部不依赖 GitHub 在线：
本地 git 操作一切正常：commit、branch、rebase、diff、log，纯本地操作和 GitHub 一毛钱关系都没有；
本地已有的仓库内容完好，已 clone 的代码、已缓存的依赖照常可用；
Issue 和 PR 的描述完全可以先在本地用 Markdown 写好，恢复后粘贴提交；
判断故障进度靠 status.github.com，而不是靠刷新和重试。
真正的教训是：这些"还能干的事"，多数人平时根本没形成习惯。
灾备清单：现在就能做的 5 件事，按成本从低到高排
与其等下次宕机干瞪眼，不如趁记忆还新鲜把下面几件事做了。我按花费时间从低到高排了个序：
1. 给重要仓库加一个备份 remote（5 分钟）。 在 GitHub 之外找一个托管点（自建 Gitea、公司内网 GitLab 都行），`git remote add backup <地址>`，之后每天下班前顺手 `git push backup main`。真出事的时候，这就是你的逃生通道。
2. 核心仓库做 mirror 备份（10 分钟 + 定时任务）。 `git clone --mirror` 会把完整的refs、分支、标签全部抓下来，比普通 clone 更全。配个 cron 每周跑一次，成本几乎为零。注意 mirror 备份的是代码和提交历史，Issue 和 PR 不在其中——这个后面单独说。
3. 把"写在 GitHub 上"变成"写在本地、同步上去"（习惯成本）。 Issue 正文、PR 描述、Release Notes，先在本地 Markdown 里写好再贴。宕机的时候你至少不用对着空白网页干等。
4. 把状态页放进你的故障判断流程（0 成本）。 收藏 status.github.com，也可以看看它的 API。遇到 gh 报错先查状态页，确认是平台故障就停手等待，别重试——这次官方复盘已经证明了，重试风暴会把故障放大 10 倍。
5. 盘点你对 Actions 的依赖（半小时，团队向）。 用 `gh workflow list` 看看自己仓库里挂了哪些工作流，想想哪些一旦停摆会阻塞发布。个人项目无所谓，但对有发布节奏的团队，至少要清楚"GitHub 挂了我们的发布链路断在哪一环"。
至于 Issue 和 PR 这类数据的备份，目前没有什么轻量方案，真要较真的话只能靠 API 定期导出——对绝大多数个人用户，我的建议是接受这个风险，把精力放在代码本身的备份上。
另外给 AI 编程用户提一个进阶选项：Copilot CLI 支持通过 Ollama 接入本地模型，虽然效果和云端模型有差距，但"断网也能让 AI 帮着干活"这件事，在宕机之夜确实是个真实的备选。哔哩哔哩
Origin 来了，但现在还不是搬家的时候
最后说说 Origin。Cursor（今年 6 月被马斯克旗下公司以约 600 亿美元收购）在 8 月 17 日开始向全部付费计划推出 Origin 早期 Beta：代码仓库、PR、代码浏览、Code Review、Merge，外加和 Vercel、Depot、Buildkite 的集成。微博知乎它最聪明的设计是"GitHub 同步"：可以把 GitHub 仓库镜像到 Origin 里实时查看、评审，但推送仍然回到 GitHub，GitHub 还是权威数据源——外媒评价这是典型的"楔入式"策略，企业几乎零成本就能试用。36氪
但对 CLI 用户，我的判断很明确：现在不用动。理由有三。Origin 还是早期 Beta，连它自己的开发者都在 Hacker News 上承认"今天功能还很少"。36氪其次它目前的产品形态深度绑定 Cursor 编辑器，对终端党来说没有对应的成熟 CLI 和工具链。第三，它自己也把 GitHub 定位成权威源，现阶段更像是给 GitHub 加了个"观后镜"，而不是替代品。
值得持续观察的是它的方向：用收购来的 Graphite 的堆叠式 PR 机制，解决多个 AI Agent 高频并发提交导致的 PR 排队和冲突问题；以及"让 Agent 理解代码、自动把 PR 推进到可合并状态"。这些恰恰是 GitHub 官方也在做的事——竞争已经开始了，受益的是用户。
接下来值得盯的三个信号
GitHub 的后续整改落地。官方已列出 sidecar 扩容、重试退避、容量监控、区域故障转移四项整改，下次出大故障的间隔会不会拉长，看这几个的落地情况；
Agent 流量对基础设施的压力。Linear 最近发布的统计显示，接入 coding agent 的团队两年间周均 PR 数从 21 个涨到 65 个，全平台统计口径下 PR 总量比 2024 年中翻了一倍还多。知乎Agent 时代 GitHub 被"用爆"可能不是最后一次，容量问题会常态化；
Origin 未来几周的 Agent 集成进展。如果它真把"Agent 原生托管"做出来，再加上自己的 CLI，那才是 gh 用户需要认真重新评估的时候。
这次宕机最好的结局，不是"Cursor 杀死 GitHub"的段子成真，而是每个把工作流押在云端的人，都顺手给自己留了一条后路。5 分钟加个 backup remote，现在就可以做。
