障害復旧手順の設計 — 手順書とスクリプトのどちらで持つか

障害復旧の手順を整備しているにもかかわらず、深夜障害で担当者が手順書を脇に置いて属人的な判断で動いてしまう——この構造的な問題は、「手順書をどう書くか」ではなく「何を手順書として持ち、何をスクリプトとして自動化するか」の設計判断から生まれている。この記事では、その境界の引き方と、訓練・自動化との組み合わせ方、そして復旧を属人化させないための仕組み作りを整理する。

いざという時に動かない復旧手順が生まれる構造

手順書が「構築当時」で止まる問題

インフラ構築プロジェクトの終盤に作成された障害復旧手順書は、多くの場合、構築時点の構成を前提に書かれている。その後、OSの更新や設定変更、ミドルウェアのバージョンアップが積み重なると、手順書の記述と実際の環境が少しずつズレていく。5台以上のサーバーを管理する環境では、構成変更のたびに複数の手順書が連鎖的に影響を受けるが、その追跡が手動のままでは「書いてあるとおりに実行したが動かなかった」という状況が発生しやすい。定期メンテナンスで一部の設定が改訂されても、障害復旧手順そのものが見直されないケースは現場で繰り返されている。手順書を「作って終わり」ではなく「環境変更のたびに連動して更新するもの」として設計する必要がある。

実行者の認知負荷が設計から抜け落ちる

手順書を作成する時点では、作成者はシステムの詳細を十分に把握している。そのため「前提知識のある自分が読んでわかる記述」になりがちで、行間の多い手順書が生まれる。深夜に呼び出された担当者が、平時にはほとんど触れていないサブシステムの障害対応を行う場面では、その行間を読むための認知コストが大きく膨らむ。「理解してから実行する」ではなく「手順どおりに実行すれば復旧できる」水準まで具体度を引き上げることが、設計の出発点になる。曖昧な記述が一箇所あるだけで、そこで担当者が立ち止まり、ダウンタイムが不必要に伸びる。

訓練なしに機能する手順書は存在しない

手順書を「あれば安心」として棚に置いておく文化の現場では、実際の障害が発生して初めて手順の穴が露わになる。ある現場では、15ステップからなる復旧手順の中に「7. 現在の状態を確認すること」という曖昧な記述があり、そこで担当者が立ち止まり30分以上のロスタイムが発生した事例がある。手順書の妥当性は「書いた人が読んで正しい」ではなく、「初見の実行者が手順どおりに動いて復旧を完遂できる」水準で測るべきだ。この視点が欠けている手順書は、存在していても本番障害では機能しない。

手順書で持つべきもの・自動化すべきものの境界

人間の判断が必要な局面を先に洗い出す

復旧処理の中で「人間が状況を見て判断しなければならない」箇所と「条件が揃えば機械的に実行できる」箇所は、設計の段階で明確に区別しておく必要がある。フェイルオーバーの実行判断は「切り替えて良い条件が揃っているか」の確認を人間が行わなければならないが、切り替え操作そのものや、サービス再起動の実行、ログの収集・圧縮・転送といった定型処理は、正確なパラメータさえ確定すれば自動化に適している。この分類を行わずに「手順書かスクリプトか」を選ぼうとすると、判断ロジックとオペレーションが混在した状態になり、どちらも中途半端になる。

自動化向き・手順書向きの判断基準

以下の表は、障害復旧における各処理の特性と、どちらで持つべきかの設計判断の目安を整理したものだ。「○」は主な担い手、「△」は補完的な役割を示す。

処理・判断の種類	手順書で持つ	スクリプトで持つ	設計上の理由
フェイルオーバーの実行判断	○	×	切替条件の確認に人間判断が必要
フェイルオーバー操作の実行	△	○	判断後の操作は自動化可
ログ収集・圧縮・転送	×	○	繰り返し・定型・時間依存の処理
サービスプロセス再起動	△	○	条件が明確なら自動化向き
DBフェイルオーバーの判断	○	×	データ整合性の確認が不可欠
バックアップからの復元操作	△	○	対象・手順の定義は手順書で行う
インシデント宣言・エスカレーション	○	×	組織的判断が必要
復旧後の動作確認	○	△	確認基準と合否判定は人間が設計する

自動化できる箇所でも手順書が必要な理由

自動化スクリプトが存在していても、「そのスクリプトをどのタイミングでどのような判断に基づいて実行するか」を手順書に書いておく必要がある。スクリプトはオペレーションのツールであり、手順書はそのツールを使う判断の枠組みだ。自動化とドキュメントは代替関係ではなく、設計上の役割が異なる。「スクリプトを整備したから手順書は不要」という判断が、スクリプトの意図や実行条件ごと失われる原因になる。スクリプトの実行条件・実行者・中断基準は、必ず手順書として残す。

「考えながら直す」と「決め打ちで戻す」の設計判断

障害の性質で復旧戦略を分ける

障害復旧には大きく二つのアプローチがある。一つは「原因を特定し、その場で修正する」ルート。もう一つは「原因追究を後回しにして、既知の正常状態に戻す」ルートだ。前者はシステムを深く理解している担当者が必要であり、時間はかかるが根本解決につながる。後者はスナップショットからの復元やBlue/Greenデプロイのロールバックといった「決め打ちの戻し操作」で、短時間での復旧を優先する。どちらを主戦略にするかは、RTOの要件と担当者のスキルセット、システムの複雑度によって決まり、システムごとに事前に選択しておく必要がある。

RTO要件から逆算した設計の選択

RTO（Recovery Time Objective）が30分以内のシステムでは、原因を追究しながら修正する戦略は現実的でないことが多い。その水準を確約するには「どこに戻すか」「何を使って戻すか」をあらかじめ決めておく必要がある。スナップショット取得の頻度や保持世代数、フェイルオーバー先の準備状況はRTO要件から逆算して設計する。「とりあえずスナップショットをとっている」という状態は、復旧戦略の設計がまだ完成していないサインだ。保持世代数が3世代しかない場合、実現可能なRPOがどの時点になるかを明文化しておくことが、復旧設計の第一歩になる。

「ロールバック」か「修正継続」かを事前に決める

障害発生中に「このまま修正を続けるか、ロールバックするか」を判断するのは、心理的にも技術的にも難しい。「もう少しで直せそう」という感覚がロールバックの判断を遅らせ、結果的にダウンタイムが延びるケースは現場でよく聞かれる話だ。そのため、「障害発生から20分が経過しても復旧の見通しが立たない場合はロールバックを選択する」といった判断基準を事前に手順書に明記しておくことが有効だ。判断基準を定めることで、担当者は現場の感情ではなく設計に基づいて動ける。基準のない手順書は、最も重要な局面で沈黙する。

復旧を属人化させない仕組みの作り方

「この人がいれば直せる」は設計の失敗

特定の担当者がいなければ復旧できない状況は、設計の観点では単一障害点と同義だ。10人規模のインフラチームであっても、夜間・休日対応が特定の1〜2名に集中する現場は多い。これを解消するには、手順書の粒度を「実行者が初見でも動ける水準」まで引き上げ、条件分岐や確認ポイントを明示する必要がある。手順書の詳細度を上げることは、ドキュメントの量を増やすことではなく、実行者が現場で持つ「迷いの余地」を減らすことを意味する。属人化の解消は人材育成だけでは達成できず、手順書の設計品質によって決まる。

ロールと実行権限を手順書に紐付ける

誰がどの手順を実行する権限と責任を持つかを、手順書の中に明記しておく。復旧作業の中で「この操作は誰がやるべきか」が不明確なまま進むと、二重実行や実行漏れが起きやすい。「DBの切り替えはDBA担当者の確認後に実施」「WAFルール変更はセキュリティ担当者の承認が必要」といった条件を手順に組み込むことで、チーム全員が手順書を使って動ける状態を作れる。ロール定義と手順書が分離されている場合、緊急時に「誰がやるか」の調整で貴重な時間を失う。

手順書の保管場所と更新フローを設計する

手順書がどこにあるかを知らなければ、障害発生時に探すところから始まってしまう。Git管理のWikiや内部ドキュメントシステムへの固定保管と、環境変更に合わせた更新フローの設計は、手順書の「使える状態を維持する」ための仕組みだ。更新のトリガーをインフラ変更のレビュープロセスに組み込み、手順書のレビューをセットで行う設計にすることで、ドキュメントの陳腐化を防ぎやすくなる。保管場所と更新フローが設計されていない手順書は、いずれ「存在は知っているが誰も参照しない」状態に向かう。手を動かす手順の解説はここでは深追いしないが、仕組みとして自動化する設計の考え方が核心になる。

訓練で手順を検証する設計（机上で終わらせない）

障害訓練を「手順の検証」として位置づける

障害訓練の目的は、担当者のスキル向上だけではない。手順書が「実際に使えるかどうか」を検証する場として機能させることが設計上の主目的だ。年に1〜2回の訓練機会を、担当者が既存の手順書だけを使って復旧操作を完遂できるかのテストとして設計すると、手順の穴が浮き彫りになりやすい。ステージング環境で本番同等の障害シナリオを再現し、完遂までの時間を計測することで「RTOを満たせるか」の実測値が得られる。この実測値がRTO要件を超えていれば、手順か環境かどちらに問題があるかを判断できる。

訓練結果を手順書に反映するフィードバックループ

訓練で発見した問題点が手順書に反映されなければ、次の訓練でも同じ問題に当たる。訓練後にKPT形式で気づきを整理し、Problemを手順書の改訂アクションとして登録するフローを定型化しておく。障害対応中に「ここが不明確だった」「この判断基準がなかった」という気づきも同様に収集し、後日手順書を改訂する習慣を作ることで、手順書は運用を重ねるごとに精度を上げていく。訓練の記録を「反省会」の場に留めず、アクションとして手順書に落とし込むことが重要だ。

本番環境でしか検証できない手順をどう扱うか

ステージングで再現できない本番特有の条件——トラフィックの規模や本番のみの依存関係——を含む手順は、完全な事前検証が難しい。この場合、「本番に近い条件での計画的メンテナンス」や「カナリアリリース時の部分的ロールバック実施」を手順検証の機会として活用する設計が現実的だ。リスクのある手順ほど、実行条件・実行結果の確認方法・中断判断基準をあらかじめ定義しておく必要がある。ステージングで検証できない部分を「未検証」として手順書に明示しておくことも、設計の誠実さの一部だ。

自動化しすぎて誤動作する境界の見極め

自動復旧が「正常」を判断できない状況

監視ツールによる自動復旧（Auto Healing）は、単純なプロセス再起動やヘルスチェック失敗時のインスタンス入れ替えには有効だ。しかし「障害の原因が自動復旧によって隠蔽される」という問題が起きやすい。メモリリークが原因でプロセスが落ちるたびに自動再起動を繰り返す構成では、根本原因が24時間以上気づかれないまま推移するケースがある。自動化は「正常状態への復帰」には強いが、「なぜ正常でなくなったか」を判断することは設計上できない。この限界を理解した上で自動化の範囲を定める必要がある。

「自動化の射程」を意図的に狭める設計

自動復旧の対象とする障害パターンを明確に定義し、それ以外は人間への通知と介入に委ねる設計が安全側に倒れている。「ヘルスチェック2回連続失敗でプロセス再起動を実行、ただし3回実行後は通知のみにとどめ自動実行を停止する」というロジックは、無限ループによるリソース消費を防ぎながら、異常の継続を人間に伝える。自動化の射程を広げるほど、想定外の状況で誤動作するリスクは比例して高くなる。設計の出発点として「自動化の範囲を最小化する」ところから始めることが、安定した運用につながる。

自動化とアラートの設計を分けて考える

自動復旧スクリプトが実行された事実は、必ずアラートとして通知する設計にしておく必要がある。「自動で直ったからアラートも不要」という設計は、次第に障害の発生頻度が見えなくなる。自動復旧の実行回数・頻度はモニタリング指標として収集し、週次で一定回数を超えた場合は人間のレビューを要求するトリガーとして機能させる。自動化は担当者の対応コストを下げるためにあり、担当者の可視性を下げるためにあるのではない。この原則を守らないと、自動化は「問題の隠蔽装置」になる。

復旧手順設計チェックリスト

以下の項目は、障害復旧手順を設計・見直す際の確認ポイントを整理したものだ。「設計済み」か「未設計」かで棚卸しすることで、手順の空白地帯が見えやすくなる。

• 手順書の対象システム・対象障害シナリオが明文化されているか
• 手順書の前提条件（実行者のロール・アクセス権・依存するツール）が記載されているか
• 「考えながら直す」と「決め打ちで戻す」のどちらを主戦略にするかが障害種別ごとに定められているか
• ロールバックの判断基準（経過時間・症状・条件）が明記されているか
• 自動化する処理と人間が判断する処理の境界が設計されているか
• 自動復旧の実行範囲と停止条件が定義されているか
• 自動復旧が実行された際に必ずアラートが通知される設計になっているか
• 手順書の保管場所と、実行者全員がアクセスできる状態が確保されているか
• 環境変更時に手順書を更新するトリガーと担当者が設計されているか
• ステージング環境での訓練計画と、訓練結果を手順書に反映するフローが存在するか
• 本番環境でしか検証できない手順が「未検証」として明示されているか
• RTO要件と訓練での実測値が一致しているか（乖離がある場合はその対策が設計されているか）
• 手順書の最終更新日と、最後に訓練で検証した日が記録されているか