ハクソク

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

GitHubの稼働状況に関する最新情報

7時間前原文(github.blog)

概要

GitHubは最近2件の重大なインシデントを受け、可用性と信頼性の向上に注力。
10倍規模のキャパシティ増強計画を実施し、将来的には30倍のスケール対応を目指す。
分散システム設計や重要サービスの隔離、シングルポイント障害の排除を進行中。
直近のインシデントの詳細と再発防止策、透明性向上への取り組みを説明。
エンジニアリング責任者Vladimir Fedorovによるコミットメント表明。

GitHubの可用性と信頼性向上に向けた現状報告

  • 直近2件のインシデント発生による影響と謝罪
  • 2025年10月から10倍キャパシティ増強計画を実行開始
  • 2026年2月時点で30倍規模の設計が必要と判断
    • ソフトウェア開発手法の急速な変化
    • agentic development workflowsの急増
  • リポジトリ作成数・プルリクエスト・API利用・自動化・大規模リポジトリ対応の急成長
  • 複数システムへの同時負荷増大による複雑なスケーリング課題
    • 小さな非効率が全体に波及するリスク
  • 最優先事項：可用性＞キャパシティ＞新機能
  • 不要な処理削減・キャッシュ最適化・重要サービスの隔離・単一障害点の排除
  • 分散システム設計の推進
    • 隠れた依存関係の削減
    • 障害範囲（blast radius）の最小化
    • サブシステム障害時の優雅な劣化（graceful degradation）の実現

直近の取り組みと技術的対応

  • 短期対応
    • ボトルネックの早期解消（Webhooksバックエンド移行、ユーザーセッションキャッシュ再設計、認証・認可フローの見直し）
    • Azure移行によるコンピュートリソース増強
  • 重要サービスの隔離
    • gitやGitHub Actionsの他ワークロードからの分離
    • 依存関係・トラフィック階層の分析
  • RubyモノリスからGoへの移行加速
  • マルチクラウド体制の準備
    • レジリエンス・低レイテンシ・柔軟性の確保
  • 大規模モノレポ（monorepo）対応強化
    • gitシステム・プルリクエスト体験の最適化
    • マージキュー操作の最適化（1日数千プルリク対応）

直近インシデントの詳細

  • 4月23日 マージキューインシデント
    • プルリクエストのマージ処理でリグレッション発生
    • squash merge方式利用時、複数プルリクが同時マージされると誤ったマージコミット生成
    • 658リポジトリ・2,092プルリクが影響
    • データ損失なし、Gitコミットは全て保持
    • 影響ブランチの状態が不正となり、自動修復が困難なケースも
    • 原因分析とプロセス改善を実施
  • 4月27日 Elasticsearchサブシステム障害
    • 検索基盤が過負荷（ボットネット攻撃の可能性）
    • 検索結果が返らないUI障害発生
    • データ損失・Git操作・APIへの影響はなし
    • シングルポイント障害の隔離未完了が原因
    • blast radius分析による再発防止策を進行中

透明性向上への取り組み

  • GitHubステータスページの更新
    • 可用性指標の公開
  • すべてのインシデントのステータス化
    • 規模を問わず状況を明確に共有
  • インシデント分類・報告プロセスの改善
    • 顧客からのフィードバックやシグナル共有方法の強化

GitHubのコミットメント

  • 開発者支援・オープンで拡張性あるプラットフォームの提供
  • 信頼性・レジリエンス・スケーラビリティの継続的向上
  • 透明性あるコミュニケーションの徹底
  • 全ての問い合わせ・フィードバックへの真摯な対応

CTO Vladimir Fedorovの紹介

  • GitHub Chief Technology Officer
    • エンジニアリングリーダーシップとイノベーションで数十年の経験
  • UserClouds共同創業者（データガバナンス・プライバシー分野）
  • Facebook（現Meta）で12年、2,000人超のエンジニア組織を統括
  • Microsoft出身、CaltechでBS/MS取得
  • Codepath.org理事、AIネイティブ世代の育成に尽力
  • ベイエリア在住、家族とアウトドア・ウォータースポーツを楽しむ

参考リンク

  • GitHub Docs：GitHubの使い方を網羅
  • GitHub Build：誰でも何でも構築できるプラットフォーム
  • Customer stories：GitHubを活用する企業・エンジニアチームの事例
  • The GitHub Podcast：オープンソース開発者コミュニティの最新トピック紹介

Hackerたちの意見

> マルチクラウドへの道を進めてるみたいだけど、これはマイクロソフトがAzureの信頼性に満足してないってことなのかな？（多くの人がそう思ってるけど、マイクロソフト自身から聞くのは興味深いね）。
└
かなり厳しい内容だね。でもAzureを使ったことがある身としては、納得できる。
└
大規模で複雑なシステムに対して、単一のプロバイダーに頼らないのは賢い判断だと思う。
└
これは、GitHubがダウンしたときに損失を被る企業向けに調整されてると思う。リテンションに役立つかもね。
└
マルチクラウドの概念は、クラウドが本来何であるべきだったかを考えると面白い。彼らはそれをメタクラウドと呼ぶかもしれない（商標に引っかかるかも）。AI生成コードの成長軌道を考えると、最終的にはマルチメタクラウド、さらに「ビヨンドクラウド」、そしてマルチビヨンドクラウドになるかも。限界は見えないね。
└
Show HNのタイミングは、みんなが思ってるより重要だよ。月曜日から木曜日の午前9時から11時（太平洋時間）が、フロントページに最もエンゲージした読者が集まる時間帯なんだ。週末の投稿は競争が少ないけど、エンゲージメントも減る。
新しいリポジトリや問題、コミットに関するデータが公開されて嬉しいよ。外から見てたみんなが信じてたことを裏付けてるね。エージェントがGitHubに急に大きな負担をかけてる感じ。まるで急成長中のスタートアップみたいだけど、すでに大きなユーザーベースがあるから、的を外さずにいるし、変化に対してはあまりスピードが出ない組織かもね。でもその反面、スタートアップにはない才能やインフラ、お金も持ってる。
└
それってどんなデータ？ラベルのないグラフと現在のピークの数字があるけど。
何やってるんだ？十分なトレーニングデータを抽出したから、トークンの補助をやめて、エージェントビジネスを回して損失を減らそうよ。
これを真顔で読むのは難しいよ。ラベルのないグラフに大きな数字、私たちが感じてることと合わない優先順位、そして過去12ヶ月のひどい稼働率を本当に認めないまま進めてることのリスト…。
└
「あなたの声を聞いています」って感じで、300語くらいかな。
└
もっと数字を見てみて: https://x.com/kdaigle/status/2040164759836778878 ここでの質問は何？成長が現在指数関数的だと信じてないの？それとも、10倍の年々成長が足りない時にスケールするのが難しくないと思ってるの？
└
たくさんのクライアントでも同じことができるよ。
└
これらのグラフが世界で最悪というわけではないよ。確かに左下の軸はラベルが付いてないけど、ポイントはちゃんと伝わってる。2023年から2026年にかけての成長が急速に進んでるし、2026年の初めには、前の3年間の成長を合わせたよりも多くの成長があるって言ってる！左下の軸の数字を知らなくても大丈夫。グラフが線形であることを前提にしないといけないけど、他の内容を考えるとそれは安全な仮定だと思う。計画以上の成長を経験する会社は、キャパシティの問題が出てくるよね。優先順位もそれに沿ったものになってる。もう単にハードウェアを追加する段階は超えてるし、バックエンドをもっと効率的にする必要がある。目標もそこに向けたものだよ。
└
つまり、GHが買収されてから6年経ったってことだね。https://damrnelson.github.io/github-historical-uptime/
偏見かもしれないけど（tangled.orgの創設者です）、未来は本当に連邦型のフォージであるべきだと思う。主権インフラ上にリポジトリをホストして、グローバルなアイデンティティと連邦型の「メタデータ」（問題、プルリクエストなど）を持つ感じ。これに対するグローバルインデックスは簡単に立ち上げられるはずだから、可用性は心配いらないよ（これに向けて進んでるから！）。
└
このアイデア大好き！でも、うちのサイトのLLM生成コンテンツは置き換えちゃうかな。最近、コードバーグに移行したんだけど、大きなランナーをセルフホスティングするのは全然オッケーだし、小さいクロンベースのものにはコードバーグのランナーを使ってる（これにはレイジーランナーもあるし）。
└
でも、できるよね？GitHubやコードバーグにリポジトリをホストできるし、セルフホスティングもできる。そうしたら、メインを見守って一貫性を保たなきゃいけないけど。それが確立されたら、どこからでも更新できるよ。READMEにリンクを貼ればいいし。
└
「主権インフラ」って具体的に何？
└
こんなの初めて聞いた！登録してみてチェックしてみるね！
└
コーディングエージェントがデフォルトでGitHubに依存しないでほしいな。別のフォージを使っても同じ機能が得られるなら、 decentなAPIを提供してくれたり、Webhookでイベントを送ってくれれば、全部自己ホストできるのに。エージェントは自分たちのインターフェースを公開する必要があるけど、プラグインで実装すればGitHubへの依存をなくせるし、残りはMCPやスキルを使えるようになるよ。
└
> 未来は本当に連邦制であるべきだよね。インターネットは集中化されるべきじゃないけど、世界を掌握して、会社を兆ドル企業に売却しないと、10億ドルの会社は作れないよ。
└
いいアイデアだけど、ほとんどの人は自分のものをホストしたがらないんだよね。もし第三者を使ってホストするなら、1〜3社の大手がサービスとして提供することになるのは避けられないし。自分でホストして可用性の問題を避けたとしても、大手もGHみたいに失敗することがあるから、依存関係が必要な場合はどうしようもない。だから、今と同じ解決策だね。使うものは全部プロキシかミラーしなきゃ。
ほんと、今は「私たちの優先事項は明確です：まず可用性、次にキャパシティ、そして新機能」とか言ってるけど、6ヶ月前はまさに同じことを言ってたのに、Azureが助けてくれるって言ってたよね。> GitHubは機能開発よりもAzureへの移行を優先する - GitHubはすべてのインフラをAzureに移行するために取り組んでいるけど、これによりいくつかの機能開発が遅れることになる。> GitHubのCTO、ウラジミール・フェドロフは、バージニアのデータセンターでキャパシティに制約があると述べている。「AIやCopilotの需要に応えることは私たちにとって生死に関わることです」と彼は書いている。 https://thenewstack.io/github-will-prioritize-migrating-to-a... 現在遅れている機能開発はさらに遅れることになるけど、ほぼ毎週新機能や変更が見られるし、ついこの間もシングルイシューのビューが変更されたばかりだよね。6ヶ月前は「生死に関わる」って言ってたのに、今も同じ問題でつまずいてるの？信頼性と稼働時間に専念しているとしても、今日の経験はすごいよね。マイクロソフトのリソースを持つ会社が、どうしてこうも自分の足を撃ち続けるのか、ちょっと驚きだよ。実際、印象的だよね。おまけに、人気のある開発者サービスを全部買収して、同じプラットフォームに移行するって、素晴らしいアイデアだね。
└
> 現在遅れている機能開発がさらに遅れるみたいだけど、ほぼ毎週新しい機能や変更が見られるよね。ついこの間も、単一の課題表示が変更されたし、これが一例だね。パフォーマンスを改善するためのパニックモードのハックだったんだろうね。https://news.ycombinator.com/item?id=47912521
└
ちょっと厳しすぎる意見だね。優先順位は排他的じゃないし、特にGitHubみたいな大規模なエンジニアリング組織ではなおさら。これが最優先事項かもしれないけど、これに貢献できないチームや個人は新機能みたいな他のことに取り組むこともあるよ。
└
Azureへの移行が可用性の問題を悪化させた可能性もあるね。専用ハードウェアの方がクラウドよりもずっと予測可能だし。「Azureに移行せずに、もう少しラックを買おう」っていうのは、GitHubの経営陣の権限を超えた決定だったんじゃないかな。
└
もしこの5年間、GitHubに新しい機能を追加したり変更したりしてなかったら、誰も不満を持たなかったと思う。でも、彼らはずっと変え続けてる。5分ごとにリニューアルする必要なんてないウェブサイトなのに。GitHubのコードベースを維持しているメインの開発チームは、新しい機能を提供しないと仕事が正当化できないマネージャーに運営されてるんじゃないかな。新しい人をGHに呼び込むために新機能を出そうとしてるけど、実際には壊れることが多くなって逆効果になってる。検索機能をひどく弱体化させたけど、なんで他の大手テック企業（Google - 検索とYouTube）が、以前はうまく機能してた検索を壊し続けるのか分からない。もっと大きなジョークなのは、MicrosoftがAzure DevOpsを持ってるけど、これが放置されそうな感じ？でもGitHubもあるし…両方で一番嫌なのはチケットシステムだね。「Jiraが恋しい」なんて言う日が来るなんて信じられない。どのJiraプロジェクトも設定が不安定だったから、ほんとに全てがそうだった。
> ウラジミール・フェドロフはGitHubのCTOです。彼は現在、AIネイティブなエンジニア、CTO、創業者を育成するために高等教育を再プログラムすることに特化した組織Codepath.orgの理事を務めています。問題が見つかった気がします。
これらのグラフで一体何をやったのか全然わからない。まるでアーティストの印象画みたい。コミットのグラフを見てみると、なんでコミットが大きなステップの後にゆっくりと減少してるの？ステップが均一なポイントで起こらないのはなんで？大きなステップが小さなステップよりも傾きが少ないことがあるのはどうして？他のグラフを見ると、全然違う効果が出てるし。
└
それは、実際のデータやデータの意味じゃなくて、「物事が上がっていく」ってだけを示す、典型的なパワーポイントのグラフだからだよ。
GitHubの安定性が悪くて困ってる。最近、ウェブで見せられるデータも信頼性がなくなってきた。昨日から、俺と数人の同僚が気づいたんだけど、ウェブサイトのプルリクエストリストが多くのリポジトリで不完全なんだ。例えば、https://github.com/gap-system/gap/pulls では「プルリクエスト 78」と表示されてるのに、PRリストビューでは「35オープン」って報告されてる（数字の78は正しいし、例えば`gh pr list`で確認済み）。しかも、https://www.githubstatus.com では「すべてのシステムが正常」と報告されてるのに。
└
> 例えば、https://github.com/gap-system/gap/pulls では「プルリクエスト 78」と表示されてるのに、PRリストビューでは「35オープン」って報告されてる（数字の78は正しいし、例えば`gh pr list`で確認済み）。これは、インフラへの負荷を減らすために「推定」クエリを使って「まあまあ正しい」結果を返すスケーリングハックだと思う。必ずしもバグとは言えないけど、プロダクトの観点からは微妙な選択だね。
└
私のプロジェクトの多くでは、過去6日間にクローズされたプルリクエストが全く表示されてないんだ。CLIではリストできるけど、検索を通すと何も出てこない。サポートはこの問題を認めたけど、それ以降は音沙汰なしで、ステータスページも27日の関連する問題以外は何も表示されてない。今のところ、いくつかのリポジトリでは解決されたみたいだけど、私はまだ複数の組織やリポジトリで問題が続いてるよ。https://github.com/orgs/community/discussions/193388
└
私も同じことに気づいたし、確かにステータスページは問題を報告してないね。ブランチページを見ていれば、欠けているPRを見つけられたよ。
> 私たちの優先順位は明確です：可用性が最優先、その次が容量、そして新機能。Copilotやスロピフィケーションについては一切触れていません。おそらく意図的な省略で、Microsoftはすべての製品において本当の優先事項が一つだけだから。