服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 事故从北京时间 9 月 5 日 04:39 开始，影响级别为 major；GitHub 于 06:25 进入 monitoring，并在 06:26 宣布解决。
- 官方现已确认根因是服务认证权限变更，导致受影响的审查无法提交到 GitHub API；回退该变更后恢复。事故页没有承诺失败审查会自动补跑，仍须逐 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 宣布事件已解决。
GitHub 后续在同一事故页说明：服务的认证权限发生变更，使受影响的 review 无法提交到 GitHub API；GitHub 回退了该变更，并于 9 月 4 日 22:26 UTC（北京时间 9 月 5 日 06:26）恢复正常。这里说的是 GitHub 服务侧提交审查的权限，不是用户仓库或个人账号的权限配置。
解决状态只说明服务端事件关闭，不证明事故窗口内每次 review 都已完成，也不代表失败任务会自动补跑；官方没有给出自动重试保证。排障记录应保存 incident ID、观察时间和当时的 status/impact，并逐一核对受影响 PR。即使 Copilot 总组件显示 Operational，也应以具体事故时间线界定影响窗口。
第一步止损：冻结网络、证书、权限和自动重试变更
已确认的问题发生在 GitHub 服务提交 review 到 API 的认证权限，不能据此推断你自己的账号缺权。事故期间同时改代理、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 可参考GitHub Copilot 企业代理与 CA 指南，不要用换 IP 解释已确认的服务端事故。
恢复完成标准与回滚条件
完成标准至少包括：官方状态进入 monitoring/resolved；最小 PR 的单次审查成功；评论、overview 和状态完整；没有重复副作用；人工门禁未被绕过；预算与 GitHub Actions 分钟没有异常。然后按少量仓库、部分自动规则、全量的顺序恢复。
如果官方重新转为 investigating、同类失败复发、review 卡住、评论重复、计费异常或 required review 状态不一致，应再次暂停自动审查并回到人工流程。确有独立网络证据时，可访问 PuppyIP 官网了解固定出口；它只帮助复现连接路径，不能修复 GitHub 服务端。
资料来源
常见问题
GitHub Copilot Code Review 这次是本地配置问题吗？
不是已确认的本地配置问题。GitHub Status 说明服务认证权限变更使受影响的 review 无法提交到 GitHub API，回退后于北京时间 06:26 恢复。不要因此修改用户账号、代理、证书或仓库规则。
官方确认的根因是什么，失败审查会自动补跑吗？
根因是 GitHub 服务的认证权限变更，阻止受影响的 Copilot review 提交到 GitHub API；GitHub 已回退变更。事故页没有承诺失败任务会自动补跑，应逐一核对事故窗口内的 PR，并在需要时按正常入口请求一次复审。
事故期间可以一直重新请求 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 或连接超时等独立证据时，固定出口才有网络诊断价值。