GitHub.comで8月17日に起きた障害は、中央米国のネットワーク飽和から始まり、認証経路とCopilot Token Serviceの復旧を長引かせた。GitHubは同日21:15 UTCに解消を報告し、影響開始から7時間47分だったとした。サイドカーの並列処理上限を見ていない自動スケーリングと、失敗時に増える再試行が重なったことが、同社の障害報告から分かる。共通経路の監視漏れが、認証とクライアントの再試行へ連鎖した。

AD

7時間47分、開発の入口から認証まで広がった

影響は2026年8月17日13:28 UTCに始まった。日本時間では17日22:28から18日06:15までに当たる。GitHubの最初の状況更新は13:40 UTCであり、実際のユーザー影響は初報より12分早い。ピーク時にはWebとAPIのエラー率が約20%に達し、アーカイブとrawコンテンツのダウンロードでは約50%が失敗した。Issues、Pull Requests、APIが影響を受け、ActionsとCopilotにも及んだ。Git Operations、Webhooks、Pagesも影響対象に入った。

認証経路にも影響が及んだ。SAML/OIDC認証、SCIM、Team Syncで遅延や失敗が生じ、組織の利用者管理を妨げた。GitHub.com上の公開ワークフローステップ定義に依存するデータレジデンシー付きGitHub Enterprise CloudのActionsワークフローも影響した。GitHub Actionsでは、ワークフローを構成する各ジョブのステップが利用者のスクリプトや再利用可能なActionを実行するため、GitHub.com側の参照先が止まると専用環境の実行にも波及し得る。

大半のサービスは16:36 UTCまでに回復したが、Actionsの低下は約18:03 UTCまで続いた。Copilot Token Serviceが完全に回復したのは21:02 UTCである。最初の大きな回復からCopilotの完全回復までにも4時間26分を要した。

サイドカーの監視漏れが4台のHAProxyへ連鎖

直接の原因は、新たなトラフィックピークによって中央米国データセンターの負荷分散装置でネットワークが飽和したことだった。発端ではIstioサイドカーPodが並列処理上限に達していた。自動スケーリングのポリシーはホストサービスを監視していた一方、サイドカーの上限は見ておらず、必要なタイミングで正しくスケールしなかったという。

GitHubによると、障害はさらに連鎖し、最終的に4台のHAProxyノードがフロー上限を使い切った。ゲートウェイの認証経路で遅延と失敗が広がり、楽観的な再試行ロジックが内部ロードバランサーを過負荷にして状況を悪化させた。4台のHAProxyを同時に一時停止すると、広範なサービスは直ちに回復した。もっとも、各ノードの容量やフロー上限、Istioサイドカーの具体的な上限値、誤設定の値は公表されていない。

AD

毎秒10万件、再試行がCopilotの復旧を遅らせた

Copilot Token Serviceでは、トークン操作の失敗が追加要求と再試行ループを生み得る状態になった。通常は毎秒7,000〜9,000件だったトラフィックが、障害時には毎秒70,000〜100,000件へ増加した。GitHubは約10倍の増幅と説明している。単一の内部エンドポイントからの遅延応答を受け、VS Codeの潜在的な再試行バグがトラフィックを増やしたことも、復旧を遅らせた要因に挙げた。

影響の残り方はクライアントによって異なった。20:08 UTCと20:45 UTCの更新では、一部アプリケーションのCopilot認証で断続的な失敗が続く一方、GitHub CLIとGitHub AppからのCopilot利用は影響を受けていないとされた。少なくともこの時点では、Copilotへの影響範囲がクライアント経路によって分かれていた。

北バージニアで発生した再試行ストームに対し、GitHubはPRによってゲートウェイの再試行ロジックを一時的に減らした。さらに負荷分散装置でCopilot Token Serviceへの受信トークン要求を403応答で遮断し、その後はサイト単位でトラフィックを段階的に戻した。403による遮断は緊急時の措置であり、恒久策として採用したとはGitHubは述べていない。VS Codeの修正PR、影響するバージョン、修正版の配布日程も未公表である。

北バージニアへの退避で残った依存関係

復旧中、GitHubは失敗していたトラフィックの一部を中央米国から北バージニアへ移し、中央米国のネットワーク障害を調査・解消するまで正常に処理した。ただし、これは全面的なフェイルオーバーだったとは報告されていない。「失敗トラフィックの一部」を移送した範囲に限られる。codeloadエンドポイントへの複数のスクレイピング攻撃も復旧を複雑にしたが、GitHubはこれを直接原因とはしていない。新たなトラフィックピークのうち、通常利用、再試行、スクレイピング攻撃がそれぞれ何割を占めたかも公表されていない。

GitHubが挙げた再発防止策は、サイドカーの並列処理能力を織り込んだ自動スケーリング設定への修正、Istioの要求数・並列処理・スケーリング上限の監査、ゲートウェイとクライアントの再試行上限とバックオフの見直しである。VS Codeの増幅挙動にも対処する。負荷分散装置の容量監視とリージョンフェイルオーバー保護も改善対象に入る。

耐障害性を測るには、通常時の余力に加え、依存先が遅れたときの再試行設計も確かめる必要がある。クライアントとゲートウェイは、何回、どの間隔で要求を再送するのか。その上限を実際の障害条件で検証できるかが、次の復旧時間を左右する。