デプロイ後の判断：Promote、Hold、Rollback、Roll-Forward、Pause、Disable

デプロイが完了しました。新しいバージョンが本番環境で稼働し、実際のトラフィックを処理しています。パイプラインはグリーン、ログは流れ続け、モニタリングダッシュボードには最新データが表示されています。さて、次はどうするべきでしょうか？

デプロイが成功したと宣言するまでのこの瞬間こそ、多くのチームが立ち往生するポイントです。すぐに完了と決めつけて次に進むチームもいれば、今見えているのが正常な変動なのか、それとも障害の始まりなのか判断できずに固まってしまうチームもいます。実際のところ、デプロイが完了したことは判断の終わりではなく、判断の始まりです。

可観測性シグナルが届き始めたら、次に取れる道は6つあります。それぞれ異なる状況に適合し、異なる結果をもたらします。どれを選ぶべきか、いつ選ぶべきかを理解しているチームは、デプロイに自信を持って対応できます。そうでないチームは、ただ上手くいくことを願うだけです。

Promote：バージョンが良好

Promoteは、新しいバージョンを正式な本番バージョンとして宣言することを意味します。すべてのトラフィックはそのバージョンに留まり、古いバージョンはアーカイブまたは削除できます。これは誰もが望む結果ですが、パイプラインが通ったからといって決して急いではいけません。

Promoteを実行するのは、すべての可観測性シグナルがSLOの境界内に収まっている場合です。エラー率は正常、レイテンシは急上昇していない、エラーバジェットは健全、スモークテストも本番で合格しています。データがパイプラインの示唆を裏付けています。このバージョンは安全です。

ここでの落とし穴は、早すぎるPromoteです。グリーンパイプラインはビルドとテストが通ったことを示しますが、本番での振る舞いが検証されたわけではありません。新しいバージョンに十分な時間を与え、意味のあるデータが蓄積されてから完了と判断しましょう。2分間は安定していても、10分後に問題が顕在化することがあります。

Hold：まだ確信が持てない

Holdは、新しいバージョンを稼働させ続けるものの、まだ正式バージョンとして宣言しないことを意味します。より多くのデータを待っている状態です。トラフィックがまだ増加途中だったり、小さな異常が見えているが、それがノイズなのか、より深刻な事態の始まりなのか判断できない場合などです。

Holdは安全な中間地点です。パニックにはなっていませんが、祝賀ムードでもありません。バージョンはトラフィックを処理し続け、その間パターンを観察します。重要な結果として、このデプロイが解決されるまで次のデプロイを開始できません。Holdはパイプラインをブロックしますが、これは意図的です。不確実性の上にさらに変更を積み重ねる前に、チームに調査を強制します。

このオプションは、何かがおかしいという直感はあるが、確固たる証拠はまだない場合に適しています。その感覚を信じてください。データが明確に「Promote」を示していないなら、無理に進める必要はありません。

Rollback：動作していた状態に戻す

Rollbackは、以前の安定したバージョンに戻すことを意味します。新しいバージョンを引き上げ、古いバージョンを再び稼働させます。これは失敗のように感じるかもしれませんが、そうではありません。悪い状況からの制御された撤退です。

Rollbackを実行するのは、エラー率がSLOを超えた場合、エラーバジェットが予想よりも速く消費されている場合、または重大な障害が検出された場合です。基準は明確で客観的です。数値が新しいバージョンは古いバージョンより劣っていると示しているなら、躊躇してはいけません。

注意点は、Rollbackは事前に準備しておかなければ機能しないということです。メカニズムは緊急時ではなく、その前にテストしておく必要があります。後方互換性のないデータベース変更があるとRollbackが不可能になるため、代替手段としてRoll-Forwardが存在します。

Roll-Forward：戻すのではなく、前方で修正する

Roll-Forwardは、現在のバージョンを稼働させたまま、問題を修正する新しいバージョンをすぐに作り始めることを意味します。元に戻す代わりに、問題のあるリリースの上に修正を重ねます。

このオプションは、問題が小さく、チームが迅速に修正を生成できる場合に有効です。また、Rollbackが不可能な場合の唯一の選択肢でもあります。例えば、データベースマイグレーションによってスキーマが変更され、古いコードでは処理できなくなった場合などです。

Roll-Forwardには、修正が実際に機能するという確信が必要です。推測で行うと、状況を悪化させる可能性があります。また、チームに迅速な納品を求めるプレッシャーがかかり、性急な判断につながる恐れがあります。Roll-Forwardは、道筋が明確な場合にのみ使用し、上手くいくことを願って使うものではありません。

Pause：停止して調査

Pauseは、現在実行中のものを変更せずにデプロイプロセスを停止することを意味します。新しいバージョンはそのままですが、調査が完了するまでそれ以上のデプロイは進められません。

Pauseを使用するのは、何か奇妙なことが見えるが、Rollbackを実行するほど深刻ではない場合です。あるリージョンでレイテンシがわずかに増加した。エラー率は上がったがSLOの範囲内。1つのエンドポイントだけが異常な動作を示しているが、他はすべて正常。

Pauseは、より大きな判断を下す前に、何が起こっているのかを理解する時間を稼ぎます。不必要なRollbackや時期尚早なPromoteを防ぎます。代償としてパイプラインがブロックされますが、それは誤った判断を下すことに比べれば小さな代償です。

Disable：問題のある部分を無効にする

Disableは、バージョン全体を元に戻すことなく、特定の機能や機能性を無効にすることを意味します。これにはフィーチャーフラグや、個々の機能を独立して切り替えるメカニズムが必要です。

これは最も軽い介入です。問題を起こしているのが1つの機能だけ（新しい検索アルゴリズム、再設計されたチェックアウトフロー、変更されたAPIエンドポイントなど）であれば、その機能だけをオフにし、他のすべては稼働し続けることができます。ユーザーはその1つの機能にアクセスできなくなりますが、アプリケーションの残りの部分は正常に動作します。

Disableは、問題が隔離されている場合、Rollbackよりも高速で安全です。また、デプロイ全体を中断することなく、特定の機能を修正する時間をチームに与えます。前提条件として、アーキテクチャが細かいトグルをサポートしている必要があります。これは頻繁にデプロイする場合に投資する価値があります。

選択方法

正しい判断は、3つの要素に依存します。問題の深刻さ、残っているエラーバジェットの量、チームがどれだけ迅速に対応できるかです。SLOを定義し、エラーバジェットを追跡しているチームは、これらの判断のための客観的な基準を持っています。エラーバジェットがほぼ枯渇している場合、小さな異常でもRollbackを正当化するかもしれません。エラーバジェットが豊富にある場合、さらに調査するためにHoldやPauseを選択するかもしれません。

以下の判断ツリーは、可観測性シグナルを適切なアクションにマッピングします。

避けるべきことは、これらの判断を直感だけで行うことです。データが明確な場合、道筋も明確です。データが不明瞭な場合、明確になるまでHoldまたはPauseを選択しましょう。

デプロイ判断のための実践的チェックリスト

• 意味のある可観測性データが蓄積されるのに十分な時間を待ちましたか？
• すべてのシグナルがSLO境界内にあるか、それとも調査が必要な異常がありますか？
• テスト済みのRollbackメカニズムは準備できていますか？それともデータベースの変更によってブロックされていますか？
• 問題は独立して無効にできる1つの機能に限定されていますか？
• Roll-Forwardを選択した場合、チームは迅速に修正を構築するキャパシティがありますか？
• パイプラインはHoldまたはPauseによってブロックされていますか？そして、その理由は全員が理解していますか？

まとめ

デプロイは、コードが実行されている時点では終了していません。次に何をするかについて自信を持って判断できるだけのデータが揃った時点で終了します。6つの選択肢（Promote、Hold、Rollback、Roll-Forward、Pause、Disable）は、その判断のための語彙を提供します。推測ではなくシグナルに基づいて、意図的にこれらを使用してください。デプロイしたバージョンが最終的な答えではありません。その動作を観察した後に下す判断こそが、最終的な答えなのです。