6 月 10 日这次 GitHub 故障，最容易被看错的地方是 401。
平时看到 401，很多团队第一反应是 token 过期、权限错了，甚至怀疑凭据出了问题。但这次 GitHub 给出的说法更具体：API 请求出现 sporadic authentication failures，也就是间歇性认证失败，部分请求收到了错误的 401 响应。
事件从 15:20 UTC 开始通报，到 16:39 UTC 标记解决。按北京时间算，大约是 6 月 10 日 23:20 到 6 月 11 日 00:39。官方称约 15% API 流量受影响，范围包括 API Requests 和 Issues。
我的判断很简单：这不是 GitHub 全站不可用，也不能读成 15% 用户或 15% 仓库受影响。它更像是一次打在自动化链路上的平台侧故障。
79 分钟里，问题集中在 API 和 Issues
从状态页节奏看，GitHub 先通报部分服务性能问题，随后把范围收敛到 API Requests 和 Issues。核心症状是 API 请求间歇性认证失败。
关键时间线可以压成这张表：
| 时间（UTC） | 官方状态变化 | 对开发者的含义 |
|---|---|---|
| 15:20 | 开始调查部分 GitHub 服务性能问题 | 监控可能开始报错，但范围还不清楚 |
| 15:27 | API Requests 可用性下降，Issues 性能下降 | API 调用、议题相关操作可能不稳定 |
| 15:46 | 确认约 15% API 流量受间歇性认证失败影响；Issues 缓解 | 401 更可能来自平台侧，不宜立刻重置所有凭据 |
| 16:21 | 错误 401 导致应用集成触发认证流程；已识别问题组件 | GitHub App、机器人、CI/CD 可能反复重试或误判 |
| 16:36 | API Requests 降级被标记为缓解 | 失败率应开始回落 |
| 16:39 | 事件标记解决 | 进入排查积压任务和等待 RCA 的阶段 |
这张表里最要紧的是两点。
一是 15% 指的是 API 流量，不是用户数，也不是仓库数。把它说成“15% GitHub 用户受影响”，就已经偏了。
二是 401 在这次事件里不等于凭据泄露。官方说的是错误响应，并表示已识别基础设施中的问题组件。详细 RCA 还没出来，根因不能替 GitHub 先写。
真正麻烦的是集成链路，不是普通网页访问
普通用户刷网页、看仓库、打开代码页面，未必能明显感到这次故障。受影响更大的，是把 GitHub API 当工作流入口的人。
比如两类团队会比较难受。
| 受影响对象 | 可能看到什么 | 更稳妥的动作 |
|---|---|---|
| 维护 GitHub App、机器人、发布脚本的团队 | 401、授权流程反复触发、任务重试、事件漏处理 | 回看 15:20-16:39 UTC 的失败请求，不要把所有 401 都当成 token 失效 |
| 依赖 GitHub API 的 CI/CD 团队 | 构建卡住、部署延迟、PR 或 Issues 触发流程异常 | 检查失败 job、重跑必要任务，确认是否有被错误跳过的发布或回滚 |
这类故障的麻烦，不在于页面多难看，而在于它会让机器误会机器。
一个 API 返回 401，内部系统可能会自动刷新授权、撤销凭据、重试队列，或者把平台侧异常报成自家配置事故。人看到的是一条失败日志，后面可能已经堆了几十个自动动作。
所以对开发者来说，最现实的处理不是“GitHub 挂了”四个字，而是三件事：查失败窗口、重跑关键任务、压住误报。
如果团队在这个时间段有发布、热修复、跨时区协作，79 分钟并不短。它足够让一次部署排队，也足够让一个机器人漏掉 Issues 或 Pull Request 事件。
现在别猜根因，要等 RCA 解释两个问题
GitHub 目前只说已经识别基础设施中的问题组件，并会在后续提供 RCA。到这一步，能判断影响，不能替它判断根因。
接下来最该看两件事。
一是错误 401 怎么产生。它到底发生在认证服务、缓存、请求路由，还是别的基础设施组件上，目前没有公开细节。
二是为什么影响约 15% API 流量。这个比例说明问题不是全量故障，但也不是可以忽略的小毛刺。它可能和流量分片、组件路径或请求类型有关，但现在只能等官方 RCA 确认。
这两个问题会影响第三方集成怎么改。
如果系统把所有 401 都写死成“凭据失效”，这次就会误伤。更合理的做法，是在平台故障窗口内保留错误分类：真实权限问题是一类，平台侧异常响应是另一类。
对维护 GitHub App 和 CI/CD 的团队，我更建议现在做四个检查：
- 拉出 15.20 到 16:39 UTC 的 API 401 日志，标记为平台故障窗口。
- 检查 GitHub App 是否产生异常授权请求，避免误导用户重新授权。
- 复核 CI/CD、发布机器人、Issues 和 PR 自动化流程，确认有没有漏跑或重复跑。
- 等 RCA 出来后，再决定是否调整重试、退避、告警和 401 处理规则。
这也是这次故障给人的提醒：平台恢复，不等于你的自动化链路已经恢复。状态页只能告诉你火灭了，不能替你清掉队列里的烟。