ロールバック後のシステム回復: ボタンをクリックするだけでは不十分
実稼働環境でのデプロイメントの変更で問題が発生した場合、最も一般的な対応はロールバックです。ただし、ロールバックはコードまたは構成を前のバージョンに復元するだけであり、自動システム回復が利用可能であることは保証されません。データベースの移行、キャッシュ内のダーティなデータ、およびダウンストリームの依存関係のステータス変化によって引き起こされる非互換性により、ロールバック後にシステムが準正常な状態または使用不可能な状態のままになる可能性があります。本当に必要なのは、完全な回復プレイブックを実行して、システム セキュリティを安定状態に戻し、それが利用可能であることを確認することです。
最も可能性の高い障害シナリオ: 変数が回復されておらず、ダーティなデータが残っている
シナリオ: データベース移行のロールバックがデータと矛盾する
一般的な失敗シナリオを考えてみましょう。データベースの移行、新しいテーブルの追加、古いテーブル構造の変更を含むデプロイメントを実行します。オンライン化後、パフォーマンスが低下していることが判明したため、実行コードを古いバージョンにロールバックしました。ただし、移行操作はロールバックされず、新しいテーブルはまだ存在し、古いテーブル構造は変更されています。古いコードが古い構造に書き込もうとすると、エラーが直接報告されたり、不整合が発生したりする可能性があります。さらに巧妙なことに、移行中に書き込まれた新しいデータが古いビジネス ロジックと競合し、ユーザーに見えるエラーが発生します。
障害点: ロールバック スクリプトにデータ移行の逆操作が含まれていない、または逆操作の順序が間違っています (たとえば、新しいテーブルが最初に削除されますが、古いテーブルには新しい構造に依存するレコードが既に存在します)。
もう 1 つの一般的なシナリオ: 構成センターとロールバックが同期していない
構成アイテムは構成センターを通じて配信されます。このデプロイメントにより、コードと構成の両方が変更されます。コードがロールバックされた後、構成がロールバックされず、古いコードが新しい構成を使用することになりました (接続文字列が間違ったクラスターを指しているなど)。
ロールバック回復手順: 停止から確認までの 7 つの主要なアクション
以下は、実稼働環境で実証済みの回復プレイブックの中心的な手順です。各ステップには明確な判定条件と失敗時の対応が用意されています。
- 変更の拡散を直ちに停止: 変更がまだグレースケールまたはバッチでリリースされている場合は、後続のトラフィック アクセスを停止します。ロールバックを確認するまでは、障害領域の拡張を続行しないでください。
- コード/構成のロールバックを実行: git revert を使用して以前のリリースのコミットにロールバックするか、CI/CD を通じて以前のビルドにロールバックします。構成の場合、構成センターも同期的にロールバックされるようにしてください (履歴バージョンに従ってロールバックします)。
- データ移行の逆方向操作の実行: この変更にデータベースの移行が含まれる場合は、逆方向の移行を実行します (Flyway または Liquibase の元に戻すスクリプトを使用するなど)。逆移行の準備ができていない場合は、SQL を手動で実行して古い構造を復元する必要があります (現時点ではバックアップからの復元を優先する必要があります)。
- キャッシュのクリーン: 古いコードによって書き込まれた互換性のない形式のデータが、ロールバック後にキャッシュに残る場合があります。関連するキャッシュ層 (Redis、Memcached、または CDN キャッシュ) をクリアします。注: キャッシュが完全にクリアされると、なだれが発生する可能性があります。ビジネス上の観点から段階的に廃止またはウォームアップすることをお勧めします。
- 依存関係ステータスの確認: ダウンストリーム サービス (API、メッセージ キュー、データベース) が予期されたバージョンであるかどうかを確認します。たとえば、サービス A をロールバックしますが、サービス A に依存するサービス B は、A が正しく処理できなくなった新しい形式に基づいてリクエストを送信した可能性があります。現時点では、B の消費を一時停止またはダウングレードする必要があります。
- 段階的なボリューム検証: 少数のユーザー グループ (例: 1%) にトラフィックを復元し、エラー率、遅延、主要なビジネス指標を監視します。ロールバックの前後でベースライン データを比較します。
- 継続観察: 少なくとも 30 分間 (または完全なビジネス サイクル) 観察し、異常がないことを確認した後、徐々にフル容量に戻します。
間違いを犯しやすいステップはステップ 3: 多くのチームはコードのロールバックのみに重点を置き、データのロールバックを無視しているため、「古いコード、新しいデータ」という矛盾した状態が生じます。すべてのデータベース変更には可逆スクリプトを伴い、プレリリース環境で検証する必要があることに事前に同意する必要があります。
権限の境界: ロールバック回復を実行する権限を持っているのは誰ですか?
ロールバック回復はストレスのかかる操作であり、権限制御が不適切だとさらなるリスクが生じる可能性があります。
- 実行ロールバックの決定: 通常、ランブックに基づいてオンコール エンジニアまたは SRE によって判断されますが、大きな変更 (サイト全体に影響するなど) については、確認のためにチーム リーダーに通知する必要があります。
- コード ロールバック: CI/CD サービスまたは承認された管理者のみがロールバック パイプラインをトリガーできます。各開発者が運用環境に直接ロールバックすることは避けてください。
- データ ロールバック: データベース ロールバック スクリプトは、DBA またはバックアップ回復権限を持つロールのみが実行する必要があります。自動ロールバックスクリプトは「ドライラン」モードに追加し、実行するSQLを出力してから手動で確認する必要があります。
- 構成ロールバック: 構成センターは変更監査と高速ロールバックをサポートする必要があり、ロールバック操作は監査ログに記録される必要があります。
境界例: 障害がユーザーの中核業務に深刻な影響を与える場合、権限ポリシーは「緊急バイパス メカニズム」を設定して、指定されたロールが特定の承認手順をスキップし、その後理由を記録できるようにする必要があります。
ロールバック失敗時のフォールバック パス: ロールバック自体が信頼できない場合
完全なリカバリ プレイブックを使用しても、ロールバックが失敗することがあります。たとえば:
- ロールバック後にサービスを開始できません (古いコードは、削除されたライブラリまたは期限切れの証明書に依存しています)。
- データの逆移行により、さらに不整合が発生しました。
- ロールバック プロセス中にネットワークが中断されたため、一部のノードが混合状態になりました。
代替案 1: スナップショットから復元する
最新の完全バックアップ (完全スナップショット) から復元します。これは通常、ロールバックよりも完全ですが、回復時間 (RTO) が長くなります。データ層に障害が発生し、逆移行では修復できないシナリオに適しています。スナップショットの回復プロセスを定期的にリハーサルしてください。
代替案 2: 代替環境への並行切り替え
アーキテクチャが Blue-Green デプロイメントをサポートしている場合、ロールバックが失敗したときにトラフィックをグリーン環境 (古いバージョン) に直接切り替えることができます。グリーン環境が最新のデータ同期を維持しているかどうかに注意してください。そうでない場合は、最初にデータ移行を実行するか、部分的なデータ損失を受け入れる必要があります。
代替案 3: ダウングレードとサーキット ブレーカー
完全なリカバリが不可能な場合は、ダウングレード機能を有効にすることができます。つまり、コア以外の機能をオフにして、コア リンクが確実に利用できるようにします。たとえば、推奨アルゴリズムを一時的にオフにして、人気のあるデータのみを返します。直接的な失敗を避けるために、書き込み操作を非同期キューに変更します。ダウングレード後は、正常に回復できるまで根本的な問題の修正を続けてください。
重要な決定事項: ロールバックが失敗した後は、ロールバックを繰り返し試行しないでください。より深刻なデータ破損が発生する可能性があります。まず、代替ソリューションに切り替えることが適切かどうかを評価し、緊急対応プロセスに入るようにチームに通知する必要があります。
次のステップ: リカバリの実践を自動化とチームの能力に変える
この記事で提供されるプレイブックは基本的なフレームワークであり、各チームは独自のシステム特性に応じてカスタマイズする必要があります。重要なのは、手順を暗記することではなく、その手順を確実にリハーサルし、導入プロセスに反映させることです。
AI の支援を利用してこの種の回復メカニズムを設計および作成する方法、および通常の開発者からエンジニアリング上の判断力を備えたエージェント エンジニアに変身する方法をより体系的に学びたい場合は、関連コースをさらに検討することを検討できます。
コメントはまだありません