全球7000万开发者每天打开的绿色代码贡献图，有人把它改成了红色——用来标记GitHub崩溃的日子。这个叫Red Squares的网站，把过去一年GitHub的宕机记录用"草"的形式铺展开来，结果是一片刺眼的红色方格。
GitHub早已不是单纯的代码托管站。它把Git操作、Pull Request、Issues、Actions、Packages、Pages、Copilot等十几项服务捆在一起，成了开发者的完整工作台。官方状态页面也给每个服务单列一项：Git Operations、Webhooks、API Requests、Actions、Copilot、Codespaces……你叫得出名字的工具，这里都有独立的健康指标。
但"GitHub挂了"这句话的含义其实很模糊。它可能是首页完全打不开，也可能是PR评论发不出去、Actions排队变长、SSH克隆时不时失败、Copilot代码补全突然消失。官方GitHub Status页面只 prominently 展示过去90天的数据，想一眼看清全年整体宕机多少天？页面没给这个数。
有个叫The Missing GitHub Status Page的第三方站点做了这件事。它从公开的状态feed里扒出故障记录，按分钟计算停止时间，再对应到具体服务。Red Squares就是基于这个数据做的可视化——把枯燥的分钟数转换成直观的日历格子。
Red Squares的统计结果是：过去一年，GitHub各功能累计停止时间约32.8天。注意这是"24小时×32.8天"的总量，不是连续一个多月不能用。更直观的数字是：365天里，有168天至少记录了一起故障——接近46%的日子出过问题。天天用GitHub的开发者觉得"最近老不稳定"，可能不只是体感，是确实有一半时间在跟各种小故障打交道。
另一个第三方站点Is GitHub Cooked?列出了服务分项的12个月停机时间：Copilot 7天5小时、Actions 4天20小时、Pull Requests 4天17小时、Search 3天5小时、Git Operations 2天5小时。但这些数字不能直接相加，同一时段多个服务同时故障会被重复计算。Red Squares的32.8天也是这个问题——三个服务同时宕1小时，它会记成3小时。
Hacker News上有工程师指出了这个计算方式的争议。但换个角度看：即便知道算法有放大效应，看到主要功能的故障时间堆出32.8天这个数字，开发者的心情很难不受影响。毕竟GitHub是工作台本身，不是可有可无的插件。每次提交前刷新一下状态页面，已经成了不少人的肌肉记忆。
热门跟贴