復旧計画が実践なしに失敗する理由

共有フォルダに置かれ、管理陣の承認を得て、その後二度と触られない復旧計画は、復旧計画ではありません。それは単なる安心毛布です。実際に誰かがその計画を読むのは、インシデント発生時、パニックが高まり判断力が低下し、ステップを飛ばすことが最速の解決策に思える瞬間です。

私は、チームが本番停止中に初めてロールバック手順を実行するのを見たことがあります。DNS伝搬の確認ステップを飛ばしていました。データベースマイグレーションが不可逆的であることに気づかず、元に戻せると思い込んでいました。6ヶ月前に退職した連絡先に電話をかけていました。これらの問題はドキュメントには一切現れません。プレッシャーがかかった瞬間に初めて表面化するのです。

復旧計画の価値は、最後に誰かが実際にそれを実行した時点での品質に依存します。

未テスト計画の問題点

計画が紙の上だけに存在する場合、いくつかの問題が静かに進行します。書いている時には明確に見えた指示が、ストレス下では曖昧になります。特定のツールが動作することを前提としたステップが、権限変更により壊れます。図では論理的に見えたアクションの順序が、実際のシステム動作と一致しません。

さらに悪いことに、未テストの計画は誤った自信を生みます。チームはドキュメントがあるから準備ができていると信じます。そのドキュメントが現実に対して検証されたことがないことに気づいていません。実際の障害が発生した時、最悪のタイミングでギャップを発見することになります。

解決策はより良いドキュメント作成ではありません。解決策は実践です。

未テストの計画と実践された計画の違いは、以下の比較で明らかです：

flowchart TD A[復旧計画] --> B{テスト済み?} B -->|いいえ| C[未テスト計画] C --> D[曖昧な手順] D --> E[誤った自信] E --> F[実際のインシデント] F --> G[プレッシャー下での失敗] B -->|はい| H[実践済み計画] H --> I[ゲームデイ / シミュレーション] I --> J[検証済み手順] J --> K[チームが計画を信頼] K --> L[実際のインシデント] L --> M[復旧成功]

ゲームデイ：構造化された失敗の練習

DevOpsチームで復旧計画をテストする最も一般的な形式はゲームデイです。ゲームデイとは、チームが意図的に障害シナリオを安全な環境（通常はステージングまたは本番相当環境）で作り出す、予定されたセッションです。

復旧を担当するチームは、事前に正確なシナリオを知りません。一定期間内に障害がトリガーされ、それに対処する必要があることだけを知っています。目的は誰かを騙すことではありません。目的は緊急対応のための筋肉記憶を構築することです。

典型的なゲームデイは次のように進行します：

  • チームの誰かが障害をシミュレートします。例えば、ネットワーク設定変更によりサーバーの半分が到達不能になる状況など。
  • オンコールチームが障害を検出し、ロールバックするかフェイルオーバーするかを判断し、文書化された計画から復旧手順を実行します。
  • セッション終了後、チームは振り返りを行い、何がうまくいったか、何を見逃したか、計画に何を変更すべきかを議論します。

最初のゲームデイは常に問題を明らかにします。時間がかかりすぎるステップ。権限不足で失敗するコマンド。計画でカバーされていない判断ポイント。それぞれの問題が計画の改善点になります。

カオスエンジニアリング：自動化された継続的テスト

ゲームデイは予定されたイベントです。カオスエンジニアリングは同じアイデアを継続的に行うものです。Chaos MonkeyやGremlinのようなツールは、特定の障害を自動的にシミュレートできます：サーバーダウン、データベース接続切断、TLS証明書の期限切れなど。

重要な違いは頻度です。ゲームデイは月1回または四半期に1回行われます。カオス実験は毎日実行できます。復旧計画テストにおいて、カオスエンジニアリングはターゲットを絞った形で有用です。ランダムな障害ではなく、復旧計画に記載された障害シナリオと完全に一致する実験を作成します。そして、システムを実行させ、障害が自動的に発生した時に計画が実際に機能するかどうかを確認します。

このアプローチはリグレッションを捕捉します。先月は機能した復旧ステップが、ファイアウォールルールの変更や認証情報のローテーションによって壊れる可能性があります。カオス実験はその破綻を即座に表面化させ、次の停止時まで待つ必要がありません。

プロセスシミュレーション：コードだけでなくコミュニケーションのテスト

復旧計画のすべての部分が技術的なものではありません。誰が誰に電話するか、どの情報が共有されるか、どのように決定が下されるかに関する部分もあります。これらの部分は、ゲームデイやカオス実験だけではテストが難しいです。

プロセスシミュレーションがこれを解決します。シミュレーションでは、実際にサーバーが停止されることはありません。チームは架空のインシデントレポートを受け取り、復旧計画を最初から最後まで紙上または模擬監視システム上でウォークスルーします。指示が明確か、システムへのアクセスが利用可能か、コミュニケーションチェーンが機能しているかを確認します。

シミュレーションは、技術的な訓練では見逃されがちな問題を明らかにすることがよくあります。もう使われていない連絡先番号。別のチームのメンバーが午前3時に利用可能であることを前提としたステップ。休暇中のマネージャーを必要とする承認ゲート。これらは自動化では修正できない種類の障害ですが、単純なウォークスルーで捕捉できます。

結果をどう活かすか

すべての練習セッション（ゲームデイ、カオス実験、プロセスシミュレーションのいずれであっても）は、改善点のリストを生成する必要があります。復旧計画は静的なドキュメントではありません。チームが学んだことに基づいて変化する生きた成果物です。

各セッション後、計画を更新してください。不要であることが判明したステップを削除します。不足していたステップを追加します。ツールの問題を修正します。連絡先リストを更新します。曖昧な指示を明確にします。計画は毎回の練習セッション後に異なって見えるべきです。

計画が決して変わらない場合、チームは練習から学んでいないことになります。

始めるためのクイックチェックリスト

チームが復旧計画を一度もテストしたことがない場合、小さく始めてください。最初のセッションのための実用的なチェックリストです：

  • 既存の復旧計画から1つの障害シナリオを選びます。最も単純なものから始めてください。
  • ステージング環境で1時間のゲームデイをスケジュールします。本番影響はありません。
  • 障害をトリガーし観察する担当者を1人割り当てます。その人は復旧には関与しません。
  • オンコールチームに計画をそのまま実行させます。セッション中の即興は禁止です。
  • セッション後、計画からの逸脱と不明瞭なステップをすべて書き留めます。
  • 見つかった内容に基づいて計画を更新します。その後、次のセッションをスケジュールします。

最初のセッションで完璧を目指さないでください。発見を目指してください。見つけたギャップはすべて、実際のインシデント中に驚かされることのないギャップです。

唯一重要な指標

一度もテストされたことのない復旧計画は、願望であり、計画ではありません。チームが実際に障害から復旧できるかどうかを知る唯一の方法は、実際の緊急事態が発生する前に、管理された条件下で彼らがそれを行うのを見ることです。

1つのシナリオから始めてください。1回のセッションを実行してください。壊れたものを修正してください。そしてもう一度行ってください。時間が経つにつれて、練習は日常的になり、復旧計画はチームが無視するものではなく、信頼するものになります。