ハクソク

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

GitHubが再び問題を抱えています

286日前原文(githubstatus.com)

概要

GitHubサービスで パフォーマンス低下 と 断続的な障害 が発生中。 APIや検索機能、Packagesなど 複数のサービス に影響。 部分的な回復は見られるが、 一部機能は不安定 な状態が継続。 調査と 対策作業 が進行中。 影響範囲は API Requests、Issues、Pull Requests、Actions、Packages。

GitHubサービス障害状況

  • 2025年8月12日 15:48 UTC時点で、 サービス可用性が部分的に回復

    • 依然として 一部サービスで不安定な挙動 や 検索データの古さ が確認されている状況
    • 調査と 障害緩和策 を継続中

  • 15:20 UTC時点では、 APIレイヤーでのレイテンシ増加 および

    • Issues、Pull Requests、Labels、Packages、Releases、Workflow Runs、Projects、Repositoriesなど 多くの機能で断続的なパフォーマンス低下
    • 調査進行中

  • 14:53 UTC時点、 検索基盤を利用するサービス全般でパフォーマンス低下

    • リクエストが 検索クラスタに届かない原因 を調査中

  • 14:30 UTC時点、 Packagesサービスでパフォーマンス低下

    • 調査継続中

  • 14:12 UTC時点、 API Requests、Actions、Issues、Pull Requestsでパフォーマンス低下 の報告

    • 調査開始

  • 本インシデントの影響範囲

    • API Requests
    • Issues
    • Pull Requests
    • Actions
    • Packages

現在の対応状況

  • 技術チームによる障害調査 の継続
    • 部分的な復旧を確認しつつ、 根本原因の特定 と 恒久対策 を検討
  • ユーザーへの状況報告 を随時更新
  • 検索基盤やAPI層 の安定化に向けた作業進行

影響を受ける利用者の注意点

  • IssuesやPull Requestsの読み込み・検索 で遅延や失敗が発生する可能性
  • PackagesやActions の一部操作に支障が出る場合あり
  • API経由の自動化処理 も影響を受ける可能性

今後の見通し

  • サービス全体の安定化 に向け、引き続き調査・対策を実施
  • 公式ステータスページ での情報更新を推奨

Hackerたちの意見

バイブがちょっと強すぎたかな。

「ダウンしてる」よりも「またダウンしてる」って聞く方が最悪だよね。IRの人たち、頑張って…

└

最後にダウンしたのは先週の金曜日で、生のコンテンツのURLが壊れた時だった。

GitHubのファンなんだけど、最近こういう問題が多くてさ… それに、まだIPv6のサポートがないのは驚き。

└

今の時点でIPv6をサポートしないのは恥ずかしいよね。

└

彼らが少なくとも部分的にAzureを使っていると考えると、驚くことではないね。Azureは3大クラウドプロバイダーの中でIPv6の実装が最悪だから。

自己ホスティングの代替としてForgejoを挙げるのはいいタイミングかな？

└

いいタイミングだね。

└

注目させたから、なんでリンクを提供しなかったの？

└

Gitlabと比べてどうなの？

エンタープライズのお客さん、契約に基づいて許可されている稼働時間について、営業担当者にメールして報告を求めるのを忘れないでね。自分から言わない限り、彼らは outages に気づかれないことを期待して何もしてくれないよ。内部的に報告の自動化もないから、かなりのストレスが溜まるんだ。これが変わる唯一の方法だよ。GitHubは間違いなく最も信頼性の低いSaaS製品だね。 outages の影響を受けない週なんてないよ。評判は最悪。

└

GitHubは間違いなく最も信頼性の低いSaaS製品だね。私たちの中にはAtlassianやBitBucketを使わざるを得ない人もいるけど、そっちの方が全てにおいてひどいよ。

└

企業はこれを自動化すべきだよね。自分たちで障害監視を作って、その結果とプロバイダーに送る面倒なフォーマットをLLMに突っ込んで、SLAクレジットを要求するメールを作成させるとか。低コストのサービスにはあまり価値がないかもしれないけど、GitHubに年間数百万ドル払ってるなら、やる価値あるかもね。

gitは高遅延の接続された開発者向けに設計された分散型VCSで、オフラインでも作業できる能力がたくさんあるんだ。 outages の影響を本当に受けたことはないと思う。たぶん、機能をマージするのに余分に1時間待つこともあるけど、そのおかげで昼ごはんを食べたりHNをブラウジングしたりできるから、他の人たちほど壊滅的には感じないな。

└

問題は、人々が開発とリリースのライフサイクル全体をGitHubに依存させていることだね。多くの場合、GitHubなしではコードのホットフィックスを本番環境にプッシュすることすらできないんだ。これは多くのエンジニアリング組織にとってひどい単一障害点（SPOF）だよ。

└

GitHubはgitホスティングだけじゃなくて、イシュートラッキング、コードレビュー、CI、アーティファクトホスティング、ウィキやドキュメント、カンバンボードも全部含まれてるよ。

└

GitHubは単なるgitじゃなくて、CIやプロジェクト管理ツール、イシュートラッカーでもあるんだよね。

信頼性の問題が続いて、CEOが辞任した今、競合が市場シェアを奪う絶好のタイミングに感じるね。応援してるよ！長い間、これらの基盤企業（テクノロジー）を倒す方法なんて絶対にないと思ってたけど、消費者の信頼を壊す能力には本当に感心してる！

└

残念ながら、GitLabは特にソフトウェアの品質に対して焦点が欠けてたね。

この outages の影響を受けた人は、今日もフロントページに載っていたRadicleをチェックしてみて。https://news.ycombinator.com/item?id=44874945 私はRadicleとは何の関係もないけど、技術には感心してるよ。

もしかしたら「エージェンティック」なことにあまり集中せず、コアプロダクトをしっかりさせることにもっと注力すべきかも。成長至上主義には合わないかもしれないけど…うーん、悲しいね。

前に働いてたところでは、すべてのgitリポジトリのコピーがサーバーにあって、ssh経由でアクセスできたんだ。そこにプッシュして、デプロイ時にサーバーにそのリポからプルするよう指示してた。もし今日同じことをやるなら、GitHubと自動的に同期を取る仕組みを追加して、デプロイのたびに両方からプルしようとするようにサーバーを自動化するかな。緊急時やバックアップのデプロイメカニズムが必要な人にとってのアイデアとしてシェアするよ。