GitHub Actions与Pull Requests遭遇服务中断
Incident with Actions, Pull Requests and Issues
GitHub官方状态页确认，Actions、Issues和Pull Requests等核心功能出现性能下降。用户反馈在加载Actions标签页、调用Checks API、排队新运行任务以及创建或更新Issues时遇到延迟和错误，REST和GraphQL API也受影响。团队已介入调查并实施初步缓解措施，但部分问题仍未完全恢复，Web通知也可能延迟。此次事件影响范围广泛，涉及开发者日常协作的关键环节，GitHub正持续排查根本原因并推进进一步修复。
我们的初步缓解措施并未完全成功，用户可能仍会在使用Actions、Issues和Projects时遇到延迟和错误，通知也会出现延迟。
HN 评论区
131- bearjaws
大家总想踩 GitHub，但说实话，从每天 5000 万 <thing> 暴增到每天 20 亿 <thing>，几乎能搞垮任何系统。哪怕这增长发生在不到 8 个月的时间里，很多东西也会接连崩盘，等你修好一个，下一个多米诺骨牌又倒了。
我很同情这个团队，但这对所有人来说都是绝佳的学习成长机会。
- orsenthil
是啊，昨天我才让 Claude 帮我构建并部署了一个端到端的项目，只要任何开源项目有提交，它就能让我家的 Lifx 灯泡闪烁。今天早上我发现它昨天太平洋时间晚上 11 点左右就停了。我当时就在想这是为什么，同时也好奇：几分钟内就能搞定这样一个完整可用的项目，到底是什么在阻止人们每天做上百个这样的项目？GitHub 根本不是为这种场景设计的。
- mglvsky
他们为什么不给个提示，比如‘请让整个系统更可靠，别犯错了’？
- zanderwohl
我一直没搞懂，现在还是没搞懂，为什么大家都把自己锁死在 GitHub 的 CI/CD 流程里。在通用的 Docker 环境里配置检查并不难。我有一台家用服务器，用来跑所有的构建和检查，还配了 GitHub Actions 配置，万一我连不上家里的 VPN，就手动触发。
除了更可靠之外，在自己控制的机器上跑就是更快。
- loveparade
我觉得如果哪天 GitHub 没出任何故障，那才是发 HN 讨论的好时机。
- throwitaway222
也许他们应该推出 Actions Free 和 Actions Plus 版本。Actions Free 包含当前产品的所有功能，但 UI 上的更新会有延迟。甚至可以改成 Actions Free/Plus 把更新推送到你自己的代理基础设施上。只需配置一个 URL，所有 Actions 的更新都会发过去。
- fschuett
我在我的部分项目里禁用了 CI，现在需要单独发一条'ci run'的评论来启动 CI。我发现 CI 在‘每次提交/推送’时自动运行越来越烦人，因为我其实只需要它在 prod-release 时变绿，而不是每次提交都跑。
- kqgnkqgn
鉴于 GitHub 似乎一直面临这些扩展性挑战，在我看来，以下两点必居其一：
1) 要么他们在运营大规模基础设施方面，不如其他大型科技公司有能力；
2) 要么 git 本身带来了独特的挑战，使得扩展变得更为困难。
我认为第 2 点的可能性远大于第 1 点。
那为什么还要死守 git 呢？如果从头开始，有没有可能设计出一个扩展性更好的新版本控制系统（VCS）？
显然，推广新东西会有难度。但 GitHub 的市场份额足够大，理论上完全有可能做到这一点。特别是利用成本或可靠性来激励迁移。
（虽然我不确定这对整个社区是否一定是好事，但我认为对 GitHub 来说是个好主意。）