高リスクなインフラ変更のためのリカバリープラン

もうすぐ本番環境を壊しかねない変更を適用しようとしている。ネットワークアーキテクチャの大幅な見直し、データベースマイグレーション、あるいはクリティカルなサービスに影響を与えるセキュリティグループの再設定かもしれない。チームで計画をレビューし、影響範囲を評価し、全員がその変更に本当のリスクが伴うことに同意している。

さて、次はどうする？

誰かが terraform apply を実行したり、デプロイボタンをクリックしたりする前に、リカバリープランが必要だ。棚に置いてあるだけの分厚いドキュメントではない。何か問題が発生した場合に備えた、実用的で具体的かつ実行可能な計画である。

まずは一つの質問から

リカバリープラン全体は、たった一つの質問から始まる。もしこの変更が失敗したら、すべてを安全な状態に戻すために何をする必要があるのか？

答えは、何を変更しているのか、そして影響範囲がどこまで及ぶのかによって異なる。単一のセキュリティグループに対する単純な設定変更であれば、答えは短いものになるだろう。古い設定を再適用するだけだ。しかし、ネットワークアーキテクチャの変更やデータベースマイグレーションには、はるかに詳細な対応が必要となる。

複雑にしすぎてはいけない。リカバリープランはリスクに見合ったものでなければならない。リスクの低い変更には、5行の計画で十分だ。コアサービスを停止させる可能性のある変更には、複数ステップからなるランブックが適切である。

すべてのリカバリープランに必要な3つの要素

有用なリカバリープランには3つの要素があり、それらはすべて明示的である必要がある。

具体的なリカバリ手順。 「以前のバージョンにロールバックする」は手順ではない。実行する正確なコマンド、そのコマンドを実行するサーバー、使用するパラメータ、そしてリカバリが実際に機能したことを確認する方法を書き留める。誰かが踏み台ホストにSSHで接続し、特定のTerraformコマンドを特定のステートファイルに対して実行する必要があるなら、そのように明記する。データベースをスナップショットから復元する必要があるなら、スナップショット名と復元手順を含める。

以下は、AWS上のセキュリティグループ変更に対するリカバリ手順の具体的な例である。

# Recovery Plan: Revert Security Group Change
# Target: sg-12345678 (production web tier)

# Step 1: Revert security group rules
aws ec2 revoke-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 10.0.0.0/16

# Step 2: Verify the rules are correct
aws ec2 describe-security-groups \
  --group-ids sg-12345678 \
  --query 'SecurityGroups[0].IpPermissions'

# Step 3: Confirm service is reachable
curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health

リカバリーを発動する判断者。 問題が発生すると、人々はパニックに陥る。各自が勝手に判断し始める。すぐにロールバックしたいと考える者もいれば、まずは問題を詳しく調べたいと考える者もいる。インシデント対応中は民主的なプロセスではない。「止めろ、今すぐリカバリーを開始する」と言える権限を持つ、単一の人物または役割が必要だ。計画書にその人物または役割を明示的に記載する。

プランを発動するタイミング。 すべての障害が即座にリカバリーを引き起こすわけではない。チームが調査している間、変更をそのまま実行させておいた方が良い場合もある。しかし、明確な境界線が必要だ。以下の2つのアプローチが有効である。

• 時間ベース: 変更適用後15分以内にシステムが安定しない場合、リカバリーを開始する。
• 影響ベース: エラー率が5%を超えた場合、またはユーザーがサービスにアクセスできないと報告した場合、リカバリーを開始する。

これらの閾値を書き留めておく。インシデント発生時に人々の記憶に頼ってはいけない。

適用前チェックリスト

高リスクな変更を適用する前に、必ず完了しておかなければならないことがある。これが適用前チェックリストであり、リカバリープランに含めるべきものである。

一般的な項目は以下の通り。

• 最新のスナップショットを取得済み
• インフラストラクチャのステートファイルをバックアップ済み
• リカバリーシステムへのアクセスを確認済み
• チームメンバーがリカバリー時の自分の役割を認識している
• インシデント調整用のコミュニケーションチャネルを確立済み

このチェックリストが存在する理由は、緊急時にリカバリーの準備をすることはできないからだ。変更前にスナップショットを取得していなければ、後からそのスナップショットから復元することはできない。ステートファイルをバックアップしていなければ、確信を持ってロールバックすることはできない。

以下のフローチャートは、変更レビューから適用前チェック、適用、監視、そして必要に応じたリカバリー実行までの全フローを示している。

適用前チェックリストは、強制力としても機能する。これによりチームは、変更を行う前に立ち止まり、リカバリーが実際に可能であることを確認する。すべての項目にチェックを入れられないのであれば、まだ変更を適用してはならない。

リカバリープランの承認者

高リスクなインフラ変更の場合、リカバリープランは、その影響を理解し、リスクを受け入れる権限を持つ誰かの承認を得る必要がある。これは、リードエンジニア、エンジニアリングマネージャー、または変更によって影響を受けるチームの代表者である可能性がある。

肩書きは重要ではない。重要なのは、承認者がリカバリープランが十分であるか、あるいはギャップがあるかを評価できることだ。「ロールバックも失敗したらどうなるのか？」や「リカバリー後にシステムが正常であることをどのように確認するのか？」といった質問ができなければならない。

これは形だけの承認プロセスではない。承認者が計画を評価するのに十分に理解していないのであれば、承認すべきではない。

誰でも見つけられる場所に計画を保存する

インシデント発生時に誰も見つけられなければ、リカバリープランは役に立たない。自分のラップトップに保存してはいけない。特別なアクセスが必要なフォルダに入れてはいけない。長いメールスレッドに埋もれさせてはいけない。

関係者全員がすぐにアクセスできる共有の場所に計画を置く。チームWiki、共有ドライブ、あるいはインフラ変更を含むプルリクエストに添付されたファイルとしてもよい。目標は、「何か問題が発生した」から「目の前に計画がある」までの摩擦をなくすことだ。

クイック実践チェックリスト

高リスクなインフラ変更を適用する前に、以下を確認する。

• リカバリ手順が正確なコマンドとパラメータで記述されている
• リカバリーを発動するかどうかを決定する特定の人物が指定されている
• リカバリーを発動するための時間または影響の閾値が定義されている
• 最新のスナップショットまたはバックアップが利用可能であることが確認されている
• インフラストラクチャのステートファイルがバックアップされている
• すべてのチームメンバーがリカバリー時の自分の役割を認識している
• 計画が関係者全員がアクセス可能な場所に保存されている
• 権限のある誰かが計画をレビューし、承認している

本当の試練は実行の瞬間に訪れる

準備され承認されたリカバリープランは、それが機能するリカバリープランと同じではない。自分の計画が確かなものであるかどうかを知る唯一の方法は、それをテストすることだ。つまり、安全な環境でリカバリ手順を実行し、コマンドが期待通りの結果を生成することを確認し、チームがプレッシャーの中でも計画を実行できることを確認する。

しかし、これはまた別の議論のトピックである。今のところ重要なのは、変更を適用する前に計画を準備しておくことだ。優れたリカバリープランがあれば、すべてが順調に進むことを保証できるわけではないが、何かが壊れたときに暗中模索で判断を下すことはなくなる。