摘要
- GitHub 在 03:53:19 UTC 报告 API 请求性能下降。
- 事故标题明确写 GraphQL API Requests，状态更新则使用更宽的 API Requests 表述。
- 04:09:01 UTC 发布缓解，04:09:10 发布解决，距离首次通知约 16 分钟。
- 公开记录没有量化失败请求比例、受影响客户数或地区。
- GitHub 表示将提供详细根因分析，但本次查看的事故记录中尚未出现。
16 分钟很短，但自动化队列按失败次数而非分钟计价。供应商恢复服务之后，客户侧仍可能留下失败作业、退避等待、重复尝试和需要人工重新启动的任务。
GitHub 把事故起点记录为 03:53:19 UTC，04:09:01 发布缓解，九秒后于 04:09:10 发布解决。可见供应商事故窗口约为 16 分钟。
时间线非常精确，范围用词却没有同等精度。标题是 GraphQL API Requests，更新内容写 API Requests。报道不能自行选择更宽或更窄的含义，应同时保留两种原始表述。
标题确定中心，不确定全部边界
GraphQL 是一项具体 API 界面，客户通过它请求结构化数据。看板、集成、仓库工具和内部自动化都可能依赖该界面。
若只有 GraphQL 下降，REST 或其他服务可能表现不同。若更新中的宽泛表述代表更广问题，标题也可能只描述最初可见组件。状态页没有提供足够信息裁决。
稳妥叙述应以具名 GraphQL 事故为中心，同时标明更新用词更宽。不能因此声称 GitHub 所有 API 都失败。
记录也没有给出请求失败率、客户数量、地理范围或延迟分布。短时间内既可能只有低比例错误，也可能出现尖峰，公开信息无法区分。
客户恢复成本由调用和作业决定
交互用户可以刷新页面后继续，自动化系统可能让一个计划任务失败、按退避策略等待，或因快速重试增加自身负载。
供应商发布解决，不会自动重放客户工作。有些作业会按策略重试，有些保持失败状态，有些必须人工启动。
涉及状态变化的调用还需检查幂等性。服务器可能拒绝动作，也可能在响应丢失之前已经完成，或已接受异步处理。未核对就重复，可能产生双重结果。
因此，客户恢复可以超过约 16 分钟。真正的剩余工作单位，是尚无可信最终状态的请求和任务，而不是事故页上的分钟数。
解决可用性，不等于解释原因
缓解和解决更新表示 GitHub 观察到恢复并关闭活动事故。它们没有说明触发因素。
状态记录承诺后续提供详细根因分析，但查看时尚未发布。因此不能把事故归因于基础设施、发布、容量或某个下游依赖。
后续说明应给出受影响组件、触发点、发现方式、缓解措施、防护改变和准确影响指标，也应说明 API Requests 是否只是 GraphQL 的简称。
客户可以检查 03:53:19 至 04:09:10 UTC 之间以及之后的重试日志。失败、延迟、重复动作和未处理队列，才是自身影响的证据。
GitHub 快速恢复了可见服务，这一点可以明确肯定。同样需要明确的是：约 16 分钟只回答事故时长，工作流成本、技术根因和准确 API 范围尚未由状态文字解决。