GitHubの障害を貢献として見せる Red Squares

 (red-squares.cian.lol)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • Red Squares は GitHub のコミット貢献グラフをパロディ化し、緑色のマスの代わりに赤いマスで GitHub.com プラットフォームの障害を表示する
  • 各 赤いマス は GitHub で障害が発生した1日を意味し、色が濃いほど障害がより長く続いた日を表す
  • 直近1年間の GitHub のダウンタイムは合計 32.5日 と集計されている
  • 少なくとも1件のインシデントがあった日は 167日
  • 最悪の日は 2026年4月30日木曜日 で、ダウンタイムは 1.0日 に達する

GitHubの障害を貢献グラフで風刺

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Hacker News のコメント

  • この手のバイブコーディング系ミームサイトが出てくるたびに、実際の原因は負荷ではなく GitHub チーム、技術スタック、Microsoft、Azure がひどいせいだ、というコメントが延々と付く
    公開されている GitHub のステータスページと Enterprise Cloud のページを比べると、Enterprise 側の数値のほうがずっと良く、個人的にも仕事にならないレベルの障害が最後にいつ起きたか思い出せない
    問題が負荷と無関係なら、Enterprise 製品でも同じような可用性の問題が見えるはずだと思う

    • きちんとサービス提供できていないことを批判するのは、個々のエンジニアを責めることではなく、システムの失敗を批判しているということだ
      とりわけ、多くの国よりも多くの資源と世界最高水準の技術人材を持つ会社であれば、システム批判は十分に可能だ
      GitHub の技術スタックは実際よくなく、長いことかなり傲慢にそれを擁護してきた
      Azure はひどいプラットフォームなのにチームへ半ば強制的に押し付けられており、リレーショナルデータベースの選定やフロントエンドの書き直しについても防御的な態度を見たことがある
      サイトを安定して動かせてもいないのに UI を作り直し、AI ツールを押し出すのは時間の無駄だ
      これは個々のエンジニアへの攻撃ではなく、ネットワーク効果で事実上の独占になったシステムが、中核製品よりも新機能やオーナーの満足を優先するという経営陣の選択を批判しているのだ
    • 公式ステータスページが SLA の都合で実際のダウンタイムをそのまま反映しないことは広く知られている
      ステータスページは会社に不利な証拠として使われうるので、比較自体にあまり意味はない
      実際には障害でも、マーケティング用語では「性能低下」と呼ばれることが多く、独立して運営されているステータスページのほうがずっと有用だ
    • どうやら別々の領域で仕事をしているようだ
      毎日ではないが、会社で障害を回避せずに1週間を過ごせた記憶がほとんどない
      たいていの場合「仕事」自体は続けられるが、障害がなければ同じ時間内にビルドまたはデプロイできていたはずの作業が遅れるので、個人的には最低でも週1回は影響を受けている
    • GitHub は小さな店ではないのだから、3兆ドル企業ならその負荷はさばくべきだ
      でなければ少なくとも、上部に「趣味用途専用」と大きく警告を出すべきだ
    • 皮肉なことに、まさに今、組織内で GitHub のバグのせいで PR に新しいスレッドを作れない
      既存スレッドに返信はできるが、新規作成はできず、ステータスページにも載っている
      こんなものがどうやって通ったのか分からないし、なぜ1時間も続いているのかも理解しがたい
      修正まであと3〜4時間かかるというのだから実に親切だ

  • Gemini 2.5 Pro、Copilot 内の Grok Code Fast 1、Claude Opus 4 のような外部モデルの性能低下まで GitHub のせいにするのは公平ではないように思える
    GitHub にできることがない問題ではないだろうか

    • 最近のパターンは、個別サービスの小さな性能低下を全部まとめて、同じくらい重要な問題のように見せることだ
      深刻度を消し去ったうえで、すべてを「GitHub 障害」や可用性グラフへと要約してしまう
      GitHub の最近の大規模障害に不満はあるが、小さなサービス低下とサイト全体の障害の境界をあいまいにして、より劇的に見せ、推薦、いいね、カルマ、注目を集める注目集め目的のサイトやソーシャル投稿が増えているのは見苦しい
    • ハイパースケーラーの性能低下を github.com の可用性と結び付けるのはあまり面白くない
      できるだけチャートを赤くしたかっただけのように見える
    • GitHub が他社サービスを再包装して提供しているなら、GitHub を責めてもいいと思う
      うちは GitHub よりずっと小さいサービスを運営しているが、複数プロバイダーと複数モデルによる代替経路を用意してある
    • モデルを誰がホストしているかによる

  • 週末はまだ未開のフロンティアだ
    まだ拡張の余地がある

    • 先月分析したとき、GitHub の平日稼働率は 89.3%、週末は 96.5% だった
      障害は平日の 62%、週末の 11% にまたがっており、Claude も同様に平日 92.5%、週末 97.8% だった
      火曜から木曜までが危険地帯で、日曜は事実上別サービスのように見える
      https://www.aakash.io/tech-chase/github-and-claude-are-down-...
    • それなら変更作業が最大の原因なのか？
    • 996 勤務制が始まるまで待てばいい

  • まずこのグラフが正確なのか疑わしい
    「少なくとも1件の障害があった170日・最悪の日 2025年11月20日木曜日、1.1日」と出ているが、1日の合計が1.1日というのがどういうことなのか分からない
    その日付にマウスを載せても内部計算の仕組みは見えず、単一項目は 1.3 時間と出る
    11月19日には 1.3 日の障害項目があるのに、合計は 8.1 時間と表示される

    • 欠落しているステータスページ [1] は、システムのどのコンポーネントでも落ちていればダウンタイムとして扱い、重複しない時間で全体の可用性を計算し、少なくとも1つの個別障害と重なる時間は二重計上を避けるため全体ダウンタイムとして扱う
      その日付では 24 時間の軽微な障害として表示されている
      このサイトは1日分の全サービスのダウンタイムを合算しているようで、そうすると最悪の日は主要カテゴリごとの1日分のダウンタイムが積み上がって10日分のダウンタイムに達することもありうる
      1: https://mrshu.github.io/github-statuses/
    • 「1.3日中 1.0日」という項目が見え、前日の 2025年11月19日水曜日にマウスを載せると「1.3日中 7.8時間」と表示される
      実際にその日にダウンタイムがあったかは確認していないが、数字が正しいとすれば、7.8時間に1日を足した値がおおよそ1.3日になる

  • 公式ステータスページ [0] とサードパーティ製ステータスページ [1] の差が大きすぎる
    実際の製品利用状況とこれほど違うのなら、SLA 条項がどうして合法なのか疑問だ
    GitHub もサービスも好きだが、実際には壊れているのにステータスページが緑色のままだと、毎回内心で何かが叫ぶ
    [0] https://www.githubstatus.com/
    [1] https://mrshu.github.io/github-statuses/

    • 条項が合法な理由は、SLA 上の可用性を追跡し、違反時にクレジットを請求しなければならない主体が顧客だからだ
      最近働いていた場所では、ステータスページに記録されない GitHub 障害をたくさん経験し、Slack 検索でログを残していた
      その後、ビジネス担当者たちが GitHub のアカウント担当とやり取りした末に、数百ドル分のクレジットを受け取った
      しかし、その数百ドル分のクレジットはかけた時間に見合わないと不満を漏らしており、だから GitHub の低い可用性は続き、何も起きない
    • 面白いことに、昨日問題が起きたとき同僚が mrshu のページをリンクしてきたが、公式ページでは Actions の問題を表示していた一方で、そのページは全部緑色だった
    • SLA は GitHub の一部機能を対象外にしている可能性が高い
      一方、サードパーティページは特定モデル1つの障害や問題までも GitHub の問題と見なすため、実際の利用感と差が出ることがある

  • 週末は障害がずっと少ない
    どうせそのときは働く気がないので完璧だ

  • このアイデア自体は前からあった
    1月に障害カテゴリごとの可用性を分解して見ようとして、これを作った
    https://isgithubcooked.com

    • 「Billing」は完全に緑で、「Pull Requests」は完全に赤い

  • 週末はダウンタイムがほとんどないのがコントリビューショングラフとかなり似て見えて笑える