ハクソク

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

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

45日前原文(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を押せば最終的には読み込まれるけど、それでも生産性に悪影響を及ぼしてるよ。

└

Copilotは96.47%の稼働率を見せてる。それって…信頼性の1つの9だね。タイトルが問題を過小評価してるって言えるかも。 > GitHubを使うのに、すべてのサービスがオンラインである必要はないよ。まあ、彼らはそう使ってほしいんだろうけど、それだと彼らの意図した使い方としては大失敗だよね。別の言い方をすると、「GitHubの機能を多く使うほど、全体の信頼性がかなり不安定に下がる」ってこと。正直、ほとんどのサービスに対して9にこだわったことはないけど、クラウドサービスプロバイダーはそれを大きな売り文句にしてたよね。LLMのおかげでそれも飽きられちゃったけど。セキュリティも同じ。GitHubは上流にいるから、下流の影響がかなり深刻に波及することがあるんだよね。

└

96%の稼働率はひどいよね。

└

2019年の同じことを見てみて。https://web.archive.org/web/20190510070456/https://www.githu... 同じ指標が以前よりもかなり悪化しているみたいだね。

└

もう少しコンテキストを追加すると、彼らのエンタープライズSLAは99.9%（3つの9）の稼働時間を個々のサービスに対して保証しているんだ。https://github.com/customer-terms/github-online-services-sla 「GitHubは、該当するGitHubサービスの稼働時間を少なくとも99.9%維持することを約束します。」…でも、このサイトによると、過去90日間で個々のサービスが99.9%の稼働時間に達したことはないんだよね。0_o

└

基本的なGitサービスは、可用性が1つの9だよ。

誰かステータスページ見た？思ってたよりずっとひどい。こんなにひどい結果のステータスページを見るのは初めてだと思う。https://mrshu.github.io/github-statuses

└

じゃあ、明らかに https://status.claude.com を見てないね。

└

ちなみに、そのページのおかげでこの投稿のタイトルが間違ってることになってる。今朝の時点で「90.21%の稼働率」って書いてあるけど、これは1つの9であって、3つじゃないんだよね。（ただし、これはプラットフォーム全体の話で、個々のコンポーネントは3つの9を達成してないみたい。）

└

「劣化したパフォーマンス」も含まれてるから、こんなに悪く見えるんだよね。ただの怒りだけじゃない。

└

特にアーカイブページと比べるとね。https://web.archive.org/web/20190510070456/https://www.githu... 月に1〜4件のインシデントがあったのに対して、今は約1件/日だよ。

自分は個人のオープンソースプロジェクトのためにGitHub（とアクション）を使ってるから、正直文句は言えないな。だって、全部無料でもらってるからね¹。でも、そのプロジェクトでも最近、GitHubのランナーが理由もなくランダムに止まることがあって、アクションを（部分的に）有料のソリューション²に切り替えなきゃいけなかったよ。¹「彼らが何を得ているか」という部分は省略してるけど。² https://www.warpbuild.com/

予想通りだね。マイクロソフトは良い製品を無駄なものに変える才能があるよ。Skypeもそのいい例だね。

└

Windows（メモ帳やエクスプローラーも含む）もそうだね。~Office~ ~Office 365~ ~Microsoft 365~ Copilot 365は、ブランドやライセンス、AIのゴチャゴチャした機能があっても、まだ技術的には使えると思うけど、長くは持たないだろうね。

└

GitHub for Businessはいつ導入されるんだろう？

IPv6の無知はカナリアだね。表面下にはたくさんのアーキテクチャの無知がある。実際の問題は、なぜ彼らが年次セキュリティ監査に失敗してないのかってことだね。https://docs.github.com/en/enterprise-cloud@latest/organizat...

└

監査の質がアーキテクチャと同じだからね、笑っちゃうよ。

GitHubにあまり多くの評価を与えたくないんだけど、彼らの稼働率は本当にひどいし、改善が必要だと思ってる。でも、こういう会社のプラットフォームの稼働率を判断するのはちょっと不公平だなって感じてる。「どれか一つの機能がダウンしたら、全部ダウン」って言って、それをプラットフォームの9に変換するのはね。私はGitHub Copilotを使ったことがないけど、彼らのステータスページを信じるなら、結構ダウンするみたい。ダウンしても、他のGitHubには影響しないから、あんまり気にしないんだよね。Copilotを無視したGitHubの稼働率が気になる。みんなが気にすることのスライスはちょっとずつ違うから、GitHubの稼働率について正確に話す唯一の方法は、たくさんの人が気にしてて最近苦労してるコアな部分に焦点を当てることだと思う。コアのgit操作、ウェブサイトの機能、APIアクセス、アクションなどね。

└

「Githubがダウンしている」と言うのは、確かに一般化しすぎだよね。チームに影響を与えるボトルネックに焦点を当てるべきなんだけど、今回はそうじゃない。彼らの最も安定したサービス（API）は、たったの2つの9（99.69%）しかないんだ。平均を3つの9にするのにも苦労しているわけじゃなくて、どのサービスもそのレベルに達するのが難しいみたい。Copilotは1つの9で最も不安定かもしれないけど、僕が最も重要だと思うサービス（GitとActions）も同じく1つの9なんだよね。

可用性の期待値のギャップは、教育の観点から見ると面白いね。学生たちは99.9%がすごい数字だって教えられるけど、それが実際には何を意味するのかは説明されない。年間で約8時間のダウンタイムがあるってことなんだ。何百万もの開発者が仕事中に依存しているプラットフォームにとって、その数字は消費者向けアプリとは全然違う意味を持つよ。

Githubに少し同情する部分があるんだ。もしみんなが僕みたいだったら、去年の5〜6倍の需要があると思う。単にコミット数だけでね。Github Copilotの使用も考慮に入れたら、もっとだよ。