GitHubセルフホステッドランナーの最低バージョン強制停止にどう対応するか
強制停止は「猶予」ではなく「自律運用テスト」
GitHub Changelogで、self-hosted runnerの最低バージョン強制が一時停止されたと告知されました。この種の発表を「更新を後回しにしても問題ない」というサインだと解釈するのは危険です。
多くの場合、強制停止はエコシステム側の準備状況を考慮した措置であり、パッチ適用の重要性が下がったわけではありません。むしろ、外部の締切に依存せず、内部ポリシーで更新規律を維持できるかが問われる局面です。
ランナーバージョンドリフトが起こす実害
self-hosted runnerは、コードからデプロイまでの供給路に位置します。ここでバージョン差分が広がると、次の問題が同時発生します。
- ビルドホストの脆弱性修正遅延
- 環境差による再現不能なジョブ失敗
- プラグイン/ツールチェインの相性崩れ
- 監査時の証跡不整合
この影響は、失敗率上昇として遅れて見えるため、検知が後手になりやすい点が厄介です。
外部期限に依存しない最低バージョン方針
プラットフォームチーム側で最低バージョンポリシーを明文化します。
- 安定版を基準に「内部最低バージョン」を設定
- 新版リリース後の猶予期間（例: 14日）を固定
- 猶予終了後は基準未満ランナーでのジョブ受理を停止
- 例外は期限・責任者・理由を必須化
これで更新が「善意の努力」から「管理された統制」に変わります。
プール分離で安全性と可用性を両立
すべてのランナーを同じ運用で扱うと、更新時の障害影響が大きくなります。重要度でプールを分離します。
- 本番隣接プール: 更新SLA厳格、ネットワーク制限強化、ハードニング済みイメージ
- 汎用プール: 定期更新 + カナリア適用
- 実験プール: 高速更新、権限分離徹底
この分離により、全体停止を避けながら更新速度を維持できます。
Golden Image + 使い捨て更新への移行
長寿命ホストへの逐次アップデートは状態汚染を蓄積します。推奨は不変更新です。
- イメージパイプラインでrunnerと依存を更新
- スモークジョブ群で検証
- プール単位で置換
- 旧ノードを速やかに退役
この方式はロールバック判断も明確にし、障害調査を短縮します。
見るべき指標
運用の健全性は「更新した気がする」では測れません。週次で以下を追跡します。
- 基準以上ランナー比率（compliance rate）
- パッチ遅延中央値（日数）
- ランナー環境起因のジョブ失敗率
- 例外件数と滞留日数
- ランナー障害が与えたデプロイ遅延
指標を意思決定に接続して初めて、更新が経営的にも説明可能になります。
45日リカバリープラン
Day 1-7: バージョン棚卸し、責任者紐付け、重要度分類。
Day 8-21: Golden Image整備とカナリア置換。
Day 22-35: 本番隣接プールで内部最低バージョン強制。
Day 36-45: 全体展開、例外レポート公開、次四半期SLOへ接続。
段階的に進めることで、品質を落とさず統制を回復できます。
まとめ
GitHubの強制停止は「待機」ではなく「自律運用の成熟度テスト」です。外部締切が揺れても内部統制を維持できる組織こそ、CI基盤の信頼性とセキュリティを長期的に守れます。
