GitHubの過去1年間のダウンタイムを「草」形式で可視化する「Red Squares」 – GIGAZINE

ソースコード管理サービスのGitHubについて、障害発生日をGitHubのContribution Graph、いわゆる「草」の形式に沿って赤いマスで表示するという可視化サイト「Red Squares」が登場しました。

Red Squares — the GitHub outage graph
https://red-squares.cian.lol/

GitHubは単一のウェブサイトというより、Gitリポジトリ操作、プルリクエスト、Issues、Actions、Packages、Pages、Copilotなどの複数サービスを束ねた巨大な開発基盤です。GitHubの公式ステータスページも、Git Operations、Webhooks、API Requests、Issues、Pull Requests、Actions、Packages、Pages、Copilot、Codespacesなどを個別の項目として表示しています。

「GitHubがダウンした」と言っても「どの程度のダウンか」はさまざまです。GitHub.com全体が完全に使えない状態だけでなく、「プルリクエストのコメント作成が失敗する」「Actionsのジョブ待ち時間が長くなる」「SSH経由のGit操作が失敗しやすくなる」「Copilotの一部機能が使えない」といった状態も障害として扱われる場合があります。

公式の稼働状況を知らせるページであるGitHub Statusは、記事作成時点では全システム正常稼働中を意味する「All Systems Operational」と表示されていました。ただし、公式ページの目立つ場所で確認できる稼働率は過去90日分が中心で、過去1年の「GitHub全体として何日分止まったのか」という集計は公式ページだけでは直感的に把握しにくくなっています。

The Missing GitHub Status Pageは、GitHubが以前は表示していた集約的な稼働率が現在は見えにくくなったとして、公開ステータスフィードから障害履歴を再構成している非公式ページです。The Missing GitHub Status Pageは、障害のタイムラインを再構築し、日単位ではなく分単位の停止時間として計算し、ソース文面から関連サービスを対応付けていると説明しています。

Red Squaresは、Missing GitHub Status Pageのデータを用いてダウンしていたタイミングをより分かりやすく可視化したサイトです。Red Squaresの集計によると、過去1年におけるGitHubの停止時間は約32.8日分でした。この約32.8日分というのは、GitHub Actions、プルリクエスト、Git操作、Copilotなどの各機能で発生した障害時間を合計すると、24時間×32.8日分に相当するという意味です。

また、少なくとも1件の障害が記録された日は168日だったとのこと。過去1年を365日とすると、約46％の日に少なくとも1件の障害が記録されていた計算になります。毎日GitHubを業務で使っているユーザーが「最近GitHubがよく不安定になる」と感じる理由は、停止時間の合計だけでなく、障害が発生した日数の多さにもあると考えられます。

非公式集計サイト「Is GitHub Cooked?」では、過去12カ月のサービス別停止時間として、Copilotが7日5時間、Actionsが4日20時間、Pull Requestsが4日17時間、Searchが3日5時間、Git Operationsが2日5時間と表示されています。サービス別停止時間は単純に足し合わせると同じ時間帯に複数サービスで起きた障害を重複して数える可能性があるため、「GitHub全体の停止時間」として読むには注意が必要です。

なお、エンジニアが集うニュース共有サイト「Hacker News」では、Red Squaresの「1日に1日を超える停止時間が表示される場合がある」という点に疑問を示すコメントがあり、「3つのサービスが同時に1時間ダウンした場合、Red Squaresでは3時間のダウンとカウントされている」と指摘されています。

Red Squaresの「1年間の停止時間が約32.8日分」という数字は、複数サービスの同時障害を足し合わせるため、ダウンタイムが長めに見える計算方法ではあります。それでも、GitHubの主要機能の障害時間をサービス別に積み上げると約32.8日分という見え方になるのも事実。GitHubは開発者にとって作業台そのものとも言えるほど必要不可欠なサービスのため、体感としては「GitHubがまたダウンしている」と言いたくなるわけです。