本文要点
- 事故从北京时间 9 月 5 日 04:39 开始，影响级别为 major；GitHub 于 06:25 进入 monitoring，并在 06:26 宣布解决。
- 官方没有说明失败请求会自动补跑，也尚未在事故页给出详细根因分析；必须对事故窗口内的 PR 和自动任务逐一对账。
- 先保存组织、仓库、PR、触发入口、失败时间、HTTP 状态、request ID 与脱敏日志，停止无证据的重复触发。
- 把自动 Copilot 审查临时切换为人工 reviewer 或既有独立审查流程，不降低 required review 与测试门禁。
- 恢复后先在非关键 PR 请求一次最小复审，核对评论、完成状态、重复评论和计费，再逐步恢复自动审查。
- 固定出口不能修复 GitHub 服务端事故；只有其他 GitHub 请求也出现 DNS、TLS、407 或超时，才查网络路径。
先认定事故边界：总体 Operational 不能覆盖单项失败
GitHub Status 的独立 incident 记录显示，Copilot Code Review 中断从北京时间 2026 年 9 月 5 日 04:39 开始。04:57 官方确认部分用户使用 code review 可能失败、根因已识别；05:54 更新为正在应用缓解、预计约 30 分钟恢复，并把影响级别升级为 major。06:25 官方表示缓解完成并进入 monitoring，06:26 宣布事件已解决。
解决状态只说明服务端事件关闭，不证明事故窗口内每次 review 都已完成，也不代表失败任务会自动补跑。排障记录应保存 incident ID、观察时间和当时的 status/impact，并逐一核对受影响 PR。即使 Copilot 总组件显示 Operational，也应以具体事故时间线界定影响窗口。
第一步止损：冻结网络、证书、权限和自动重试变更
当官方已经确认服务端事故，同时改代理、CA、组织模型策略、仓库规则和账号会制造第二个故障。先冻结这些变量，记录受影响的组织、仓库、PR、reviewer 入口、客户端、失败时间、HTTP 状态、request ID 与脱敏错误。
自动规则如果持续请求 Copilot review，应暂停重复触发或设置明确间隔，避免堆积重复任务与额外 AI credits。结果未知的请求先看 PR 时间线和 review 状态，不要看到超时就马上重发。
审查不能空档：回退到人工 reviewer 与原有门禁
Copilot Code Review 的失败不应降低合并要求。把受阻 PR 分配给人工 reviewer，继续执行既有测试、静态检查、required reviews、CODEOWNERS 与高风险变更的双人复核；只延迟可以安全等待的自动审查。
官方文档说明可以在 GitHub.com 的 Reviewers 中请求 Copilot，也可以经 REST API 添加 reviewer。事故期间不要在多个入口反复触发同一个 PR；选择一个入口做恢复验证，其余保持人工流程。
恢复后怎么验：只用一个非关键 PR 做最小复审
官方进入 monitoring 或 resolved 后，先选一个无敏感数据、差异小、已有人工结论的非关键 PR。记录请求时间，只触发一次 Copilot review，核对是否出现 overview、评论是否完整、任务是否结束，以及是否重复旧评论。
GitHub 文档提醒，手动 re-review 需要从 Reviewers 重新请求；自动 review 只有配置 Review new pushes 才会在新提交后复审，而且复审可能重复已解决或已点踩的评论。恢复验收必须把重复评论和意外 credits 消耗纳入检查。
不要把 Copilot 结论当成唯一批准
默认情况下，Copilot 留下的是 Comment，不是 Approve 或 Request changes；它的 approval assessment 本身不计入 required approvals。即使组织开启了仍在 public preview 的 Copilot approvals，新提交也会让此前批准失效。
因此事故恢复不能以“页面重新出现一条评论”作为唯一完成条件。还要确认人工批准、required checks、分支保护和预期 reviewer 状态都正常，再恢复自动审查或合并关键 PR。
服务端、权限、预算与网络要分层
官方 incident 覆盖的是服务端失败。没有 Copilot Code Review 入口也可能来自组织策略未启用；达到用户、企业或成本中心预算会阻断消耗 AI credits 的功能；只有单个请求 401/403 时才先查权限和预算。
DNS 解析失败、TLS 握手错误、代理 407、TCP 超时或其他 GitHub/Copilot 请求也同时不可达，才进入网络层。通用企业代理、Kerberos 与 CA 可参考<a href="/resources/github-copilot-enterprise-proxy-ca-guide">GitHub Copilot 企业代理与 CA 指南</a>，不要用换 IP 解释已确认的服务端事故。
恢复完成标准与回滚条件
完成标准至少包括：官方状态进入 monitoring/resolved；最小 PR 的单次审查成功；评论、overview 和状态完整；没有重复副作用；人工门禁未被绕过；预算与 GitHub Actions 分钟没有异常。然后按少量仓库、部分自动规则、全量的顺序恢复。
如果官方重新转为 investigating、同类失败复发、review 卡住、评论重复、计费异常或 required review 状态不一致，应再次暂停自动审查并回到人工流程。确有独立网络证据时，可<a href="/" target="_blank" rel="noopener noreferrer">访问 PuppyIP 官网</a>了解固定出口；它只帮助复现连接路径，不能修复 GitHub 服务端。
资料来源
常见问题
GitHub Copilot Code Review 这次是本地配置问题吗？
GitHub Status 建立了独立事故、把影响升级为 major，并已于北京时间 06:26 宣布解决。事故窗口内的失败先按服务端中断处理，不要同时改代理、证书、权限和仓库规则。
事故期间可以一直重新请求 Copilot review 吗？
不建议。先检查 PR 时间线和结果状态，暂停自动重试或拉长间隔，避免重复任务、重复评论与额外 AI credits。
Copilot 审查失败后 PR 可以直接合并吗？
不能因此降低门禁。应切换人工 reviewer，并继续 required reviews、测试、静态检查和高风险变更的双人复核。
GitHub 显示恢复后怎么验证？
在一个非关键、差异小且已有人工结论的 PR 上只请求一次复审，确认 overview、评论、完成状态、重复评论与计费均正常。
Copilot 的 approval assessment 能替代 required approval 吗？
默认不能。它通常留下 Comment；approval assessment 本身不计入 required approvals，Copilot approvals 还处于 public preview 并受管理员配置影响。
换固定 IP 能修复这次 Code Review 中断吗？
不能修复 GitHub 服务端事故。只有其他 GitHub 请求也出现 DNS、TLS、407 或连接超时等独立证据时，固定出口才有网络诊断价值。