1 ポイント 投稿者 GN⁺ 1 일 전 | 1件のコメント | WhatsAppで共有
  • Pull Requests のパフォーマンス低下が発生しており、/pulls/repo/pulls ページでインデックス済みの pull request のすべてが表示されない可能性があります
  • 現在 Elasticsearch クラスターにすべてのインデックス文書が入っていませんが、pull request のデータ自体は失われておらず、更新時に再インデックスされます
  • 残っているインデックスを再インデックスする作業と、全結果復旧のための full reindex の加速作業が並行して進められており、正確性と追加影響の回避が優先されています
  • コンポーネント状態表では Pull Requests のみが低下状態として表示されており、Git Operations・Webhooks・API Requests・Issues・Actions・Packages・Pages・Copilot・Codespaces・Copilot AI Model Providers は Operational 状態です
  • 最近の履歴には、検索の低下、Actions ジョブ失敗、Copilot agent セッション開始失敗、merge queue の回帰、Projects の遅延、Codespaces 接続失敗などの複数の障害事例と復旧措置も公開されています

現在の障害状態

  • Pull Requests でパフォーマンス低下が発生しており、Incomplete pull request results in repositories として公開されています
  • /pulls/repo/pulls ページで インデックス済みの pull request のすべてが表示されない可能性があります
    • Elasticsearch クラスターには現在 すべてのインデックス文書が入っていません
    • pull request のデータ自体は 失われていません
    • pull request が更新されると再インデックスされます
    • 全結果復旧のために full reindex の加速作業 も並行して進められています
  • 残っている Elasticsearch インデックスを 再インデックス中 で、正確性を優先しつつ追加影響を避ける方針で対応中です
    • データを安全に backfill する 慎重なアプローチ を維持しています

コンポーネント状態

  • 現在の状態表では Pull Requests のみが Degraded Performance と表示されています
  • そのほかの主要コンポーネントは Operational 状態です
    • Git Operations
    • Webhooks
    • API Requests
    • Issues
    • Actions
    • Packages
    • Pages
    • Copilot
    • Codespaces
    • Copilot AI Model Providers
  • 過去 90 日間の稼働率もあわせて提供されています
    • Pull Requests 99.58% uptime
    • API Requests 99.95% uptime
    • Packages 99.97% uptime
    • Copilot AI Model Providers 100.0% uptime

地域別ステータスページと購読経路

最近の障害履歴

  • Apr 28 一部 GitHub サービス障害

    • Disruption with some GitHub services は解決済みです
    • Actions hosted Ubuntu ジョブで 開始遅延と失敗 が発生しました
      • ubuntu-latestubuntu-24.04 実行の一部が遅延または失敗しました
      • 一時は約 5% のジョブ が影響を受け、その後 2% 未満、さらに 1% 未満 まで減少しました
    • Actions 実行を妨げていた問題は緩和され、最終的に正常動作へ復旧しました
  • Apr 27 GitHub 検索の低下

    • GitHub search is degraded は解決済みです
    • Elasticsearch 接続問題と追加負荷により 検索失敗 と複数の下位サービス問題が同時に発生しました
      • Issues、Pull Requests、Packages、Actions が影響を受けました
      • workflow run の失敗、projects の読み込み失敗、search timeout が発生しました
    • 追加負荷の原因を遮断した後に復旧の兆候が見られ、その後は安定化監視へ移行しました
  • Apr 27 Copilot Cloud Agent Codex セッション障害

    • Disruption with some GitHub services は解決済みです
    • Copilot Cloud Agent で Codex agent セッション開始失敗 が発生しました
      • issue の割り当てや @copilot コメントメンションなど、すべての導線から開始できませんでした
      • Copilot Cloud Agent 全体の 0.5%、約 2,000 件の失敗ジョブ が影響を受けました
      • Copilot の他の agent セッションは影響を受けませんでした
    • Codex agent セッションの model resolution mismatch により、ランタイムで互換性のないモデルが選択されたことが原因です
    • Codex agent セッションに安定したデフォルトモデルを選ぶようにする緩和策がデプロイされました

根本原因の公開を含む主な事例

  • Pull Requests merge queue の回帰

    • Incident with Pull Requests は解決済みです
    • merge queue で squash merge 方式 を使用した際、merge group に PR が 2 件以上あると誤った merge commit が生成されました
      • その後のマージで、以前の PR 変更分や以前の commit 変更分が巻き戻される可能性がありました
      • 影響期間中に 2,092 件の pull request が影響を受けました
    • merge queue の外でマージした PR と、merge または rebase 方式を使った一部のグループは影響を受けませんでした
    • merge base 計算を調整する新しいコードパスが 不完全な feature flag gating の状態で適用されたことが原因です
    • コード変更をロールバックして全環境に強制デプロイし、影響を受けたリポジトリ管理者には 復旧手順 を別途案内しました
    • その後、複数 PR の squash グループまで含める merge correctness テスト範囲 の拡張が進められています
  • Claude・Codex agent を Web から開始できない問題

    • Disruption with users unable to start Claude and Codex agent task from the web は解決済みです
    • github.com で Claude または Codex agent による 新しい agent task を開始できませんでした
    • Copilot mission control の task creation request ルーティングコード変更 が原因です
    • 進行中の agent task とほかの Copilot agent 機能は影響を受けませんでした
    • 問題を引き起こした変更をロールバックして復旧し、task 作成経路に 追加監視と統合テスト を導入しています
  • Copilot @メンション処理漏れ

    • Disruption with some GitHub services は解決済みです
    • pull request コメントの @copilot メンションが Copilot coding agent の実行につながりませんでした
      • pull request・issue コメント全体のうち約 23,000 回の呼び出し、全体の 0.5% が処理されませんでした
      • コメントの作成・参照・返信自体には影響ありませんでした
    • downstream consumer にイベントを発行できなくした serialization error が原因です
    • イベント発行復旧用の修正をデプロイした後に正常処理へ戻り、関連イベントスキーマの点検と監視改善が進められています
  • Copilot Chat と Cloud Agent の停止

    • Disruption with Copilot chat and Copilot Coding Agent は解決済みです
    • github.com の Copilot Chat と Copilot Cloud Agent で エラー が発生し、その間利用できませんでした
    • preview 状態の Copilot Memory も agent セッションで利用できませんでした
    • インフラ設定変更によりデータベース接続問題が発生したことが原因です
    • github.com は先に復旧し、残りの地域デプロイも順次復旧しました
  • Projects サービス遅延

    • Disruption with projects service は解決済みです
    • Projects が 同期されない、または 変更反映が遅延する 可能性がありました
      • 変更反映遅延は最大で約 45 分 に達しました
    • serialization error によりイベント失敗と resync の急増が起き、イベント処理層が過負荷になったことが原因です
    • 流入する変更の処理速度を高めて緩和し、その後 backlog を解消しながら復旧しました
  • コードスキャン既定設定・Code Quality の低下

    • Partial degradation for code scanning default setup and for code quality は解決済みです
    • 新しい pull request で code scanning default setupcode quality 分析 がトリガーされませんでした
    • 新規作成した issue が project board に表示されない問題も同時に発生しました
    • serialization error により、コードスキャン、コード品質分析、project board 更新が正しくトリガーされなかったことが原因です
    • code scanning・code quality のイベント発行は復旧し、project board 側は追加コード変更と reindex により復旧しました
    • incident 前または発生中に処理されなかった PR は 新しい push が必要 で、分析が再トリガーされます

その他の最近の障害事例

  • Disruption with some GitHub services
    • GitHub.com の Web 体験が低下し、約 1.5% の Web リクエスト がエラーで終了しました
    • 一部の時点では Web トラフィックの約 10% が遅延または失敗しました
    • 1 つのデータセンター地域で キャッシュコンポーネントの容量が飽和 したことが原因です
    • 影響のない地域へトラフィックを迂回し、最近のデプロイをロールバックして復旧しました
  • Incident with Codespaces
    • VS Code editor 経由での GitHub Codespaces 接続に失敗しました
    • 40% の codespace start ジョブ が失敗しました
    • SSH 接続は影響を受けませんでした
    • upstream download service の障害により、起動時に必要な VS Code Server のダウンロード が妨げられたことが原因です
    • 既定エンドポイントが低下した際に代替ダウンロード経路を使う回避策で緩和しました
  • Disruption with some GitHub services
    • GitHub Enterprise Cloud の Copilot Insights ページ へのアクセス時に 500 エラーが発生しました
    • 709 人のユーザー が影響を受け、総影響時間は約 5 時間 10 分 でした
    • metrics pipeline の認証失敗と tenant credential 変更が原因です
    • 診断ツール、より細かな監視、alerting 強化が進められています

1件のコメント

 
GN⁺ 1 일 전
Hacker Newsのコメント
  • 今は静かに失敗するのがむしろより問題だと思う
    たとえばPRが何十件もあるのに、"There aren’t any open pull requests."と表示されて、人を確実に誤解させる

    • 先週はmerge queueを使うと誤ってtrunkを吹き飛ばしてしまうこともあったが、それも静かに失敗していた
    • うちではむしろ、ついにPRを全部片付けたように見えるので、お祝い中だと冗談を言うことになった
    • PR一覧が表示されても、見ているカテゴリのPRを全部表示しないことがあって、本当にたちが悪い
  • これは自分には本当に強く刺さる
    数か月前、$PARENT_CONGLOMERATEがシナジーと効率性を理由に傘下組織全体へGitHub移行を強制し、今度は**$DAYJOBでもself-hosted GitLabから移る番になった
    すでに不満はいくつかある
    GHアカウントに関するITポリシーは一貫性がなく、個人アカウントでも、以前に$DAYJOB用として別に作ったアカウントでも、既存アカウントはまったく使えず、ITルールに合わせた新しいアカウントをまた作らなければならない
    私たちは
    monorepoを使っていないのでgroupsを多用していたが、GitHubにはその概念に直接対応するものがなく、プロジェクトnamespaceを手動で整理しなければならない
    そのうえ、GitHubの可用性までこの有様だ
    私たちのチームはリリース日程が売上に直結していて、1日2日ずれるだけでも月間目標を達成できるかどうかが分かれることがある
    別の状況なら収益の中核コードをあらかじめミラーしていただろうが、そんなゲリラ的な回避策を作るほどのリスクを負う価値はなさそうだ
    近い将来のポストモーテムで
    The Synergy Mandate**を責められればいいのだが、現実にはそうならないことは自分でもよく分かっている
    ただ売上目標を引き続き達成し、業績不振で製品が打ち切られないことを願うばかりだ
    こうして書いていると、自分が入社した頃と今とで、この仕事がどれほど変わったかをいっそう実感する

  • すべてのOSSプロジェクトに改めて言いたい
    簡単なCIジョブで複数のforge間でコードを同期するのはとても簡単にできるし、第2のforgeからメール通知を受け取るのにも追加の負担はほとんどない
    少なくともGitHubの外へ移って貢献できる選択肢は開いておくべきで、結局そのほうがエコシステム全体にとって良い

    • コード同期自体は簡単で些細な部分であり、CIジョブは実際のところその部分しか解決しない
      大半のプロジェクトでは、それすら絶対必須ではないかもしれない
      難しいのはコードの周辺にあるものだ
      ticketsやPR、クローズ済みのものまで含めた履歴
      プロジェクトを参照するさまざまなリンク
      CI設定
      大きなプロジェクトならコミッター権限の構成
      必要ならpush/commit/branchルールまですべて移さなければならない
      こうしたものはプロジェクトごとに移行するのが非常に面倒で、一部は失われるかもしれない
      しかし、さらに大きな問題はソフトウェアを見つけるための基本プラットフォームを失うことだ
      ソフトウェア版fediverseはいつ出てくるのだろうと思う
    • 同期は些細だが、本当の核心はCI
      いまだにGitHub Actionsが最良の選択肢で、FSFであれ他のOSSラボであれ、オープンソースメンテナーにまともなCIを提供できていない
      しかもCI負荷も以前よりはるかに大きくなっている
    • 独自のGitLabインスタンスを立てるのも良い解決策になりうる
  • もう真剣に代替手段を後押しすべきだと感じる
    これが私たちのビジネスに実際の影響を与え始めており、改善する気配もまったく見えない

    • GitHubのようなUIが欲しいならForgejoやGiteaを使えばいい
      org/repo構造の制約は受け入れる必要がある
      似てはいるが少し違う体験を望むならGitLabが合っている
      カーネル寄りのやり方、つまりホスティングと柔軟なリポジトリ構造、ssh keyベースのユーザー認証、シンプルなWeb UIを望むなら、gitoliteにcgitを組み合わせるかgitwebを使えばいい
    • 私たちは何年もGiteaとDrone/Woodpeckerをself-hostingしているが、とてもうまく動いている
      GiteaでもForgejoでも、提供機能が要件を満たしていれば十分だ
      ときどきGitHub障害スレッドを見に来て笑って帰るが、うちのGiteaインスタンスはここ数年の総ダウンタイムが数分レベルで、しかも全部深夜の計画アップグレードだった
    • GitLabがもっと注目されないのは意外だ
      完全な複製ではないにせよ十分近く、オレンジとリンゴほどの違いではなく、リンゴとナシくらいの差だと思う
    • 自分も同じ考えだった
      ただ、GitHubは本当に粘着性の高いプラットフォームで、actionsや各種連携を入れてしまうと離れにくい
      それでも障害がここまで頻繁なのは、もうかなりひどいレベルだ
    • 今はForgejoでGitとCIをself-hostingしているが、とても満足しているし、うまく動いている
  • GitHubだけの問題ではなく、もっと大きな障害のように見える: https://downdetector.com

    • 共通項はAzureである可能性が高そうだ
  • 今日も一日の終わりにyが付く日だから、つまりやはりGitHub障害があるということだ

  • Codeberg.orgでも今問題が起きている

    https://status.codeberg.org/status/codeberg

    https://social.anoxinon.de/@codebergstatus/11647770704799298...

  • GitHubが落ちるのも嫌だし、AIにコードを盗まれるのも嫌なら、sourcehutを使ってみるといいと思う
    自分にはとても合っていて、プラットフォームとしてもっと栄えてほしい

    • 新しいリポジトリを探索する体験が気に入って、私は全部Codebergへ移し、関心のあるプロジェクトの大半もそこにある
    • sourcehutの何が違うのか分からない
      結局それも別の中央集権型サービスではないかと思う
  • 今回のはやけに長引いている気がする
    修正チームがClaudeのセッション制限に引っかかってクールダウンが終わるまで何もできず、AIなしで直接直せる唯一の人は手術で席を外している、みたいな冗談を思い出す
    AIなしで直接修正していた世代が全員引退したら、その次はどうなるのだろうとも思う

  • GitHubが落ちるたびに、何人かずつ倫理的な代替手段へ移っていき、FOSSコミュニティがMicrosoft一社にSPOFを置く構造も少しずつ弱まっていく

    https://sfconservancy.org/GiveUpGitHub/

    • その趣旨には共感するが、多くのプロジェクトがGitHubに集まっていた社会的側面には確かに利点があった
      コラボレーションしやすかったし、今はさまざまな理由で摩擦が増している
      issuesがスパムのように使われることも増えており、それ以上に悪質な活動も少しずつ見え始めている
    • SPOFはSingle Point of Failureの略だ