要約

  • GitHub はインシデントを major と分類し、正確な状態時間は1時間45分20.200秒だった。
  • 対象は Actions、Issues、Webhooks、Pull Requests の4サービスだった。
  • Actions ジョブは開始に時間がかかり、Issues 検索は古い結果を返す可能性があると説明された。
  • GitHub は09:22:21 UTC に遅延の発生源を特定して修正を適用したと発表し、処理待ちの解消を監視した。
  • 09:39:19.558に解決し、詳細な根本原因分析を後日共有するとした。

インシデントの時間は、開始と終了の差から正確に計算できる。07:53:59.358から09:39:19.558までで、1時間45分20.200秒である。

「約105分」は読みやすい表現だが、精密な監査ではミリ秒までの記録が残る。一方、この値を全顧客の停止時間と読むことはできない。GitHub は影響した利用者、リポジトリ、ジョブ、イベントの数を公表していない。

利用者ごとの症状と回復時刻も異なり得る。状態ページはサービス全体の履歴であり、各組織の生産性損失を直接測る台帳ではない。

4サービスは同時に戻らなかった

最初の更新では Actions、Issues、Webhooks の可用性低下が示され、後から Pull Requests が追加された。Actions は partial outage、他の関連面は degraded performance として記録された。

GitHub は08:34:23に、Actions ジョブの開始遅延、Issues 検索の古い結果、他サービスの類似影響を説明した。

Issues は09:18:37、Actions は09:19:49に緩和された。09:22:21には遅延源を特定し修正を適用したと発表したが、残るサービスでは処理待ちが解消中だった。

Pull Requests は09:27:35、Webhooks は09:35:17に正常化を報告し、全体の解決は09:39:19だった。修正、個別サービスの回復、全体終了は別の段階である。

顧客側の時計はさらに長くなることがある

Actions が遅れると、テストやデプロイ判断が待つ。Issues 検索が古いと、チームは表示と実際の記録を照合する。Webhook が遅れているか不達か分からなければ、接続先システムも確認が必要になる。

処理待ちがある状態で再実行すると、元の仕事が後から動いた場合に重複の可能性が生まれる。今回重複が発生したと GitHub が述べたわけではない。利用者がそのリスクを管理する条件が存在した。

GitHub は遅延の発生源を特定したとしたが、具体的なコンポーネント、変更、依存先は公表していない。詳細な RCA を共有すると約束した。現時点で原因をデータベースや外部クラウドなどに限定する根拠はない。

このインシデントは7月22日のホステッドランナー遅延とも区別される。時刻、対象製品、公開された症状が異なり、連続発生だけで同一原因とは言えない。

次の検証材料は RCA である。発端、4サービスへの伝播、隔離策、処理待ちの安全な解消が説明されるまで、結論は時間記録の範囲に留めるべきだ。重大状態は1時間45分20秒、顧客の整合確認はその外側にも延び得る。

情報源