GitHub 这次最容易被误读的地方，是它没有“全站趴下”。
代码还能推。API 还在。Pages 还能打开。Copilot 的模型供应商状态也没挂红。
但很多团队照样会被卡住：搜索超时，workflow runs 失败，Projects 加载不出来，Issues 和 Pull Requests 间歇性失败。更麻烦的是，Copilot Cloud Agent jobs 使用 Codex agent 后，任务启动即失败，官方建议先切到其他 agent。
这类故障不够戏剧化，却很接近真实的工程事故。
现代开发早就不是“仓库能不能打开”这么简单。你可以 git push，但搜不到上下文；你可以发 PR，但评审链路不稳定；你可以触发 CI，但 workflow 失败；你想让 agent 接手任务，它刚启动就倒下。
发生了什么：仓库还在，协作层在抖
状态页给出的时间窗口集中在 2026 年 4 月 27 日 16:31 到 17:35 UTC。GitHub 多次更新状态，措辞主要停在调查和缓解中。
关键信息不在“GitHub 挂了”，而在“哪些层同时 degraded”。
| 项目 | 状态页信息 | 直接影响 |
|---|---|---|
| Actions | 16:31 起调查性能下降 | workflow runs 失败或受阻 |
| Search | 16:33 确认搜索失败 | 请求超时，项目加载异常 |
| Issues / PR | 16:36、16:53 更新为 degraded | 协作、评审、排障被拖慢 |
| Packages | 16:39 更新为 degraded | 依赖发布和拉取链路受扰 |
| Copilot Cloud Agent | 使用 Codex agent 的任务启动后失败 | 官方建议切换其他 agent |
同时也要把边界说清：Git Operations、API、Pages、Copilot AI Model Providers 当时显示正常。
这点很重要。它把问题从“GitHub 是否全站宕机”修正为更准确的判断：GitHub 的核心仓库能力还在，但协作层、搜索层、CI 层、包管理链路和部分 AI agent 入口在同一时间段里出现抖动。
对开发者来说，这比一个红色大标题更有用。
因为真正影响工作节奏的，往往不是最底层的 git 操作，而是围绕代码流动的一整套流程。
谁受影响：不是普通访问者，是工程团队
普通用户可能只会觉得页面慢一点，甚至完全无感。
受影响更明显的是两类人。
一类是依赖 GitHub 做日常协作的团队。PR 看不了、Issue 打不开、搜索超时，排障就会变慢。代码在，语境没了。很多工程工作不是写一段新代码，而是在旧代码、旧讨论、旧决策里找线索。
另一类是把 Actions、Packages、Copilot agent 纳入自动化流程的团队。CI 跑不通，包发布受阻，agent 任务失败，影响的是交付节奏。不是“今天少用一个工具”，而是流程断了一截。
这也是这次线索补强旧判断的地方：受影响的不只是代码托管，而是从搜索、评审、CI、依赖到 AI agent 的开发链路。旧问题是“GitHub 多项服务异常”；新信息把异常的位置钉得更准，也把影响对象缩得更清楚。
没有必要夸大成灾难。现在看不到数据丢失，也看不到全站崩溃。
但也不能轻描淡写。开发平台的局部故障，会在组织里放大。
为什么重要：高可用数字挡不住链路依赖
GitHub 状态页还给了 90 天游标：Actions 99.37%，Codespaces 99.48%，Copilot 99.69%。
这些数字不难看。放在云服务里，甚至算正常。
问题是，工程团队依赖 GitHub 的方式已经变了。
过去 GitHub 是代码仓库。后来它是协作平台。Actions 把 CI/CD 拉进来，Packages 接住制品和依赖，Projects 承接管理，Copilot 和 agent 又开始进入写代码、改代码、跑任务的过程。
平台越像操作系统，局部故障越不像局部故障。
这有点像铁路。不完全一样，但结构相似。铁轨没断，车站没塌，可调度系统、信号系统、售票系统一起卡顿，乘客照样走不了。
今天的 GitHub 也是这样。Git Operations 正常，只能说明铁轨还在；Search、PR、Actions、Packages 抖动，说明调度室在冒烟。
很多团队平时追求的是顺手：少搭系统，少管集成，少维护胶水代码。GitHub 正好把这些事包成一套体验。
这套体验确实值钱。问题也从这里长出来。
“天下熙熙，皆为利来。”开发者把流程交给平台，是因为效率真高；风险并不是效率的反面，风险就藏在效率里面。
AI agent 让故障边界又往外推了一圈
我更在意 Copilot Cloud Agent / Codex agent 这条线。
官方说得很窄：使用 Codex agent 的 CCA jobs 在启动后失败，临时办法是选择其他 agent。
这不能扩大成“整个 Copilot 不可用”。状态页上 Copilot 和 Copilot AI Model Providers 当时仍显示正常。把窄故障说成大崩盘，是不负责任。
但这条窄故障已经足够说明趋势。
AI 编程工具如果只是补全框，坏了也就少几行建议。开发者还能自己写。
AI agent 一旦开始负责开分支、改 PR、跑测试、处理 issue，它就不再只是辅助功能。它会进入团队排期，进入自动化链路，进入老板以为“已经可以省掉人手”的那部分想象。
这时候 agent 坏掉，就会像 CI 坏掉一样，被写进团队节奏表。
这才是平台公司的甜蜜陷阱。功能越集中，用户越省心；链路越集中，故障越有杀伤力。
我不反对把 GitHub 当主平台。说“逃离 GitHub”很容易，真做起来成本高，收益也未必够。
更现实的做法是给关键链路留降级方案：
- CI 是否能临时迁移，至少关键构建不能只押一个入口；
- 依赖和制品是否有缓存，Packages 抖动时不要连本地构建都被拖死；
- Issue、PR、搜索信息是否有最低限度的备份或同步；
- AI agent 是否能切换到其他 agent，或快速退回人工流程。
这不是末日准备。只是工程基本盘。
真正成熟的团队，不是永远不用平台，而是知道平台什么时候会反客为主。
接下来该看什么：不是恢复公告，而是故障边界
这类事故后，最该看的不是一句“服务已恢复”。那只是结尾，不是答案。
更该看三件事。
第一，Actions 和 Packages 的恢复是否稳定。它们牵涉构建、发布、依赖拉取，影响面比页面访问更深。
第二，Search、Issues、PR 的 degraded 是否反复出现。协作层故障最烦人，不一定让系统停机，却会让人停工。
第三，Copilot Cloud Agent 对 Codex agent 的失败是否只是短时 bug，还是暴露了 agent 编排、任务启动、模型路由之间的脆弱连接。
如果只是一次短抖，影响会很快过去。
如果同类问题在高频开发平台上反复出现，团队就要重新算账：省下来的集成成本，是否正在换成更隐蔽的停顿成本。
GitHub 这次没有全站宕机。正因为没有全站宕机，它才更像一次真实演练。
仓库还在，流程却卡住了。
这就是今天开发基础设施最值得警惕的地方：我们以为自己依赖的是一个网站，实际依赖的是一条生产线。