GitHub 实际宕机情况追踪
熟悉的一幕：你尝试推送代码或检查 Actions，却只收到沉默或 500 错误。你打开官方状态页面，一切都是绿色的，显示"所有系统运行正常"。直到半小时或一小时后，才会低调地出现一条关于事故的横幅。
我一直觉得很有趣的是，大型平台都精通如何"平滑"正常运行时间统计数据。如果你相信官方报告，GitHub 几乎总是 99.9% 可用。但每天使用这个服务的开发者知道：现实要平淡得多。github-statuses 项目试图纠正历史记录，展示这个主要代码托管平台的真实可用性状况。
这个项目是关于什么的
仓库作者决定不轻信漂亮的图表，创建了这个"缺失的状态页面"。这是一个存档，收集来自 GitHub Atom 订阅源的数据，重建事故的真实时间线。
这个项目的有趣之处在于它不仅仅反映当前状态——它存储历史记录。如果 GitHub 删除旧的事故记录或调整开始时间（这种情况确实会发生），这个仓库会保留原始痕迹。该项目已经被 The Register 等主要科技媒体和 Fireship、PrimeTime 等知名博主关注。看来"GitHub 宕机"这个话题对很多人来说是个痛点。
底层是如何工作的
基础是 Flat Data 概念。数据从外部源获取，处理后直接保存到仓库中作为简单的文本文件（JSON、CSV）。
一个有趣的细节：有时 GitHub 会"忘记"在事故描述中指定哪些组件受到影响。为了解决这个问题，作者接入了 GLiNER2——一个小型命名实体识别（NER）模型。它分析消息文本，判断讨论的是 Actions、Copilot 还是 API 问题。
技术栈如下：
- Python 3.11–3.13 用于提取脚本。
- uv 作为包管理器（作者强烈推荐，我也同意——它速度快得惊人）。
- GitHub Actions 用于自动化数据收集。
- 一个简单的静态 HTML/JS 网站来可视化收集到的数据。
你能从数据中提取什么
如果你克隆仓库，parsed/ 文件夹已经包含可直接使用的数据。但如果你想自己动手，脚本允许你：
- 以 JSONL 格式导出特定时间段内的所有事故记录。
- 用影响级别信息丰富数据——为此，脚本会访问并解析具体的事故页面。
- 生成包含宕机时间窗口的 CSV 文件，你可以轻松导入 Excel 或 Grafana 来构建自己的图表。
运行所有这些只需要几个命令：
uv venv --python 3.13
uv sync
uv run python scripts/extract_incidents.py --out my_data --enrich-impact
为什么这对开发者有用
乍一看，这似乎只是一个"耻辱墙"。但这个项目有相当实用的应用。
首先，这是一个处理非结构化数据的好例子。看看作者如何在常规 HTML 解析失败时实现 ML 回退机制。在代码中，你可以看到如何配置模型的置信度阈值，以及如何过滤误报。
其次，如果你在一家对 GitHub 依赖很关键的公司工作（例如每 5 分钟通过 Actions 部署一次），这些数据可以帮助你向业务方说明需要实施自托管运行器或在 GitLab/Bitbucket 上建立备份平台的必要性。独立来源的数据总是比"我觉得它经常宕机"更有说服力。
如何查看结果
最棒的是，查看图表不需要任何配置。仓库中有一个 site/ 文件夹。你可以直接运行本地服务器：
python -m http.server 8000
然后打开 http://localhost:8000/site/。你会看到时间线、特定服务（Actions、Pages、Copilot）的正常运行时间百分比，以及按天细分的详细情况。
github-statuses 项目不仅仅是一个 bug 存档。它很好地展示了如何用 Python、几个 ML 库和 GitHub Actions 创建一个透明的监控系统，而官方来源往往对此保持沉默。
谁应该看看这个仓库：
- 对开放数据收集和分析感兴趣的人（Open Data）。
- 想在真实项目中尝试 uv 库的开发者。
- 用于评估使用云服务风险的 SRE 工程师。
项目活跃，数据定期更新，代码写得足够清晰，一个晚上就能弄清楚。你甚至可以尝试改编这些脚本来监控其他对你重要的服务。
相关项目