北京时间 8 月 17 日 21:40（UTC 13:40），全球最大代码托管平台 GitHub 触发异常告警。短短半小时内故障快速蔓延，几乎波及平台全部核心业务。而这已经是 GitHub 一个月以来发生的第二次大规模宕机事故。
故障逐级发酵，从性能卡顿蔓延至基础代码操作瘫痪
根据 GitHub 官方状态日志记录，本次事故的影响是逐层扩大的。
UTC 13:40，故障正式启动，平台首次通报性能受损。仅一分钟之后，API 请求服务率先降级，Actions、Webhooks、Issues 等功能接连出现异常。
13:58，官方披露了故障的量化数据：网页访问与 API 请求错误率约 20%，仓库归档、原始文件下载的报错率飙升至 50%。
14:24，故障蔓延至企业级服务。SAML、OIDC 登录认证、用户同步等功能中断，不少企业开发者甚至无法登录账号。
14:31，AI 编程助手 Copilot 也被划入受影响清单。
15:01，Pull Requests、Actions、Webhooks、API 等多项核心服务全部升级为重大中断。
15:21，最基础的 Git 操作开始失效，clone、fetch、push 等代码拉取与提交功能报错，开发者无法推送代码。
直至 16:36，GitHub 团队才锁定故障组件、启动修复，平台出现恢复迹象，但并未立刻全面回稳。第三方故障监测平台 Downdetector 数据显示，本次宕机的用户报错峰值接近 3000 条。截至事故结束，GitHub 所有服务恢复正常。
目前 GitHub 尚未对外公布宕机的根本诱因，仅承诺后续将会发布完整的事故复盘报告。
一月两度故障，AI 正在压垮 GitHub 基础设施？
这已经不是 GitHub 本月第一次出现重大事故。早在 8 月 6 日，GitHub Actions 就曾爆发长达 10 小时的故障，海量 CI/CD 任务积压，Webhook 接口遭到限流，那次事故影响时长远超本次宕机。
短短 30 天连续两次大规模中断，一个潜藏已久的行业问题彻底浮出水面：AI 编程浪潮正在急速拉高 GitHub 的负载压力。
随着编程智能体大规模普及，代码提交、自动审查、自动化测试都可以交由 AI 完成，GitHub Actions 流水线任务量两年内成倍暴涨。人类开发者一次代码提交，只会触发一条流水线；而 AI 智能体单次任务，就能产生数十次流水线请求。现如今平台基础设施所承受的压力，早已和三年前不可同日而语。
单点依赖风险敲响警钟，全行业的供应链隐患
对于广大开发者来说，宕机最致命的影响并不是网页无法打开，而是 Git 操作与 CI/CD 流水线瘫痪：代码拉取不到、线上版本无法发布、自动化部署全线叫停。如今大量企业已经将 GitHub 当作软件交付链路中不可跳过的一环，平台一旦停摆，项目当天就没法上线。
风险还会沿着产业链向外传导。当下很多 AI 编程工具、智能体框架都依托 GitHub 完成账号认证、代码调取、任务运行，Copilot 降级只是最直观的表象。当一个平台同时身兼代码仓库、身份认证中心、自动化执行引擎、AI 训练数据源四重身份，它任何一次微小故障，都能顺着上下游的依赖链条，放大成全行业的停摆危机。
此前被很多团队视作多余成本的多仓库镜像、异地备份、本地 CI 冗余方案，重新回到了开发者的备选清单。
这场宕机抛出了一个值得整个行业深思的问题：在 AI 生成代码爆发的时代，我们还能放心地将整条软件交付的命脉，押注在单一平台之上吗？