GitHub故障持续7小时47分:AI工具也需要“备用线路”

8月17日，GitHub一次故障处置持续7小时47分钟，网页和API最高错误率约20%，部分代码下载错误率约50%；VS Code的重试问题又将Copilot令牌服务的请求量放大约10倍。8月20日，ChatGPT也出现大面积服务异常。

HaiDatas · AI基础设施与业务连续性观察
核心来源：GitHub故障记录^[1] ｜ GitHub容量与可靠性说明^[2] ｜ OpenAI服务状态页^[3] ｜企业用户受影响情况^[4]
GitHub与ChatGPT是两起独立事件，现有信息不能证明二者相关，也不能据此判断AI服务整体故障率正在上升。

AI越能干，停下来时带走的工作就越多

如果聊天机器人暂时打不开，很多人可以晚一点再问。

但当AI已经接入代码仓库、企业知识库、客户系统和自动化流程，故障的含义就变了。员工可能还能写代码、整理资料，后面的审核、部署、查询和交付却无法继续。

8月17日的GitHub故障就是一个例子。部分开发者仍能推送代码，但拉取请求、Actions、身份验证和Copilot等功能同时受到影响。一些企业可以继续“写”，却无法审核、合并和部署。

8月20日，ChatGPT又出现登录、对话、历史记录和Codex等功能异常。据事发时报道，12个API接口也受到影响。

两次事件真正值得关注的，不是哪家平台更容易出错，而是一个更现实的问题：

当AI成为工作入口，企业有没有准备另一个出口？

7小时47分钟，四组数字说明了什么？

GitHub披露，8月17日13时28分至21时15分（UTC），GitHub.com持续出现错误率升高和延迟。

指标	GitHub披露的数据	它说明什么
故障处置时间	7小时47分钟	不同服务分阶段恢复，并非同时恢复
网页及API最高错误率	约20%	页面和自动化调用出现大范围不稳定
代码归档及原始内容下载错误率	约50%	构建、测试和部署更容易被卡住
Copilot令牌服务请求量	每秒7000—9000次升至7万—10万次	自动重试将流量放大约10倍

注：20%和50%是最高时点错误率，不代表所有功能在7小时47分钟内完全不可用。

故障最初出现在美国中部数据中心：一个负责转发请求的组件达到并发上限，自动扩容策略却没有正确监测这个限制，随后4个负载均衡节点耗尽连接容量，认证路径开始出现延迟和失败。

这不是AI模型本身“变笨”或“失控”，而是支撑AI工作的网络、认证和自动化系统出了问题。

这恰好说明企业使用的从来不只是一个模型，而是模型背后的一整套基础设施。

从10倍改到30倍：AI正在制造“机器流量”

GitHub早已意识到流量结构正在变化。

2025年10月，GitHub开始按现有规模的10倍扩容。到2026年2月，公司已经判断，未来需要按30倍规模重新设计。

主要变化之一，是AI辅助和Agent开发快速增长。同一名开发者可以同时让多个AI任务读取代码、创建分支、检查问题和运行测试。员工人数没有增加，底层API、权限、搜索、数据库和自动化任务的调用量却可能成倍增长。

一次拉取请求也不只是“提交一段代码”。它可能同时触发代码存储、权限检查、Actions、搜索、通知、Webhook、缓存和数据库。任何一个环节变慢，都可能继续影响其他环节。

因此，不能把8月17日事故简单归结为“AI流量导致GitHub故障”。最初原因仍是新流量峰值叠加扩容配置错误，Copilot重试主要放大了压力并拖慢恢复。

但它揭示了一个趋势：

过去，一个人只能以人的速度使用软件；现在，一个人可以指挥多个AI，以机器速度调用软件。

平台需要承受的，不再只是更多用户，还有每名用户背后越来越多的自动任务。

还能写代码，为什么公司却无法交付？

代码从电脑走到用户手里，要经过一条完整链路，编写→推送→审核→合并→ 自动测试→安全检查→部署。

GitHub已经不只是代码仓库。拉取请求负责审核，Actions负责测试和部署，身份系统决定谁有权限，Copilot又直接参与代码生成和修改。

这些功能集中在一个平台上，平时可以提高效率；当多个环节一起异常，开发者即使还能写代码，也无法把工作送到下一步。

企业想临时换平台同样困难。代码可以备份，真正难搬走的是自动化任务、权限规则、登录体系、插件和下游连接。一位受访企业用户估计，重建这些工作流可能需要数月。

这次故障还影响了部分使用数据驻留服务的企业。原因不是这些企业的数据离开了指定区域，而是其Actions任务需要从GitHub.com读取公共步骤定义。

这说明数据放在哪里，回答的是合规问题；平台故障时工作能不能继续，回答的是连续性问题。

数据能够备份，不代表流程能够立即切换。“市场上有其他模型”和“公司现在就能换过去”，也是两件不同的事。

AI停在半路，可能比完全打不开更麻烦

这次事故中最值得注意的，是约10倍的重试流量。

系统第一次请求失败后，通常会自动再试一次。但大量客户端同时反复重试，就像入口已经拥堵，门外的人反而一起加快敲门：失败制造更多请求，更多请求又制造更多失败。

AI工作流还多了一层风险。

一项任务可能包含读取资料、查询系统、修改记录、生成结果和发送通知五步。AI可能已经修改了记录，却在发送通知前超时。员工最后只看到“任务失败”，却不知道前面几步是否已经完成。

这就像付款页面一直转圈。最麻烦的不是明确告诉你付款失败，而是不知道钱究竟有没有扣。

此时直接重试，可能带来三个问题：

◆ 已完成的操作是否会被重复执行；

◆ 系统中的数据停在哪个版本；

◆ 下一步应该由AI继续，还是交给员工接管。

GitHub此次事件不能证明企业已经发生重复部署或重复修改。但约10倍的请求放大说明，当系统无法准确判断任务状态时，自动“再试一次”本身就可能成为新问题。

状态页恢复，不等于企业工作恢复

厂商宣布服务恢复，只代表平台重新可以访问。

故障期间积压的审核、失败的自动任务，以及不确定是否完成的操作，仍然需要核对。平台恢复用了多久，与企业清理积压、恢复交付用了多久，并不是同一个数字。

因此，企业评估AI可靠性不能只看在线率，还要看四层指标。

层级	应该记录什么
服务层	故障时长、错误率、响应时间
工作流层	中断任务数、失败步骤、待核验任务数
数据层	可导出比例、备份频率、版本恢复时间
业务层	人工接管率、积压量、积压清理时间

AI产生的净收益，也不能只计算正常运行时节省的时间，这是一套企业自查思路，不是用来推算此次事故经济损失的公式。

AI净收益 = 节省的时间 − 中断损失 − 恢复与返工成本 − 备用方案成本

备用线路不等于再买一整套系统

不是所有AI任务都需要第二套平台，企业可以按中断后果分级。

任务类型	典型场景	需要的准备
可以晚点完成	润色、头脑风暴	保存资料，等待恢复
可以人工接管	查询、分析、代码辅助	保留上下文、阶段结果和操作说明
不能停或会修改系统	客服发送、部署、审批、写入数据	限制重试、设置人工确认和替代路线

其中最关键的是给每项重要AI任务留一张“任务收据”：

◆ 谁发起了任务；

◆ 使用了哪些资料；

◆ 已经完成哪一步；

◆ 修改过哪些系统；

◆ 重试了几次；

◆ 接下来由机器继续还是人工接管。

运行日志通常写给技术人员看，“任务收据”则要让客服、运营、财务等普通员工也能看懂。

数据在这里不是为了事后做报表，而是为了让一项中断的工作能够安全地接着做。

数据边界

第一，GitHub与ChatGPT是两起独立事件，发生时间接近不代表原因相关。

第二，GitHub披露的是最高错误率，不能与7小时47分钟直接相乘推算影响规模。

第三，ChatGPT异常范围和持续时间应以OpenAI后续状态记录为准。

第四，企业部署暂停的案例不能代表所有企业，也不足以推算实际经济损失。

企业真正要备份的是工作链

AI故障过去意味着少用一个新功能，现在却可能意味着一项工作没有下一步。

这不是停止使用AI的理由，而是AI已经重要到需要被当作正式基础设施管理的信号。

企业评估AI，既要计算它正常运行时省下多少时间，也要计算它停止后会带走多少工作。真正的备用方案，不只是再买一个模型，而是保证资料能够取回、任务状态能够查清、自动重试能够停止、员工能够接手。

HaiDatas对这次故障的判断是，AI进入工作流之后，企业真正要备份的不是模型，而是一条能够被查清、被接管、被安全恢复的工作链。

数据来源

1. GitHub：8月17日服务故障记录^[1]

2. GitHub：容量规划从10倍调整到30倍^[2]

3. GitHub：2026年5月可用性与AI流量说明^[5]

4. GitHub：数据驻留环境复用GitHub.com Actions的说明^[6]

5. OpenAI服务状态页^[3]

6. IT之家：ChatGPT大面积服务异常^[7]

7. TechTarget：GitHub故障对企业开发与部署的影响^[4]

7小时47分钟、20%、50%、每秒7000—9000次和每秒7万—10万次来自GitHub故障记录；10倍与30倍容量规划来自GitHub公开说明；ChatGPT受影响功能及12个API接口异常来自事发时的状态页转述。“任务收据”和业务连续性框架为HaiDatas分析。

参考链接

[1] https://www.githubstatus.com/incidents/zkxwbgr0cnmx

[2] https://github.blog/news-insights/company-news/an-update-on-github-availability/

[3] https://status.openai.com/

[4] https://www.techtarget.com/it-infrastructure/news/366649459/GitHub-outage-had-users-weighing-options-but-finding-few

[5] https://github.blog/news-insights/company-news/github-availability-report-may-2026/

[6] https://docs.github.com/en/enterprise-cloud@latest/actions/how-tos/administer/reuse-namespaces-on-ghecom

[7] https://www.ithome.com/0/991/891.htm