先说结论当你看到 GitHub 官方状态页出现 “GitHub Actions and Pages are experiencing degraded availability” 时说明 GitHub 的 Actions 和 Pages 服务正在降级不是你的网络、你的仓库、你的电脑出了问题。这个状态提示在 GitHub 服务状态页里属于“可用性降级”比“服务中断”轻一些但 Actions 任务会变慢、排队变长Pages 站点也可能会出现构建不更新、部署失败、访问 5xx 等情况。这次我们就把这条公告拆开讲清楚它影响什么、怎么确认自己是不是被波及、Actions 和 Pages 分别要怎么排查、服务恢复后要做哪些检查、以及团队怎么从架构上降低对这种单点依赖的敏感度。补充一句全文只讨论 GitHub 官方服务状态和本地排查方法不涉及任何非官方访问方式。1. 核心能力速览先给一张“速览表”大家对照自己的使用场景快速定位影响。项目说明事件类别GitHub Actions / GitHub Pages 可用性降级典型现象工作流排队、构建延迟、Pages 更新不生效、部署失败确认来源GitHub 官方状态页 status.github.com受影响对象使用 GitHub Actions 的 CI/CD 团队、使用 Pages 托管静态站/文档站的个人和团队不受影响对象GitHub 仓库代码托管、Issue、PR 的基础功能通常仍可用但不保证所有模块都正常第一优先级操作打开状态页确认、查看 Actions 排队详情、查看 Pages 构建日志推荐检查工具gh CLI、curl、aapanel 或 UptimeRobot 等状态监控服务降低依赖手段本地构建产物备份、优先级队列调整、自建 Runner、备用静态托管这张表里的“通常仍可用”不是绝对保证遇到故障时应该以状态页和实际请求返回为准。2. 这条状态公告到底在说什么GitHub 状态页对服务状态的描述分为几档operational正常运行、degraded performance性能降级、partial outage部分服务中断、major outage重大服务中断。“experiencing degraded availability” 落在“性能降级”这一档。它的意思是服务还在但表现出明显的性能下降或部分请求失败。这也是为什么你可能会看到奇奇怪怪的“间歇性 503”和“卡在 queued 里的 Actions 任务”。对 Actions 和 Pages 来说降级通常体现在下面几个方向Actions 工作流长时间停留在 queued 状态Runner 不领取任务。工作流运行中途失败错误信息里没有明确的代码错误而是网络超时、连接被重置。Pages 提交 push 后站点迟迟不触发构建。Pages 构建完成后访问站点仍然返回旧内容。自定义域名的 HTTPS 证书刷新变慢或站点偶尔出现 5xx。严格来说这些现象背后可能各有原因但当你发现多个现象同时出现、并且状态页出现降级公告时应该先按“服务端故障”处理而不是先改代码。这段时间里的每一次失败GitHub 团队通常会在状态页更新调查进度。这些更新是开发者和运维判断“是否恢复”的最直接依据。3. 先确认是 GitHub 故障还是自家网络问题很多用户遇到 Actions 排队、Pages 打不开第一反应是“本地网络有问题”或者“代码有问题”。正确顺序应该是先看服务端状态再做本地验证。3.1 打开官方状态页直接访问 GitHub 官方状态页。如果状态页上已经挂出 Announcement说明服务端异常是公开的不必再反复重启、重推代码。3.2 用命令行快速确认连通性只访问网页不够因为浏览器缓存、DNS 缓存都会干扰判断。用命令行看响应头更直接# 检查 GitHub 主站响应 curl -I https://github.com -o /dev/null -s -w http_code:%{http_code}\n # 检查 API 响应GitHub API 返回 200 说明 API 层基本正常 curl -s https://api.github.com/rate_limit | head -20更推荐直接观察响应时间和状态码curl -s -o /dev/null -w time_total:%{time_total} http_code:%{http_code}\n https://api.github.com如果返回的 http_code 是 200但 time_total 明显偏大说明链路或服务端可能存在性能问题。如果大量请求出现 502、503、504则明显处于降级状态。3.3 确认 DNS 与网络链路在服务降级期间本地 DNS 解析失败容易被误判为“GitHub 挂了”。你可以临时切换公共 DNS 再做一次解析对比但不要针对访问速度做非官方优化。重点是识别本地问题和服务端问题# 查看当前解析结果 nslookup github.com nslookup api.github.com # 对比解析响应时间 time nslookup github.com如果 nslookup 能正常返回 A 记录但 curl 超时则问题更可能出在网络链路或 GitHub 服务端。如果 nslookup 本身超时说明本地 DNS 配置需要调整。判断原则很简单先看状态页再看 API 响应最后再看本地 DNS。大多数情况看到官方降级公告后本地链路检查只需要确认“服务端确实异常”就够了没必要反复折腾自己的网络配置。4. Actions 工作流异常排查Actions 降级时开发者最直观的感受是任务排队。下面按“确认排队 - 定位失败任务 - 重试策略 - 选择 Runner”的顺序排查。4.1 检查 Actions 排队状态工作流页面里的每个 job 都会有 queued、in_progress、completed 三种状态。服务降级时通常会出现大量 queued 任务。用 gh CLI 可以快速列出近期的 workflow run# 查看最近 10 次 run 的状态 gh run list --limit 10 # 查看某个 run 的具体 job 队列状态 gh run view run-id --json jobs --jq .jobs[] | {name, status, conclusion}如果 run 状态长期显示 queued且数据库/代码本身没有变更基本可以判断是服务端调度延迟。4.2 定位失败任务降级期间工作流失败不代表脚本有问题。失败的错误信息可能是ERROR: failed to fetchError: Process completed with exit code 1.日志中相关资源下载超时遇到这类错误先不要急着改代码而是先重新运行一次失败的任务并把运行时间记录在案。如果恢复正常后任务可以顺利通过说明当时的失败属于服务端降级不是代码回归。4.3 重试策略Actions 页面和 gh CLI 都支持重新运行失败的任务# 重新运行失败的 run gh run rerun run-id # 查询特定 workflwo run 的详细状态 gh run watch run-id降级期间建议不要短时间疯狂重试因为你反复触发只会增加队列积压。更务实的做法是保留失败日志等待状态页恢复后再统一重跑。4.4 自建 Runner 要不要上如果你所在团队的工作流对延迟非常敏感且每天跑的 Actions 任务很多可以考虑自建 Runner。自建 Runner 的优点是任务派发到自己的机器上减少 GitHub 托管 Runner 排队的影响缺点是维护成本高需要自己管理依赖、镜像、安全补丁。在降级期间自建 Runner 可能仍然会通过 Webhook 接收任务因此需要注意 Webhook 链路是否也受影响。不能把自建 Runner 当成万能方案。5. Pages 部署故障排查Pages 在降级期间的表现往往是“push 之后站点不更新”或者“更新到一半访问失败”。5.1 查看部署状态在仓库的 Settings - Pages 页面可以看到最近的部署记录在 Actions 里也能看到 Pages build-and-deploy 工作流的运行结果。首先要确认部署工作流是否触发触发后是否排队构建是否成功部署发布是否成功。如果构建工作流根本没有触发说明 Webhook 或 Actions 调度层受影响。如果构建成功但站点不更新说明 Pages CDN 刷新缓存可能延迟。5.2 用 Pages API 查看部署列表GitHub Pages 有相关的 REST API可以在降级期间判断状态# 查看 Pages 构建信息仓库需要替换为你的仓库 curl -s -H Authorization: Bearer your-token \ https://api.github.com/repos/owner/repo/pages返回 JSON 中通常包含status、html_url、cname等信息。status 显示built而页面不更新时重点观察 CDN 缓存。如果你只是普通用户没有配置 API Token直接在浏览器里打开 Settings - Pages 看状态即可。5.3 备用方案本地构建后推送如果 Pages 长时间无法构建而站点内容必须更新可以考虑本地构建静态站然后把构建产物作为一个分支手动推送。但这样做仍然依赖 Actions 的自动部署所以更彻底的做法是准备备用静态托管。在降级事件尚未结束时我建议先不要大规模切换平台因为 DNS 重新解析、证书签发、缓存预热都会引入新的变量。务实的顺序是记录期望发布的内容和提交 hash把本地构建产物备份到对象存储或代码仓库附件等 Pages 恢复后重新触发一次部署。5.4 自定义域名与 HTTPS 问题如果你给 Pages 绑定了自定义域名降级期间可能看到证书报错或域名解析异常。先检查 DNS 解析是否指向 GitHub Pages 的 IP再检查仓库 Pages 设置里的域名是否被正确识别。服务恢复后如果证书异常仍然存在可以把自定义域名移除再重新添加强制触发证书申请。6. 服务恢复后要做的事状态页从降级恢复为 operational 之后不要马上收工还有几个检查项6.1 清点积压任务降级期间排队的 Actions 任务有些会在服务恢复后自动执行有些可能会被标记为失败。恢复后先运行gh run list --limit 50 --json databaseId,status,conclusion把所有conclusionnull或statusfailed的任务列出来集中重新运行。6.2 校验 Pages 版本登录仓库的 Pages 页面确认当前部署版本与你期望发布的版本一致。如果恢复后 Pages 仍然展示旧内容可以重新 push 一个空提交触发部署git commit --allow-empty -m trigger pages rebuild after gh degradation git push origin main6.3 清理临时改动有些开发者在降级期间为了绕过故障可能临时修改了 workflow 的 runner 标签、并发数或超时时间。恢复后要把这些临时改动还原避免长期带着“应急配置”运行。6.4 更新状态记录建议团队内部维护一份简单的事件记录内容包括开始时间、恢复时间、受影响工作流、失败任务数、Pages 部署最终结果。这不仅是复盘依据也是后续优化 CI/CD 架构的输入。7. 如何长期监控 GitHub 服务状态很多团队是遇到问题了才发现 GitHub 状态页有公告这不太理想。更好的做法是提前接入监控。7.1 订阅状态页 RSSGitHub 官方状态页支持 Atom/RSS 订阅可以在内部监控系统或聊天工具中接入https://www.githubstatus.com/atom拿到这个订阅地址后用团队内部现有的 feed 机器人推送即可。状态页更新时会在第一时间把事件标题和状态变化推送到群里。7.2 用 API 轮询状态GitHub Status 本身也开放了一个简单的 JSON APIcurl -s https://www.githubstatus.com/api/v2/status.json | jq .通过返回值中的status.indicator和status.description可以判断当前是 operational、degraded_performance 还是 partial_outage。用系统定时任务跑一遍检测到indicator ! none时自动发告警。7.3 第三方监控UptimeRobot、Gatus 这类服务可以对https://github.com和https://api.github.com做主动探测。建议分开探测因为主站可用并不代表 API 正常API 正常也不代表 Actions 调度正常。监控策略建议每 5 分钟探测一次 API 响应码每 15 分钟检查一次官方 status.json收到降级公告后自动触发内部 Wiki 页面生成事件记录模板。8. 常见误判与排查清单下面这张表是降级期间最高频的误判场景。问题现象可能原因排查方式解决方案Actions 任务长时间 queuedGitHub 托管 Runner 调度降级查看 gh run list 与官方状态页等待恢复减少短时间重试必要时启用自建 Runner工作流 mid-run 超时失败服务端网络抖动或资源下载失败查看 job 日志中的具体网络错误重新运行恢复后统一重跑失败任务push 后 Pages 不触发构建Webhook 或 Actions 调度异常查看 Actions 页面是否有新的 workflow run等恢复后 push 空提交触发重建Pages 构建成功但站点旧内容CDN 缓存未刷新对比部署记录中的 commit hash等待或重新部署绑定自定义域名的检查域名状态网站间歇性 5xxPages 服务降级状态页公告 curl 响应码不切换 DNS观察状态页恢复情况本地 curl github.com 超时本地 DNS / 网络链路问题nslookup 对比公共 DNS调整本地 DNS重新测试API 正常但 Actions 排队Actions 与普通 API 基础设施可能分离降级查看 Actions 页面排队状态以状态页为准不重复修改 workflow注意最后一种情况API 正常不代表 Actions 正常。GitHub 的各个子系统在降级时可能表现不一致不能用某一次 curl 的结果推断全部功能都恢复。9. 架构层面的抗故障建议一次状态降级并不可怕可怕的是团队把全部发布链路绑死在单一平台上。如果 Actions 是你们唯一的 CI/CDPages 是你们唯一的静态站托管建议从下面几个方向做冗余。9.1 CI/CD 双通道核心仓库至少保留两套可执行的构建路径。例如主要通道GitHub Actions。备用通道本地脚本或自建 Runner 直接执行同一套构建命令。关键是构建脚本要从 workflow 文件里抽出来做成独立的 shell/Makefile 任务这样即使 Actions 无法调度也能在本机或内部服务器直接运行。9.2 制品与日志异地保存不要把构建产物只留在 Actions 的 Artifact 里。建议在 workflow 中加入上传对象存储或内部制品的步骤这样降级期间也能从其他渠道获取部署包。上传步骤本身如果也跑到一半失败就在恢复后重新运行一次。9.3 Pages 内容多目标发布静态站打包后的产物理论上可以同时部署到 Pages 和备用静态托管平台。建议提前把 DNS 切流方案设计好但在服务降级期间不要匆忙切换。先在恢复窗口测试备用平台部署流程确保备用环境配置完成再决定是否启用。9.4 依赖与缓存降级期间很多工作流失败是“依赖拉不下来”导致的。建议提前配置 Actions 缓存并对第三方依赖设置合理的镜像源减少运行中对外部网络请求的依赖。但所有依赖获取的配置都要保持合规不要使用不稳定的非官方地址。9.5 通知渠道要分离把状态监控通知放在主站之外的另一套渠道里。如果 GitHub 本身故障通知应该能通过即时通讯工具或邮件发出来而不是依赖 GitHub 仓库的 Issue 或 Actions 发送。10. 常见问题速查降级期间提交代码到仓库会丢吗不会。Actions/Pages 降级通常不影响 Git 仓库本身的数据写入。push、pull、PR 等操作大概率正常。如果你担心数据安全可以本地多备份一份。降级期间应该停止推送吗不需要停止推送但建议减少触发 Actions 的频率。如果只是修正文章的标点、格式可以积累几次变更后合并提交减少无效排队任务。状态页恢复后还需要等多久没有固定时间。恢复后可能出现延迟的 CDN 更新、积压队列消化、证书重新签发。建议给一个观察窗口比如 30 分钟到数小时再用gh run list和 Pages 页面确认最终状态。如果状态页显示 operational 但我这边仍然异常呢先检查本地网络、DNS、浏览器缓存。也可以清空本地 DNS 缓存后重新测试。如果仍未恢复可以通过 GitHub 官方支持渠道反馈附上请求时间、响应码、HTTP 响应内容。自建 Runner 是不是降级时的最优解不是。自建 Runner 只能规避 Runner 调度排队但 Webhook 触发、Pages 构建、GitHub API 调用仍然可能受降级影响。自建 Runner 适合作为长期架构优化不适合做临时的应急手段。有没有必要换掉 GitHub没必要因为一次降级就全面迁移平台。更合理的做法是保留 GitHub 作为主平台同时把关键流程沉淀为可迁移脚本必要时能在其他平台快速重建。重点不是“跑路”而是不让自己被单点绑死。11. 总结这次状态公告给团队的三条提醒第一看到 “degraded availability” 先冷静判断依据是官方状态页而不是“感觉”。第二Actions 和 Pages 是两条独立的排查路径先确认影响范围再动手改配置。第三任何云服务都有降级可能构建脚本、发布产物、监控通知要做到平台之外也能复用。下次再遇到类似公告可以先打开状态页跑一遍 status.json 检查再决定是等、是重试还是切换备用方案。这条经验建议直接收藏到团队的故障处理文档里。