CI におけるインフラ障害とは？ - 解説

インフラ障害とは、あなたのコードではなく、job を実行しているプラットフォーム（runner、ネットワーク、プロバイダー）に起因する CI の失敗です。

build が赤くなると、変更の中の何かが壊れたと考えるのが自然です。しかし、job の下で動くプラットフォーム自体も失敗しえます。runner のプロビジョニングに失敗する、インスタンスが回収される、プロバイダーで一時的なインシデントが起きる、といったものです。こうしたインフラ障害は環境的なものであり、コードのバグのように扱うと多くの人の時間を無駄にします。

何がインフラに該当するか

runner のプロビジョニング失敗や、空のプールからの遅い取得。
job の途中でのスポットまたはプリエンプティブルインスタンスの回収。
プラットフォーム側のネットワーク、DNS、接続性の問題。
一時的なプロバイダーのインシデントやコントロールプレーンの不具合。

インフラ障害とコードの失敗

コードの失敗は再現可能です。同じ job を実行すれば、原因が変更の中にあるため同じように失敗します。インフラ障害は通常再現しません。プラットフォームの一時的な状態に依存するからです。再現性のテストは、最初の判断材料として最良のものです。

なぜ誤診しやすいのか

インフラ障害は、一般的または誤解を招くメッセージ、キャンセル、接続エラー、突然の停止として表面化することが多く、そのためテスト対象の変更のせいにされたり、ランダムな flaky として片付けられたりします。これを独立した環境的な種類として認識することが、問題解決の半分です。

どう復旧するか

インフラ障害は一時的なので、正しい対応はほぼ常にリトライであり、できれば新しい runner 上で行います。次の試行ではプラットフォームが異なる状態にあるため、通常は同じ失敗は再発しません。対照的に、本物のコードのバグをリトライしても分数を無駄にするだけです。

Latchkey の視点

インフラ障害こそ、自己修復 runner プラットフォームが吸収すべきものです。Latchkey のマネージド runner は、プロビジョニングの不具合、プリエンプション、ネットワークの一時障害といった一時的かつ機械的なインフラ障害を検知して自動的にリトライします。そのため、一度きりのプラットフォームの一時障害で build が失敗することはありません。

重要なポイント

インフラ障害は、あなたのコードではなくプラットフォームに起因する。
プロビジョニングの問題、プリエンプション、ネットワークの一時障害が典型的である。
コードの失敗は再現するが、インフラ障害は通常再現しない。
正しい対応はリトライであり、多くの場合は新しい runner 上で行う。