ホステッド runner インシデントとは？ - フロートがダウンするとき

ホステッド runner インシデントとは、CI プロバイダーの共有 runner フリートの停止または劣化（遅いプロビジョニング、詰まったキュー、失敗する job）であり、あなたの側からは修正できません。

ホステッド runner を使うと、フリートはプロバイダーの責任になります。それは壊れるまでは便利です。フリート全体のインシデントは全員の CI を一度に停止させ、復旧のために workflow の中で変更できるものは何もありません。

インシデントはどう見えるか

runner がプロビジョニングされないため、job がキューで詰まる。
すべてのリポジトリで runner の起動が遅い、または失敗する。
あなたのコードとは無関係な、断続的な job の失敗。

なぜ修正できないのか

フリートはプロバイダーによって完全に管理されているため、インシデント中はレバーがありません。自分の runner のリトライも、フェイルオーバーもできません。ステータスページが緑になるのを待つ間、チームの CI はブロックされます。

露出を減らす

runner の供給元を分散させることで影響範囲を制限できます。あるフリートでインシデントが起きても、別のプロバイダーで実行できる job は動き続けます。単一のフリートに依存することは、すべての CI の単一障害点を意味します。

マネージド runner によるレジリエンス

独立したマネージドフリート上で実行すれば、GitHub ホステッドのインシデントで build を止める必要はありません。あなたの job は別のインフラ上で動きます。Latchkey は GitHub ホステッドのフリートから独立しています。

インシデント vs 自分の設定ミス

インシデントのせいにする前に、それがフリート全体のものであることを確認しましょう。プロバイダーのステータスページと、他のリポジトリや組織も影響を受けているかを確認します。もし自分の job だけが詰まっているなら、原因はプロバイダーの停止よりも、自分の側の label、quota、権限の問題である可能性が高いです。

重要なポイント

ホステッド runner インシデントは、あなたが修正できないプロバイダーのフリート停止である。
すべてのリポジトリのキューを一度に止め、job を失敗させる。
単一フリートへの依存は、CI の単一障害点となる。
独立したマネージドフリートは、インシデントの影響範囲を減らす。