有人在Hacker News上发帖吐槽,GitHub页面弹出一行提示:"没有可用的服务器来处理你的请求"。发帖那一刻,官方状态页githubstatus.com还是全绿,什么事故都没挂。几分钟后,状态页更新,一条编号为zkxwbgr0cnmx的事故出现,标题从"GitHub Overloaded"改成了官方措辞更委婉的"Degraded Performance"。
这中间的落差,才是这次故障真正有意思的地方。用户看到的是页面报错、PR合不上、Copilot掉线,一条普通的"又崩了"吐槽帖;而官方后台记录的,是一次被自己标注为critical级别的系统性事故。
故障链条比想象中长
按官方事故时间线,问题从API请求开始,API Requests先出现降级,一分钟后GitHub Actions跟着降级,再过两分钟Webhooks沦陷,随后Issues和Pull Requests相继报错。半小时后,SAML、OIDC认证及SCIM同步这类企业级登录服务被确认受影响,再过几分钟,Copilot可用性下降。从第一个组件报警到Copilot出问题,整个链条只用了51分钟。
这不是"网页卡了"那么简单。CI/CD流水线、代码协作、企业单点登录、AI编程助手,四条业务线几乎同时中招。对依赖GitHub Actions自动部署的团队,这意味着发布卡住;对用企业版SSO登录的公司,这意味着团队级协作直接瘫痪。
20%这个数字,分歧在哪
官方给出的错误率有分层:网页和API请求错误率约20%,归档下载与原始仓库内容下载的错误率约50%。评论区有人质疑这个20%是不是"随便编的数字",但检索到的状态页数据证实,官方确实报的就是这个口径——问题不在数字造假,而在这个百分比怎么理解。
另一位用户测试多个地区和VPN后表示,实际感受到的失败率远高于20%。这个矛盾其实有解:页面加载牵涉几十个请求,20%是整体失败比例,但真正决定页面能不能用的那几个关键请求,失败率可能接近百分之百。20%的错误率,足以让一个协作工具变得不可用——平均数从来救不了体验。
- 提醒.官方的平均错误率和用户的实际体感可能相差很大,关键路径请求往往比整体数字惨烈得多。
georgehotz要走,是情绪还是趋势
tinygrad作者georgehotz在这轮吐槽里宣布,团队要转向自托管的Gitea,理由是"借助LLM做devops从来没这么容易过"。这句话背后是两件事在同时发生:GitHub的可靠性问题反复出现,同时大模型正在把自建Git服务的门槛拉低——过去需要专职运维才能搞定的证书、备份、权限体系,现在配合LLM辅助,一个小团队也能应付。
这不代表自托管会成为主流。GitHub的护城河从来不是稳定性,而是网络效应:开源生态、CI集成、招聘时看简历里的GitHub主页,这些沉没成本比一次故障重得多。但对少数已经有能力和意愿自建的团队,LLM降低的运维门槛,确实让"离开GitHub"从一句气话,变成了一个可以真的算成本账的选项。
命脉系于一家平台的代价,平时看不见,出事时全账单一起结。
这次事故最该被记住的,不是页面报错的截图,也不是评论区吵的20%该怎么算,而是认证服务和代码托管、CI/CD、AI助手被绑在同一套底层架构上这件事——一旦核心组件出问题,连登录都成了牺牲品。企业客户要看的不是这次多久修复,而是GitHub会不会公开真正的根因复盘;普通开发者能做的,大概只是记住PR卡住时,先看状态页,再骂人。