次のデプロイ前に復旧計画が必要な理由

アプリケーションの新バージョンを本番環境にプッシュした直後、ユーザーからログインできないとの報告が相次ぐ。エラーレートが急上昇し、データベースの応答時間は3倍に跳ね上がる。チームのチャットは悲鳴で埋め尽くされ、「ロールバックすべきか？」と誰かが問いかける。「サーバーで直接修正してみる」と言う者もいれば、一度もテストしたことのないコマンドを打ち始める者もいる。

この光景は、チームの規模を問わず繰り返される。共通する問題はバグそのものではない。計画の欠如だ。デプロイ中に何かがうまくいかなかったとき、チームには冷静に考える時間がない。不完全な情報のもと、ユーザーが待ち、マネージャーが状況報告を求めるプレッシャーの中で行動しなければならない。その瞬間、迅速な復旧と長期障害の分かれ目は、多くの場合たった一つの要素に集約される。それは、デプロイ開始前にチームが何をすべきかをすでに決めていたかどうかである。

インシデント発生時の場当たり的判断の問題

デプロイが失敗したとき、直感的にその場で対処法を考えようとする。誰かが以前のバージョンへのロールバックを提案する。別の誰かは本番サーバーに直接パッチを当てたいと言う。さらに別の人物は、問題が安定するまで様子を見るべきだと主張する。こうした議論は貴重な時間を浪費する。議論の1分1分が、より多くのユーザー影響、より多くのエラーログ、そしてチームへのさらなるプレッシャーを生む。

より大きなリスクは、計画外の行動によって事態がさらに悪化することだ。本番サーバー上のファイルを手動で編集したり、部分的なバックアップをリストアしたり、テストせずにデータベースコマンドを実行したりすると、新たな問題を引き起こす可能性がある。ログインページが壊れただけの状態が、データ不整合、データベース破損、あるいは完全なサービス停止に発展しかねない。

復旧計画を準備していないチームは、本質的にギャンブルをしている。デプロイがうまくいくことを願い、もしうまくいかなければ、誰かが正しい対処法を知っていることを願う。それは戦略ではない。希望的観測に過ぎない。

復旧計画の本質

復旧計画とは、共有ドライブに置かれて年に一度読まれる分厚いドキュメントではない。それはデプロイ前に下された一連の判断であり、プレッシャー下でもチームが実行できる形で書き留められたものだ。計画は具体的な問いに答える。

  • どのような条件でデプロイを停止し、復旧を開始するのか？
  • その判断を下す権限を持つのは誰か？
  • 以前のバージョンにロールバックするのか、修正を加えてロールフォワードするのか？
  • 選択した復旧アクションを実行する正確な手順は何か？
  • 復旧が成功したことをどのように確認するのか？

小規模チームであれば、計画は5つのステップからなるチェックリストかもしれない。複数のサービスと依存関係を持つ大規模チームであれば、計画には連携ポイント、コミュニケーションチャネル、エスカレーションパスが含まれる。複雑さはシステムに応じてスケールするが、原則は変わらない。デプロイする前に判断を下せ、ということだ。

準備が重要な理由

復旧計画が問題発生後ではなく、デプロイ前に存在しなければならない理由は4つある。

第一に、インシデント発生時には時間が味方しない。ダウンタイムの1分1分が、収益の損失、ユーザーの不満、評判の低下といったコストを生む。チームが何をすべきか考え込む時間があれば、復旧時間は増加する。事前に定義された計画は思考のステップを排除する。チームは新しい対応を考え出す代わりに、既知のアクションを実行する。

第二に、計画がなければ、人によって何をすべきかの意見が分かれる。あるエンジニアは即座にロールバックしたいと考える。別のエンジニアはまず調査したいと考える。さらに別のエンジニアはホットフィックスを適用したいと考える。これらの意見の相違は遅延と混乱を生む。復旧計画はこれらの問いを事前に解決する。全員がデフォルトのアクションを知っており、そこから逸脱すべきかどうかを判断する権限者が誰かも分かっている。

第三に、一部の復旧アクションはその場で準備できない。データベースを以前の状態に戻すには、適切なフォーマットと保持ポリシーで取得されたバックアップが必要だ。モバイルアプリケーションのロールバックには、以前のバージョンが署名され、配布可能な状態で準備されている必要がある。これらの準備はデプロイ前に行わなければならず、障害発生後では遅すぎる。

第四に、テストされたことのない計画は単なる理論に過ぎない。チームは障害シナリオをシミュレートし、安全な環境で復旧手順を実行すべきだ。これにより、計画のギャップ、不足している権限、古いスクリプト、実際には成立しない前提が明らかになる。計画をテストすることで、それはドキュメントからケイパビリティへと変わる。

復旧は悲観主義の表れではない

復旧計画の作成をためらうチームもある。それはデプロイプロセスへの信頼の欠如を示すと感じるからだ。それは間違った考え方だ。復旧計画は失敗を予期しているという認めることではない。複雑なシステムは予測不可能な振る舞いを持つことを認識し、準備をすることが責任ある行動だということだ。

成熟したチームは、デプロイを成功させることだけに注力しない。デプロイが期待通りに進まない可能性にも備える。彼らは復旧を、緊急時のみに発動される例外的な手順としてではなく、デリバリープロセスの正常な一部として扱う。

二つの主要なアプローチ：ロールバックとロールフォワード

復旧計画が必要だと理解したら、次はどの種類の復旧を使うかだ。最も一般的な二つのアプローチは、ロールバックとロールフォワードである。

ロールバックとは、システムを以前の正常な状態に戻すことだ。デプロイを取り消し、以前実行されていたバージョンに戻す。問題が明確で、以前のバージョンが安定している場合、これが最も単純なアプローチとなる。

ロールフォワードとは、問題を修正する新しいバージョンをデプロイすることで、古いバージョンに戻らない方法だ。このアプローチは、以前のバージョンに独自の問題がある場合、ロールバックがデータ損失を引き起こす場合、または修正が十分に小さく迅速にデプロイできる場合に有用である。

各アプローチにはトレードオフがある。ロールバックはより単純だが、すべての種類の変更に適用できるとは限らない。ロールフォワードはシステムを前進させ続けるが、プレッシャーの中で修正を開発しテストする必要がある。適切な選択は状況に依存する。だからこそ、デプロイ前にその判断について議論し文書化すべきなのだ。

以下のフローチャートは、各復旧パスの判断プロセスと手順をまとめたものである。

flowchart TD A[デプロイ失敗] --> B{ロールバックは安全か？} B -->|はい| C[ロールバック] B -->|いいえ| D[ロールフォワード] C --> E[コードを戻す] E --> F[DBを戻す] F --> G[システム確認] D --> H[修正を作成] H --> I[修正をデプロイ] I --> J[システム確認]

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

デプロイ前に、チームでこのチェックリストを確認しよう。

  • 復旧をトリガーする条件について合意しているか？
  • ロールバックかロールフォワードかを判断する権限者が誰か分かっているか？
  • 復旧の正確な手順が文書化され、アクセス可能か？
  • ステージング環境で復旧手順をテストしたか？
  • 必要なバックアップ、アーティファクト、権限は準備できているか？
  • チームの全員が計画の場所を知っているか？

これらのすべてに「はい」と答えられなければ、デプロイの準備はできていない。

まとめ

復旧計画のないデプロイは、デプロイではない。それは願望だ。数分で復旧するチームと、何時間も混乱に陥るチームの違いは、技術スキルではない。それは準備である。何かがうまくいかなくなる前に何をするかを決め、それを書き留め、テストし、全員が計画を知っていることを確認せよ。それこそが、復旧をパニックから手順へと変える方法だ。