GitHub Actionsの障害によりCIジョブとCopilotのコーディングエージェントが停止

Why it matters

GitHub uses Actions to run CI, Pages, Copilot agents, code reviews and migrations. Runner failures can now block several stages of software delivery at once.

GitHub Actionsが大規模な障害を被ったのは8月6日で、ソフトウェアのビルドとデプロイが停滞し、GitHub Pages、Copilot coding agent、Copilot code review、エンタープライズのマイグレーションが妨げられました。GitHubによれば、workflow runが失敗し、長時間キューに残るかタイムアウトし続け、ホストされたランナーの容量が制約されたままだったといいます。(githubstatus.com)

GitHubは最初に15:22 UTC（東部夏時間で午前11:22）にActionsのパフォーマンス低下を認めました。16:33 UTCまでに、GitHubはActionsとPagesの両方を大規模障害として分類しました。インシデントは開始から3時間以上経過した18:46 UTC時点でも調査中であり、GitHubは回復に予想以上の時間がかかっていると警告しました。(githubstatus.com)

この障害は特にGitHubホストのランナーを使うジョブに大きな影響を与えました。セルフホストのランナーも安全な回避策とはなりませんでした。GitHubは、これらの顧客がランナー登録時にエラーやレート制限に遭遇する可能性があると述べました。以前のアップデートでは、ActionsのREST APIからのエラー、予期しないワークフローのレート制限、および既に開始した後に失敗したジョブが報告されていました。Webhookの配信が遅延する可能性もありました。(githubstatus.com)

コアなリポジトリ機能は利用可能なままでした。Git操作、プルリクエスト、イシュー、パッケージおよび一般的なAPIリクエストは稼働中とされ、障害の重心はコードのテスト、ビルド、デプロイに使われるオートメーションに絞られました。マージ前にチェックの合格を必要とするか、Actionsを使ってソフトウェアをリリースするエンジニアリング組織にとって、リポジトリが利用可能であるだけではデリバリーパイプラインを進める助けにはなりません。(githubstatus.com)

開発者たちはすぐにパターンを認識しました。Ryan Brewer (@ryanbrewer)は「Another day another github outage.」と書き、Aida Issayeva (@Aida_Isay)は立て続けのActionsインシデントが日常になりつつあり、CIをデバッグする際の最初のステップとしてGitHubのステータスページを確認することを述べました。彼女が共有したスクリーンショットはほとんどのGitHubサービスの稼働履歴が緑で示され、Actionsだけが赤いインシデントマーカーを付けていました。

Actions has become GitHub's shared execution layer

8月6日のインシデントの広がりは、現在どれほど多くのGitHubの機能がActionsを通じて動いているかを反映しています。GitHubのドキュメントによれば、Copilot cloud agentはActionsで動くエフェメラルな開発環境内で動作し、そこでコードを読み、変更を加え、テストを実行します。Copilot code reviewもデフォルトではGitHub-hosted runnersを使用します。(docs.github.com)

GitHub PagesはサイトのビルドとデプロイにActionsを使うことができ、GitHub Enterprise Importerはリポジトリや組織をGitHub Enterprise Cloudへ移動します。したがって今回の障害は従来のCIジョブを超えて、AI支援開発、ウェブサイトの公開、インフラ移行にまで及びました。GitHubは複数の製品を同じワークフローおよび計算レイヤーに集中させており、ランナーのプロビジョニングやオーケストレーションが失敗したときの運用コストが増大しています。(docs.github.com)

Pagesはすでに15:03 UTCに始まった別のデプロイ遅延インシデントを経験していました。GitHubはそのインシデントを16:22 UTCに解決済みとマークしましたが、これはPagesがActionsの広範なインシデント下で再びパフォーマンス低下を示す数分前のことでした。GitHubはその後、Actionsに加えてPagesを大規模障害のステータスに移しました。(githubstatus.com)

Reliability pressure was already building

この障害に先立ち、8月5日に別のCopilot cloud agentの障害が発生していました。GitHubによれば、内部のレート制限が意図より広く有効になっており、11:02から11:54 UTCの間に新しく送信されたすべてのcloud agentジョブが遅延しました。バックログは13:00 UTCまでに解消されました。(githubstatus.com)

Actionsは7月にも繰り返しの中断を経験しました。7月25日には、地域インフラとRedisの容量に関連する2回の劣化期間が記録されました。最初の期間ではワークフローの25%がインフラエラーで失敗し、2回目の期間では失敗率が最大60%に達しました。7月29日には、プロビジョニング不足の内部サービスがメモリ不足に陥り、約2%のワークフローが遅延し、ランナー登録の失敗やAPIのタイムアウトを引き起こしました。(githubstatus.com)

7月初旬のインシデントでは、ホストされたランナーのプロビジョニング、オートスケーリングの設定、期限切れの内部証明書が関与していました。個々の原因は異なりますが、各障害は顧客にとって同じ場所に表面化しました：ワークフローがランナーを待ち、開始に失敗するかリトライを使い果たすのです。(githubstatus.com)

その繰り返しにより、GitHubのステータスページは日常的なCI診断の一部になりました。8月6日の障害は、GitHubがより多くの製品（そのAIエージェントを含む）をActionsに結び付けることで生じる運用リスクを強調しています。そのレイヤーの障害は、テスト、リリース、レビュー、サイトのデプロイ、および自動化されたコーディング作業を同時に停止させる可能性があります。