8月17日大概是代码托管行业史上最拥挤的一天。
UTC时间13:40（北京时间21:40），GitHub开始今年最大的一次宕机，Issues、PR、Actions、Webhooks、Copilot、企业SSO挨个倒下，直到21:15 UTC才全部恢复。微博同样是这天，GitLab打破每月两次的常规补丁节奏，紧急发布非周期安全更新，修一个CVSS 9.4的严重漏洞——攻击者不需要任何认证，一条HTTP请求就能删掉实例上所有公开项目。知乎还是这天，Cursor把酝酿已久的代码托管平台Origin推给了付费用户，时机准得像提前写好的剧本。知乎
三件事撞在同一天，但对我们这种一线干活的运维来说，热度排序不等于处理顺序。看完十几个信源的交叉信息后，我的结论是：先救火，再补墙，最后才轮到看热闹。
第一件事：查你的自建GitLab，这是本周唯一的"救火级"事项
先说清楚谁需要慌：只用GitLab.com或者GitLab Dedicated的可以跳过，官方云端已经自动打了补丁。压力全部落在自建、自维护的GitLab CE/EE实例上。知乎
这次修的CVE-2026-19478，CVSS向量是AV:N/AC:L/PR:N/UI:N——翻译成人话就是：不需要登录、不需要交互、不需要任何权限，只要你的GitLab暴露在公网，攻击者就能通过GraphQL接口删除公开项目、篡改用户账号状态、修改项目配置。知乎而且删除是物理级的，没有回收站，仓库、提交记录、CI配置、Issue、Wiki一起消失。知乎据安全研究者的分析，漏洞出在GraphQL自定义指令的fallback降级分支上，这段逻辑直接跳过了全部身份认证和权限校验。
受影响的版本区间记一下：18.2到18.11.11之前、19.0到19.0.8之前、19.1到19.1.6之前、19.2到19.2.4之前。修复版本就是每条线的上限：18.11.11、19.0.8、19.1.6、19.2.4（极狐GitLab对应的补丁是8月19日发的）。知乎按国内安全厂商奇安信鹰图的测绘，国内暴露在公网的风险GitLab资产超过10万个，POC已经公开，批量扫描工具在扩散——这不是"找时间再升"的漏洞。知乎
好消息是这次升级成本极低：补丁不含数据库迁移，多节点部署可以零停机热升级。唯一要注意的坑是，Omnibus安装方式默认会在升级时停服务跑迁移，想保持不停机得提前放一个`/etc/gitlab/skip-auto-reconfigure`文件。知乎
如果生产环境确实动不了，有两个临时止损手段：一是把所有Public项目批量改成私有或内部可见——这个漏洞的利用前提就是存在公开项目，实例里一个公开项目都没有，攻击者触发不了任何破坏动作；二是在防火墙或反向代理层拦掉匿名访问`/api/graphql`的请求。但这两招都只是争取时间，官方明确说了没有配置开关能关掉漏洞，升级是唯一根治方案。知乎另外同批还有一个CVE-2026-19650（CVSS 7.1），能让GET请求触发mutation搞CSRF，必须一起打补丁。知乎
升级完也别直接收工：翻一下最近30天的项目删除和配置修改日志，确认这段时间没人动过手脚。
第二件事：GitHub这次宕机的根因，值得每个把CI/CD押在它上面的团队看一遍
官方复盘是CTO Vlad Fedorov在8月20日发的，结论很直白：不是代码问题，不是配置变更，就是容量——流量冲到新峰值时，美国中西部数据中心一个关键组件没有同步扩容，压力扩散到认证系统，然后连锁塌方。知乎
几个数字值得咂摸：峰值时网页和API的请求错误率约20%，仓库归档和原始文件下载的错误率约50%（注意这是请求级口径，不等于一半用户掉线）；更麻烦的是恢复阶段，Copilot客户端的重试循环反过来把流量越推越高，GitHub不得不先部分禁用认证令牌重试，才敢把服务放出来。微博知乎
为什么容量会跟不上？因为AI编程把流量结构改了：官方承认4月以来月提交量从14亿涨到29亿，接近翻倍；GitHub这两年加装了超过300万CPU核和120PB高速存储，Azure承载的平台负载从5月的12%拉到了58%，还是在追。知乎翻翻它今年的账本：6月6起事故、7月8起，7月8日那次中断7小时、峰值5xx错误率96%，8月6日Actions长时间故障被官方自己定性为"影响与时长均不可接受"。这次已经是8月第二起重大事故。
对DevOps的启示其实很朴素：当GitHub挂掉时，你的交付链是多点同时断的——代码拉不下来、PR开不了、Actions跑不动、Webhook断流，连企业SSO都进不去。Hacker News上"Ask HN: Alternatives to GitHub"的讨论帖拿了479分，但目前没有证据出现成规模的迁移潮，原因也简单：GitHub的护城河不是Git，是Actions、Copilot、Dependabot这些搬不走的东西。知乎
所以现阶段更划算的不是迁移，而是最低成本的冗余：给关键仓库加一个mirror远端，确认备份恢复流程真的跑通过一次。知乎这部分投入一天能干完，但它决定了下次GitHub趴窝时你是"等恢复"还是"照常干活"。
第三件事：Cursor Origin别急着搬，但这事儿本身的信号值得盯
Origin的定位官方说得很清楚：面向Agent时代的Git forge。哔哩哔哩它默认的模式是镜像同步——把GitHub仓库镜像过来，GitHub依然是权威数据源，你在Origin里push的内容会转发回GitHub，PR和评论双向同步。知乎但Issues、Actions工作流、Secrets都不跟过来。知乎
它真正有意思的部分全是为多Agent并行设计的：堆叠式PR（去年收购的Graphite的看家本领）、给并发PR自动排序查冲突的合并队列、AI自动解决冲突、机器可读的审查状态API。知乎官方演示的性能数字很吓人——每小时29.6万次克隆、8.1万次push、单仓库每秒22.6次提交——但没公布完整测试条件，听听就好。知乎
给三个判断，对号入座：
现在别把Origin当GitHub的灾备。镜像模式下权威数据源还在GitHub，GitHub挂了，你的镜像仓库也推不上去。它解决的是Agent工作流，不是高可用。知乎
已经在用Cursor Cloud Agent、跑多Agent并发的团队，可以零成本试。镜像同步不用搬家，Pro方案20美元一个月本来就包含，跑两周看看堆叠PR和合并队列对自己的Agent工作流是不是真提效。知乎
不用Origin的团队，把它当风向标看。今年3月The Information曝OpenAI在秘密开发自己的代码托管平台。微博5月Ghostty作者Mitchell Hashimoto发长文告别用了18年的GitHub。微博现在Cursor下场——头部AI编程公司集体开始怀疑"代码放在GitHub"这件事的可靠性。这个趋势如果持续，明年你的选型清单上大概率会多出两三个名字。
最后，把本周的事排个序
今天：查自建GitLab版本，落在受影响区间的，安排本周内升级到修复版本；升不了的，先把公开项目转私有、把`/api/graphql`的匿名访问拦掉。
本周：给关键仓库加镜像远端，验证一次备份恢复。
持续盯：CVE-2026-19478的在野利用情况、GitHub下个月的可用性报告、Origin什么时候补上Issues和原生CI。
这一周的三件事看着热闹，本质上只讲了一件事：AI把代码生产的速度提上去之后，托管层的安全和容量账单，开始集中到期了。
