要点
- GitHub は7月19日23時34分 UTC、Actions の障害を critical として記録した。新しいワークフローは開始が遅れるか失敗し、実行中の処理も失敗する可能性があった。
- 影響は API Requests、Pages、Issues へ拡大した。GitHub は Actions の長時間停止が他サービスへの連鎖を生んだと説明し、別に開いた Git LFS/API の障害を同じ調査に統合した。
- CircleCI では開始しないパイプラインや実行中のまま止まるパイプラインが発生した。OpenAI も GitHub に依存するプログラミング作業の失敗や遅延を報告した。
- Actions は04時43分 UTC に全面回復し、障害は1分後に解消扱いとなった。GitHub が予告した詳細な原因分析は、本稿の締め切り時点では未公表だった。
リポジトリに変更が届いていても、配送工程が始まったとは限らない。
今回の GitHub 障害が示したのは、まさにこの状態のずれだ。最初の告知は19日23時34分 UTC で、対象は Actions だった。GitHub はまもなく、新規ワークフローが遅延または開始失敗となり、進行中の実行も失敗し得ると説明した。23時57分には原因を特定したとしたが、何が壊れたかは明らかにしなかった。
その後、障害は実行基盤だけの問題ではなくなった。00時07分に API Requests が部分停止となり、Pages と Issues も劣化した。別の記録では、一部の Git LFS 操作と API 経由のファイル読み込みに失敗が出た。01時11分、GitHub は Actions の停止が長引いたため他サービスに連鎖的な影響が生じ、別件として開いた障害も関連していたと説明した。
計算資源より先に制御の一貫性が崩れた
Actions のワークフローは、リポジトリのイベントを受け、ジョブを作り、runner へ割り当て、結果をブランチ保護や外部サービスへ返す。処理を実行する CPU だけで成立する仕組みではない。
このため、各システムの見ている状態が分かれる。push は存在するのにパイプラインが作られない。ジョブは終わっているのに必須チェックが更新されない。LFS の大きなファイルは保存されていても、取得に使う API が失敗する。公開済みの Pages は読めても、次のビルドが進まない。
復旧時刻も一様ではない。Pages は01時37分、Issues は02時20分に正常化した。02時43分、GitHub は Issues、API Requests、Pages の回復を発表したが、セルフホスト型または大型ホスト型 runner を使う Actions ジョブの復旧作業は続いていた。API Requests が正常とされたのは03時03分。Actions は03時34分に監視へ移り、04時43分に全面回復した。
これらは状態ページの更新時刻であり、全顧客に共通する停止時間ではない。GitHub は影響したリポジトリ数、組織数、ジョブ数、地域、失敗率を公表していない。Git 操作だけを使うチームと、Actions、LFS、Pages、外部 CI を連結したチームでは、影響の形が違う。
CircleCI の記録が示す「終わっていない実行」
下流で何が起きたかは CircleCI の説明が具体的だ。同社は GitHub API のエラーにより、ワークフローが始まらない、または実行中表示のまま止まる状態が出たとした。push イベントの webhook 処理にも失敗があった。
API のエラー率が戻った後、CircleCI は、始まらなかったパイプラインを再度起動し、実行中のまま止まったものはキャンセルして再実行するよう案内した。上流が復旧しても、下流が持つ履歴や状態までは自動で整合しないことを示す対応だ。
OpenAI も別の状態記録で、GitHub に依存するプログラミング作業の失敗や遅延を、API の部分停止と Actions の劣化に結び付けた。利用者数や失敗件数、損失額は示していない。ここでの意味は限定的だが重要である。GitHub の内部表示にとどまらず、別会社の顧客接点まで障害が届いたことを確認できる。
CircleCI や OpenAI が原因だったという意味ではない。すべての連携が壊れた証拠でもない。依存先が復旧表示になっただけでは、複数のサービスに分散した状態が一致したとは言えない、という証拠である。
runner を自社運用しても指令系統は残る
GitHub はセルフホスト runner を、顧客が配備・管理し、Actions のジョブを実行する機械と定義している。顧客はハードウェア、OS、導入ソフトを選び、維持費も負担する。
この方式は、社内ネットワークへの接続、特殊なハードウェア、処理能力、データ配置を自社で管理するうえで有効だ。ただし、ワークフロー全体を自社運用することとは違う。
GitHub は、API や Pages が回復した後も、セルフホスト runner と大型 runner を使うジョブの復旧を続けていた。顧客の機械自体が故障したと述べたわけではない。計算資源が利用可能でも、イベント受付、キュー、割り当て、状態返却が GitHub 側で止まれば処理は進まない、という依存境界を示している。
緊急時の代替経路には、予備サーバーだけでなく、誰が処理を開始できるか、どの版を承認済みとみなすか、結果をどこに記録するかまで必要になる。実行場所だけを複製しても、配送経路全体の代替にはならない。
再実行の前に外部の結果を確かめる
失敗または実行中と表示されたジョブが、外部に何もしていないとは限らない。パッケージの公開、インフラ変更、通知、デプロイ開始まで終え、状態返却だけ失った可能性がある。
そのまま再実行すると、同じ変更を二度適用しかねない。リポジトリのイベント、Actions の履歴、runner のログ、成果物、実際の配備先を照合する順序が必要だ。同じ操作を繰り返しても結果が壊れない設計や検証可能なリリース番号は危険を下げるが、確認そのものは省けない。
CircleCI の再実行案内は同社が観測した状態への対処であり、パイプライン内部の副作用まで保証するものではない。テストだけならやり直しやすい。途中まで進んだ本番変更では、対象システムの現状に合わせた復旧が要る。
必要なのは波及経路を説明する原因分析
GitHub は04時44分に障害を解消扱いとし、詳細な原因分析を後日示すとした。公開情報からは、影響したサービスと復旧順序は分かる。最初に壊れた部品、API や他サービスへ広がった仕組み、再発防止の変更は分からない。
また、侵入、ソースコード消失、データ損失、特定顧客のデプロイ失敗、特定地域への集中、SLA クレジットを示す根拠もない。critical は GitHub の障害区分であり、各顧客の損害を表す数字ではない。
今後の説明では、最初の故障、ジョブの滞留、復旧中に生じた二次影響を分ける必要がある。それまでは結論を狭く保つべきだ。GitHub のサービス連鎖は戻った。顧客側の障害が終わるのは、イベント、実行履歴、配備先の三つが一致した時である。