ハクソク

世界を動かす技術を、日本語で。

GitHubはわずか「三つの9」の可用性に苦しんでいるようです

2026年3月23日原文(theregister.com)

概要

  • クラウドサービスの 障害頻発 が深刻化
  • GitHub のサービス停止が続発
  • サービス稼働率の 可視化が困難
  • エンタープライズ顧客向けSLA の現状
  • ダウンタイムへの 備えの重要性

クラウドサービスの障害頻発とGitHubの現状

  • ほぼ 毎日のように発生するクラウドサービスの障害
  • 「 Five nines」(99.999%稼働)どころか「 One nine」(90%稼働)すら達成困難な現状
  • GitHub では2月9日に複数のサービス（Actions、Pull requests、Notifications、Copilot）で障害発生
    • 1554 UTCに「一部GitHubサービス」で問題発生を公式認知
    • 通知遅延が最大 50分、1757 UTC時点で 30分 に短縮
    • 1929 UTCに「復旧」を発表
  • Copilot の障害も発生
    • 2月9日1629 UTCから2月10日0957 UTCまで、 Copilotのポリシー伝播問題 が一部ユーザーで発生
    • 新たに有効化したモデルが 利用不可 になるケース
  • GitHubは ステータスページの仕様変更 により、過去90日間のサービス状況や全体稼働率の把握が困難に

稼働率の可視化と信頼性への懸念

  • 非公式なパブリックステータスフィード から再構成された情報により、GitHubの 稼働率が2025年に一時90%を下回った ことが判明
  • Five nines （99.999%稼働）が理想だが、 90%維持すら困難なベンダーも存在
  • エンタープライズ向けSLA では99.9%稼働を明記
    • ただし全ユーザーには 保証されていない
  • サービスの不安定さ はGitHubだけの問題ではなく、クラウド全体の課題

ダウンタイム対策の必要性

  • GitHub利用者の苦労 は、 ダウンタイム対策の重要性 を強調
  • 稼働率の高さだけでなく、 障害発生時の対応計画 が不可欠
  • クラウドサービス選定時のリスク評価 の必要性

Hackerたちの意見

2025年にGitHubのCTOが、GitHubのインフラを独立させるのではなく、すべてをAzureに移行すると発表したときのこと:

「私たちにとって、可用性が最優先であり、この移行によりGitHubは開発者が頼りにする速くて信頼性のあるプラットフォームであり続けます。」 あの時の予想通り、うまくいかなかったよね。誰か、2014年から2015年頃に、コミュニティの半分が「もっと早く機能を追加して！」って叫んでたのを覚えてる？信頼性と安定性に焦点を当てたプラットフォーム（OSでもいいけど）に戻れたらいいのに。あの頃はもう遠い昔みたいだね。

└

完全にAzureに切り替えたら、IPv6アクセスを無効にするのを忘れそうだね。夢見るのは自由だけど。

└

安定性と信頼性は、全体的に見てここ数年でかなり改善されたと思う（特にGitHubについて言ってるわけじゃないけど）。ただ、みんな100のツールや依存関係を使っていて、それらがさらに50の他のものに依存しているから、複雑になってるんだよね。

└

「信頼性と安定性に焦点を当てたプラットフォーム（OSでもいいけど）に戻れたらいいのに」 それは、大手を使っている人にとってだけ有効な意見だよ。中小の競合もいて、彼らは（何十年も）すごく退屈だけど、その分安定してるからね。

└

GitHubは新機能を追加するのもあんまり良くなってないよね :(

GitHubがAIをあれこれ詰め込むことに夢中になっている間に、プラットフォーム全体が本当に崩れかけていて、そのセキュリティの欠陥が悪用されて大きな被害をもたらしてる。先週、Aqua Securityが侵害されて、いくつかのリポジトリが感染した。脅威アクターは、GitHub Actionsでの可変参照の広範な使用を悪用して、数千のCI実行を感染させたんだ。GitHubが認めているけど修正を拒否している問題も悪用されて、無害に見えるワークフローに悪意のあるアクション参照を密輸することができちゃう。GHAはもうスイスチーズとは呼べないくらいひどい状態だよ。大規模な見直しが必要だね。今のところ、リポジトリごとにオプトインのImmutable Releasesがあるだけ。

└

CIがデフォルトで過剰に複雑になったのが心配だよ。プロバイダーがテンプレート化されたYAMLや様々な抽象化を持ち込んで、動的な動作や依存関係を追加するようになったから。CIとCDを混ぜることで、通常のデプロイやデリバリーには独自の複雑さがあるから、さらに悪化したかもしれない。昔は、デリバリーの部分にJenkinsを使って、E2Eのナイトリービルドを行い、テストやリンターを実行するのにはもっと軽量なものを使ってた。実際に必要なのは、よく構造化されたシェルスクリプトのスイートを実行できることだけだと思う。Gitの中にいるなら、リポジトリイベントにちなんだディレクトリでスクリプトを実行するためのフックの規約に従うとかね。信頼できないコードを実行することに依存する再利用可能な「アクション」を作るのはやめよう。ステータスの報告、キャッシング、JUnitファイルの保存などを手助けするユーティリティを提供すればいいんだ。残るのは、すべてのツールを含むベースイメージを設定することだけ。Dockerがそれをやっていて、信頼できない第三者に依存する唯一の部分かもしれない。スキャンして自分のキャッシュ版を保存できるなら別だけど。簡単に聞こえるかもしれないけど、なぜか私たちはコードをデプロイするために重要なシステムに対して、分散型のYAMLベースの泥沼を受け入れちゃったんだ。ほとんどすべてに無監視でアクセスできるのに。そして今、人々はそれにAIエージェントを接続している。

└

もっと愚痴るためのネタが欲しいなら（悪気はないけど、俺も愚痴るからね）、https://github.com/orgs/community/discussions/142308 のような大きな問題が何年も放置されてるのを見れば、十分だと思うよ。

└

GHAはもうスイスチーズとも呼べないくらい、もっとひどい状態だよ。それは高いハードルだけどね。スイスチーズよりいいものなんて少ないから。

└

公共サービスのお知らせだよ。アクションのバージョンをハッシュに固定できるよ。今のところ、これはベストプラクティスだと言う人もいるみたい。こんな感じで、コメントにはハッシュが指すべき場所が書いてある。古い --> uses: actions/checkout@v4 新しい --> uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4 リポジトリをスキャンして自動化するツールもあるよ: https://github.com/mheap/pin-github-action

ちょっとニュアンスを加えたいんだけど、GitHubを擁護するつもりじゃないよ。彼らは確実に信頼性を上げる必要があるけど、90%の稼働時間の数字は、GitHubが提供するすべてのサービスが90%の時間オンラインであることを示してるだけなんだ。GitHubを使うのに、すべてのサービスがオンラインである必要はないよ。例えば、私はCopilotを使ってないけど、そいつは96.47%の稼働時間で、トラッキングされているサービスの中では最悪なんだ。

└

一方で、GitHubが痛いほど遅いけど技術的には使える場合も含まれてないよね。最近は、ちょっとしたPRのdiffビューを開くのに15〜30秒かかるのが普通になってる。確かに、長い待ち時間やF5を押せば最終的には読み込まれるけど、それでも生産性に悪影響を及ぼしてるよ。

Hacker Newsで議論の続きを見る