要約
- GitHub は7月22日20:43:43Z に事象
20frdtvv3yg6を開始し、22:09:26Z に解決とした。継続時間は85分43秒だった。 - GitHub ホスト型 runner の実行の約3％で、開始まで5分を超える遅延が発生した。
- 長い遅延後に一部が失敗する可能性があり、GitHub は原因を特定して22:01:57Z に緩和、約8分後に解決した。
- 分母は GitHub ホスト型 runner の実行であり、すべての Actions、自社ホスト runner、GitHub 全サービスではない。
- GitHub は根本原因分析を約束した。公表前に容量、地域、デプロイ、スケジューラ障害を原因と推測してはならない。
継続的インテグレーションのジョブには二つの時計がある。一つはキューに入った時から動き、もう一つは runner が実際に命令を実行してから動く。チームはキャッシュ、軽量イメージ、並列試験で後者を短縮するが、前者はプラットフォーム側でほぼゼロだと考えがちだ。
今回の事象は最初の時計を可視化した。世界規模では3％は少数である。しかし、その範囲に入った一つのリリースにとって、重要経路は完全に待たされた。
実行環境を買うとスケジューリングにも依存する
ホスト型 runner を使えば、ビルド機の調達、修正、容量拡大を自社で行わずに済む。代わりに、ジョブ受付、地域容量、イメージ、割り当てが外部依存になる。
キュー待ちは遅いビルドとは異なる。顧客コードがまだ動いていないため、ログに診断材料が少ない。再実行は同じ制約されたプールへ需要を増やし、デプロイを重複させたり、原因を直さず利用枠を消費したりする可能性がある。
公表値の境界は明確だ。GitHub はホスト型 runner 実行の約3％が開始まで5分超かかり、そのうち一部が長い遅延後に失敗し得ると述べた。Actions 全体の3％が失敗したとも、自社ホスト runner に影響したとも述べていない。
85分は一つの変更時間帯を越える
記録は20:43:43Z に始まり、22:01:57Z に緩和、22:09:26Z に解決した。全体で85分43秒、緩和から終了までは約8分である。
通常のブランチ確認なら不便で済む。時間指定の本番リリース、証明書更新、セキュリティ対応、基盤変更では、同じ待ち時間が許可済み時間帯を使い切る。影響は世界全体の率より、どのジョブが3％に入ったかで決まる。
回数を制限した再試行、同時実行制御、明確なタイムアウト、重要ジョブ用の代替手順はリスクを下げる。自社 runner や第二の提供者は冗長性を作る一方、保守、認証情報、ネットワーク、供給網リスクを戻す。無料の切り替えではない。
根本原因はまだ公開されていない
GitHub は緩和前に原因を特定し、根本原因分析を公表するとした。この記事で確認できる記録には仕組みがない。容量不足、デプロイ、特定地域、スケジューラ欠陥のいずれかに帰属させるのは推測になる。
原因が不明なため、顧客側の合理的な対策にも限界がある。一度限りで修復済みなら並行基盤の方が高くつく。再現可能な容量・割り当て問題なら、厳格なリリース目標を持つチームは明確な退避経路を必要とする。
有用な次の資料は憶測ではなく分析報告だ。何が引き金となり、なぜ一部だけが5分を超え、長い待ちがどう失敗へ進み、緩和が何を変え、どの制御が再発を防ぐかを説明すべきである。
大半の利用者は気づかなかったかもしれない。限定された分母だからこそ運用上の価値がある。ホスト型 runner はサーバーをサービスへ変えるが、実行待ち行列をソフトウェア供給網から消さない。その責任を GitHub へ移す。