要約

  • GitHub が事故記録 qcvjkzcs7j74 を詳しく更新したのは8月11日で、実際の影響時間は8月6日15時05分 UTC から7日00時14分 UTC までだった。
  • 最大時にはワークフロー実行の71％でインフラ障害が発生し、残りのうち75％は5分を超えて遅延した。
  • 通常のデプロイによる pod 交換が既存の容量・同時実行上の弱点を露呈させ、残存サービスの飽和から複数クラスタへ障害が連鎖した。
  • 容量増強、webhook 起点の流入制限、バックログ処理の拡大で第一段階は回復した。
  • 無効ジョブの再取得を続ける潜在バグが第二段階を生み、一部 ARC runner は手動復旧、未処理イベントの一部は手動再実行が必要になった。
  • GitHub は保護策と自動復旧を強化するとしているが、実装済みか、再発時に機能するかはまだ確認できない。

復旧後に残った処理を先に数える

サービスが operational へ戻っても、push や pull request の一部は処理されず、自動再生もできなかった。さらに、事故中の緩和策で停止状態に残った Actions Runner Controller の runner があり、手動対応が必要だった。

利用者にとっての終了点は、ステータスページの解決時刻ではなく、予定していた処理が実行、再実行、または明示的な破棄のいずれかに分類された時点になる。

71％と75％は母集団が違う

71％は全ワークフローに対するインフラ失敗の割合である。75％は、その71％を除いた残りの実行について、5分超の遅延が発生した割合だ。二つを足したり、残り29％を正常完了と見なしたりはできない。

一方で、失敗と待ち時間を分けた開示は、顧客がエラー再試行と納期遅延を別々に評価する材料になる。

通常デプロイが予備容量を試した

イベントを処理して Actions ジョブを生成する内部サービスで pod が交換された。交換中の残存容量が需要を支えられず、飽和、クラッシュ、複数クラスタと下流サービスへの連鎖が起きた。

必要な余力は平常時のピークだけでは測れない。更新中に一時離脱するインスタンスと、同時実行の偏りを吸収できるかがデプロイ安全性を決める。

スループット回復だけではキューは直らなかった

GitHub は容量を増やし、webhook から入る処理を絞り、バックログ処理能力を上げた。その後、割り当てサービスが既に無効なジョブを runner へ渡し、runner が取得を繰り返す問題が顕在化した。

無効な参照を止める変更によって、ようやく有効ジョブへ進み、キューを縮小できた。量の問題に見えた障害には、ジョブ状態の整合性という別の制御面があった。

8月11日は説明の時計である

障害そのものは7日に解決している。11日の更新は原因、影響比率、緩和策を公開した時点であり、新しい停止でも、障害時間の延長でもない。

運用時刻と説明時刻を分離すれば、可用性の長さと、原因説明までの時間をそれぞれ正しく評価できる。

改善項目は検証可能な形が必要になる

GitHub はデプロイ・容量保護、前兆監視、キューと runner 割り当ての耐障害性、連鎖抑制、自動復旧を改善するとしている。公開された故障経路には対応している。

ただし、閾値、提供版、導入率、試験結果は示されていない。次の Runner や ARC リリースで自動復旧が確認できるかが最初の具体的な証拠になる。

リポジトリ側の台帳が最後の空白を埋める

想定イベント、run ID、終了状態、生成物を記録すれば、再生されなかったトリガーと、遅れて完了した処理を区別できる。無条件の再実行による重複も防げる。

プロバイダーの復旧は現在の入口を証明する。顧客の照合は、事故中に意図した作業が最後まで処理されたことを証明する。

情報源