要約

  • 障害は7月24日16時04分 UTC に始まり、詳細分析は7月29日02時36分25秒 UTC に追記された。
  • 三つある物理データセンター可用性ゾーンの一つで、単一ケージの spine スイッチと集約層との接続が失われた。
  • 利用可能な相互接続容量の25％が失われ、稼働中の残存経路が飽和してパケット損失が発生した。
  • Actions ジョブの10％が失敗し、5％は開始が遅れた後に成功した。Issues 操作の27％が低速またはタイムアウトとなり、Copilot 要求と git push は各4％が影響を受けた。
  • GitHub は将来増設用の光ファイバーへ迂回し、17時07分に損失を解消、17時36分に全経路を復元し、100Gbps から400Gbps への更新を加速する。

この開示を単なる障害件数として読むと、重要な部分を落とす。下層では同じパケット損失でも、上層では失敗、待ち時間、タイムアウト、自動再試行、書き込み結果の不確実性に分かれた。復旧後の確認も一種類では済まない。

29日に起きたのは再障害ではなく証拠の公開

サービスが損なわれたのは24日であり、その日のうちに公式インシデントは解決済みとなった。29日に新しく現れたのは、ネットワーク階層、容量低下率、製品別の影響、緊急迂回、恒久対策に関する具体的な説明である。

したがって「29日の GitHub 停止」と表現すれば、存在しない二度目の障害を作ることになる。25日や27日の別インシデントとも混同できない。公式 ID yjysg0xrl67m が今回の事実範囲を区切る。

説明には未確定部分もある。GitHub は接続喪失後に残存経路が飽和した仕組みを示したが、最初の接続喪失を起こした機器、保守作業、設定変更は示していない。伝播原因は具体化したが、起点までは公開していない。

同じ輻輳でも製品ごとに意味が変わった

各コンピュートケージには leaf-spine 構成があり、spine はゾーン内の集約層につながる。障害は一つのケージと集約層の間で起き、そのケージの計算資源に依存するワークロードが断続的な損失を受けた。

Actions では10％が失敗し、5％は遅れて開始した。Issues では27％の操作が遅いかタイムアウトした。Copilot は4％がエラーになったが、多くは自動再試行された。git push も4％が影響を受けた。認証は遅くなったものの、エラー率は1％未満だった。

これらは分母が異なるため、足して「全体障害率」を作ることはできない。意味があるのは変換の違いだ。キューを持つサービスは遅延し、対話操作はタイムアウトし、再試行機能は初回エラーを隠し、書き込みは成功済みか確認が必要になる。

復旧は将来用の容量を先に使った

GitHub は影響接続を、将来の容量増設に割り当てていた光ファイバーへ迂回した。17時07分にパケット損失をなくすだけの容量が戻り、17時16分には大半のサービスが完全復旧を示し、17時36分に全経路が正常化した。

三つの時刻は別の到達点である。十分なネットワーク余力、大半のアプリケーション復旧、全物理経路の復元は同義ではない。最後の緑色だけを残すと、段階的な回復が見えなくなる。

将来用ファイバーが緊急手段として機能した点は重要だ。ただし迂回中にどれほど余力が残ったか、その経路が現在ふたたび予備容量になっているかは公表されていない。

再実行の前に、外部状態を読む必要がある

GitHub の文書では、書き込み権限を持つ利用者が workflow 全体、失敗ジョブだけ、または特定ジョブを再実行できる。再実行は元の実行者の権限、commit SHA、Git ref を使う。しかし同じ文脈で動くことと、安全に二度実行できることは別である。

遅延ジョブは、新しい実行が始まった後で完了したかもしれない。応答に失敗した push でも、リモート参照が進んでいる可能性がある。クライアントでタイムアウトした Issue コメントも保存済みかもしれない。再送前に実際の状態と外部副作用を照合する必要がある。

Copilot の自動再試行は最終エラーを減らすが、初回成功率の低下を見えにくくする。認証もエラーが1％未満だから無影響とは限らない。遅延に敏感なクライアントでは、速度低下そのものが障害になる。

400Gbps 化は妥当だが、完了した証明ではない

旧型ケージは100Gbps インターフェースを使う。GitHub は400Gbps への予定済み更新を可能な限り加速し、経路または機器を失った際の帯域余裕を各層で増やすという。今回の飽和機構に直接対応する対策である。

一方、名目速度が四倍でも耐障害性が自動的に四倍になるわけではない。完了時期、旧型ケージ数、最低余力、許容する複合故障、検知や隔離の変更は未公表だ。

有効な合格基準は故障時の測定になる。一つのケージから集約層への経路を失っても残存リンクが飽和せず、障害対応ツールが使え、利用者より先に検知できるかが問われる。

物理台帳と業務台帳を同時に閉じる

顧客側は失敗・遅延 workflow の ID を保存し、リモート Git 参照を確認し、Issues 書き込みの重複を探し、初回失敗と再試行成功を分けて記録できる。復旧は要求を全部送り直すことではなく、実際の状態を整合させることだ。

GitHub の次の説明には、最初の接続喪失の起点、迂回後の余力、400Gbps 計画の範囲と日程、単一ケージ障害が残りを飽和させない制御が必要になる。増設用ファイバーが予備へ戻った時期も明確にすべきだ。

29日の分析は、抽象的なクラウド依存を物理量に戻した。相互接続容量の四分の一が消え、残った経路が満杯になり、利用者には同じ方法では片付けられない複数の復旧待ちが残った。

情報源