ロールバックjobとは? 不正なデプロイを元に戻す

ロールバックjobは、デプロイがうまくいかなかったときに直前の正常な既知バージョンを復元し、稼働中のシステムを素早く動作状態に戻します。

デプロイは失敗します。問題は、どれだけ速く復旧できるかです。ロールバックjobはpipelineの取り消しボタンです。壊れたリリースを置き換えるために、直前の正常な既知バージョンを再デプロイします。速く信頼できるロールバックは、本番のインシデントを長時間の障害から短い一瞬のつまずきへと変えます。だからこそ成熟したpipelineはロールバックを第一級のjobとして扱うのです。

ロールバックjobがすること

現在の壊れたartifactの代わりに、以前の正常なartifactをデプロイします。そのartifactはすでにビルドされ検証済みなので、ロールバックは通常、プレッシャー下での前方修正よりも速く安全です。

ロールバックが速さを保つ方法

再デプロイできるよう、以前のartifactを利用可能に保つ。
再デプロイが安全になるよう、デプロイを冪等にする。
手作業ではなく、ロールバックを自動化する。
明確なシグナル (health checkの失敗) から起動する。

簡単な例

app:${NEW} をデプロイした後、post-deployment checkが失敗します。ロールバックjobは、本番で通過した最後のバージョンである app:${PREVIOUS} を再デプロイし、チームが調査する間サービスを復旧します。

ロールバック vs ロールフォワード

ロールバックはすぐに正常な既知の状態へ戻します。ロールフォワードはバグを修正して再デプロイします。ロールバックはサービスを最も速く復旧するため、インシデント中の最初の一手として通常は正しい選択です。修正は落ち着いてから続ければよいのです。

ロールバックの信頼性

ロールバックは、すでに状況が壊れているときでも機能しなければならないため、頼れるものである必要があります。安定したエージェントと一時的なエラーへのリトライがここで重要です。マネージドrunner (Latchkey) はインフラの不調をリトライするため、ロールバック自体がインシデントのさなかに不安定なrunnerで脱線することがありません。

重要なポイント

ロールバックjobは、不正なデプロイの後に直前の正常な既知バージョンを再デプロイします。
プレッシャー下で前方修正するよりも、通常は速く安全です。
以前のartifactを利用可能に保ち、ロールバックを自動化して速さを維持しましょう。