失敗した要求の再試行は、依存先が要求を処理できる状態へ戻る場合に限って成功率を上げる。 依存先が容量不足で遅延しているときは、失敗のたびに新しい要求を作るため、回復に必要な処理能力まで奪う。
このとき、最初は一部の要求だけだった失敗が正の帰還を作る。 遅延がタイムアウトを増やし、タイムアウトが再試行を増やし、増えた要求がさらに遅延を悪化させる。
GitHubでは2026年8月に、この増幅が異なる経路で二度起きた。 8月6日のGitHub Actions障害では、実行環境が取り消し済みのジョブを割り当てられ、同じ無効な仕事を再試行し続けたため、基盤が回復し始めても滞留を解消できなかった。 8月17日の広域障害では、負荷分散装置と共有認証経路が飽和したところへ、利用側の不具合が内部認証APIへの再試行を増やし、部分的な性能低下を複数サービスの障害へ広げた。
したがって、再試行は個々の呼び出しだけで決めず、依存先が受けられる総量を基準に制限する必要がある。 試行回数と経過時間に上限を置き、待ち時間を段階的に延ばして開始時刻を分散し、同時実行数を制限すれば、失敗した要求が一斉に戻るのを防げる。 依存先が回復できない水準に達した場合は、遮断器や流量制限によって新しい仕事を早く拒否し、処理中の仕事と復旧処理のための容量を残す。
「再試行を入れれば耐障害性が上がる」という設計は不十分である。 再試行によって生じる追加負荷の上限と、依存先が飽和したときに要求を止める条件まで定義して、初めて再試行は耐障害性の仕組みになる。
https://github.blog/news-insights/company-news/github-availability-report-august-2026/