1 復旧手順の概要
復旧手順とは、通信や情報システムの障害・停止が起きた際に、原因を切り分けつつ影響を小さくしながら、サービスを再開するための一連の行動計画と判断基準を指す。復旧の速さだけでなく、再発の抑制、運用の標準化、関係者間の認識統一を同時に達成することが重視される。
1.1 目的と基本方針
復旧手順の設計では、復旧目標と安全性、そして業務継続の観点を優先順位として定める。一次対応で過剰な変更を行うと二次被害が広がり得るため、段階的な判断と検証可能な作業が基本となる。
1.1.1 目標復旧時間と優先度設計
目標復旧時間（RTO）や許容停止時間（目標復旧の枠）を設定し、復旧対象の優先度を決める。優先度は、業務上の重要度、利用者影響の大きさ、代替手段の有無、復旧に必要な作業量などを総合して設計する。緊急度が高い領域ほど、実行順序や承認者の権限範囲を明確にしておく。
1.1.2 影響範囲の最小化
障害対応では、まず被害の拡大防止を優先する。具体的には、影響範囲を推定し、変更を局所化し、復旧作業が増幅しないようにする。復旧中は不確実性が高いため、影響範囲を継続的に更新しながら、必要な範囲に限定して操作する。
1.2 適用範囲
復旧手順は特定の機種やサービスに限定されず、障害が起き得る領域全般に適用できる。対象は、通信経路から基盤、さらには利用者が業務として感じる停止まで広がる。
1.2.1 通信ネットワーク障害
ルーティング、スイッチング、冗長経路、回線収容など、通信を成立させる機能が劣化または停止した状態を想定する。復旧では、疎通回復だけでなく、経路の安定化や性能劣化の解消までを含めて扱うことが多い。
1.2.2 サーバ・クラウド障害
物理サーバ、仮想化基盤、コンテナ、クラウドサービス（計算・ストレージ・管理プレーン等）に関わる停止や応答遅延を対象とする。復旧では再起動、スイッチオーバー、スケーリング、イメージ復元など複数の手段を使い分ける。
1.2.3 利用者影響がある業務停止
システム障害が原因となって、利用者の業務が止まる、遅延する、誤動作するなどの状態を対象とする。復旧手順では「サービスの定義」を明確化し、どの機能が復帰すれば「復旧した」と言えるかを基準化する。
1.3 関係者と役割
障害対応は複数の技能を要するため、役割を事前に定義しておくことが重要になる。現場で作業する層、判断する層、記録と広報に関わる層を分けると、判断の遅れや情報の欠落が減る。
1.3.1 障害対応チーム
一般に、一次対応を行う運用担当、専門領域（ネットワーク、サーバ、セキュリティ等）を含む技術担当、復旧の方針決定や承認を担うリーダー、記録・進行を担う担当が編成される。必要に応じてベンダ連絡も組み込む。
1.3.2 エスカレーションと承認フロー
初動後に追加の権限や意思決定が必要になるため、エスカレーション条件を定義する。例として、影響が拡大している場合、暫定復旧でリスクが残る場合、設計変更や強い変更（設定改変・ロールバック等）を行う場合に承認が必要となる。承認フローは、作業者の責任範囲と意思決定責任を整合させる。
2 平時の準備
平時の準備は、障害発生後の速度と品質を左右する。復旧手順は、紙やドキュメントとして存在するだけでは不十分で、実データ（構成、資産、変更履歴）と結び付く運用になっている必要がある。
2.1 資産管理と把握
復旧の成否は、対象システムの全体像が把握できるかに強く依存する。資産台帳は、機器や仮想リソースだけでなく、接続関係、依存関係、運用上の前提も含めて整備する。
2.1.1 設定情報・構成情報の管理
構成情報は復旧作業の中心になるため、所在と更新責任を明確にする。特に、障害時に参照できない構成情報は価値が低い。
2.1.1.1 バージョン管理と変更履歴
構成ファイルやインフラの定義はバージョン管理で追跡する。変更履歴には、変更理由、影響範囲、実施時刻、作業者、検証結果を残し、障害発生時に「いつ、何が、どの範囲に反映されたか」を追える状態にする。ロールバックの判断にも直結する。
2.2 バックアップと復元
バックアップは「あるかどうか」だけでなく、「復元できるか」「復元に要する時間は許容内か」が重要である。復元の成否は定期演習で確認し、手順の現実性を検証する。
2.2.1 バックアップ方式の選定
バックアップ方式は、フル・差分・増分、スナップショット、レプリケーション、アーカイブなどから要件に合わせて選ぶ。目標復旧時間、データの更新頻度、復元粒度（ファイル単位か、システム単位か）、保管期間、保管先の分離などを考慮する。さらに、バックアップ自体の欠損検知（整合性検査）も設計に含める。
2.2.2 復元手順の定期演習
復元手順は机上ではなく演習で確認する。対象データを本番と同条件に近づけつつ、段階的に復元を行い、所要時間、依存関係の扱い、ネットワーク要件、権限要件を記録する。演習結果に基づき、手順書の更新やツールの改善を行う。
2.3 障害対応の標準化
標準化は「誰がやっても同じ品質」に近づけるための仕組みである。チェック手順と判断基準を揃え、作業のばらつきを抑える。
2.3.1 チェックリストとプレイブック
チェックリストは確認漏れを防ぎ、プレイブックは障害タイプ別に判断・実行を整理する。プレイブックには、観測すべき指標、切り分けの順序、暫定対応と恒久対応の条件、ロールバックの要否、コミュニケーションのタイミングなどを含める。現場に即した言葉で記述し、参照しやすい形に保つ。
2.3.2 訓練・評価の仕組み
訓練は定期的に実施し、成果を評価する。評価では、初動の速さ、切り分けの精度、連絡の完全性、承認フローの順守、復旧後の検証実施を観点とする。評価結果は改善へ直結させ、形骸化を防ぐ。
3 障害検知から初動まで
初動は、被害の拡大を抑えつつ情報の質を上げる局面である。判断の早さと、誤った方向へ突っ込むリスクを同時に管理する必要がある。
3.1 通知と一次評価
通知が来た時点で、担当者が混乱しないように優先順位を付ける。一次評価は「何が起きているか」を暫定的に定め、次の切り分けに必要な観測点を絞る。
3.1.1 アラートの確認と優先順位
受信したアラートは重複・誤検知もあり得るため、発生時刻、影響対象、重大度タグ、関連する監視値を確認する。優先順位は、利用者影響、障害の連鎖の可能性、復旧に要する時間を基準に整理する。似た症状が複数同時に出ている場合は関連性を確認し、単独障害として扱わない。
3.1.2 利用者影響の見積り
利用者が感じる状態（遅延、エラー、利用不可）を見積もる。ログ、計測、問い合わせ状況、監視ダッシュボードを突合し、どの機能が止まっているのかを優先して把握する。可能なら、影響の範囲を地理や部門、契約プランなどの観点で切り分ける。
3.2 記録とコミュニケーション
初動時の情報整理は、後の検証や原因分析に直結する。記録と連絡は「作業の補助」ではなく、復旧プロセスの一部として扱う。
3.2.1 タイムライン作成
障害発生の時刻、最初の検知、重要な判断、実施した操作、観測された変化を時系列で残す。タイムラインが整備されると、後で「何が原因で、何が効果だったか」を切り分けやすくなる。
3.2.2 利害関係者への報告
運用担当だけでなく、影響を受ける部門や意思決定層へ、現在地と見通しを伝える。報告には、影響範囲、復旧方針の方向性、次の更新予定時刻、暫定措置の有無を含める。情報は短くてもよいが、頻度と一貫性を優先する。
3.3 安全確保と切り分け開始
安全確保は「すぐに直す」前に行う。無理な復旧操作は、原因が別にある場合に被害を増やすためである。
3.3.1 二次被害の回避
二次被害の典型は、誤ったスイッチ操作、過剰な再起動、設定の一斉変更、証明書や鍵の不適切な再発行などである。作業前に前提（現状、変更点、ロールバック可能性）を確認し、影響範囲を限定したうえで実行する。
3.3.2 現象の切り分け手順
切り分けでは、症状から要素へ順に落としていく。例として、ネットワークとアプリ層を分け、疎通と応答、認証とデータ取得の段階を切断して観測する。観測結果を次の仮説に結び付け、同じ確認を繰り返さないようにする。
4 復旧フェーズの実行
復旧フェーズでは、暫定的にサービスを戻すか、危険を抑えて恒久復旧を目指すかのバランスを取る。判断は、目標復旧時間と残存リスクを軸に行う。
4.1 復旧方針の決定
方針決定は、作業順序や承認判断を決める工程である。ここで誤ると、良かれと思った変更が逆効果になる。
4.1.1 試行順序（暫定対応・恒久対応）
一般に、暫定対応は復旧の足場を作るために用いる。たとえば冗長経路への切り替え、軽微な設定調整、キャッシュ再構築などが対象になり得る。恒久対応は根本対策の実施で、設計や構成の見直しを伴うことが多い。時間制約がある場合、暫定復旧の完了条件と、恒久復旧の進め方を同時に定める。
4.1.2 変更の是非（ロールバック判断）
変更を行う場合は、変更が有効である可能性と、失敗時の回復手段を評価する。ロールバック判断では、以前の状態へ戻せるか、戻すことで別の問題が起きないか、復旧時間に収まるかを見極める。承認済みの手段に限定し、場当たり的な操作を抑える。
4.2 構成復元と再起動
構成復元と再起動は、復旧の中核になりやすい。再起動は短期の効果がある一方で、依存関係を崩し得るため手順に注意する。
4.2.1 設備の再起動・スイッチオーバー
単体再起動か、冗長構成に基づくスイッチオーバーかを選択する。選択では、停止による影響、フェイルオーバーの挙動、復旧までの時間、監視から観測できる健全性指標を基準にする。切替の順序（待機系の準備、切替、回復確認）を明確にする。
4.2.2 設定の復元と整合性確認
設定復元はバックアップや構成管理の情報に基づいて実施する。復元後は整合性確認を行い、関連サービスが矛盾なく動作するかを確かめる。証明書や鍵、依存先の接続情報など、復元でズレやすい項目を重点的に点検する。
4.3 通信経路・名前解決の復旧
通信経路と名前解決は利用者体験へ直結する。ネットワークの疎通だけでなく、参照の正確さも同時に戻す必要がある。
4.3.1 ルーティングの確認
経路情報の整合、経路の優先順位、ポリシーによる制限、ループやブラックホールの有無を確認する。冗長構成では切替後にルーティングが落ち着くまで時間がかかる場合があるため、収束状況を観測する。
4.3.2 名前解決と証明書の確認
名前解決では、参照先の変更、キャッシュの整合、応答の正当性を検証する。加えて、TLSに関わる証明書の有効性やチェーンの構成を確認し、通信が暗号方式として成立していることを担保する。鍵更新や再発行を行う場合は、同一期間に複数要素が変わらないよう注意する。
4.4 設備交換と復旧（必要時）
根本的に復旧が難しい場合は、設備交換や部品切替が検討される。ここでは判断基準と記録の取り扱いが重要になる。
4.4.1 パーツ交換の判断基準
交換の判断では、自己診断結果、ログの再現性、障害切り分けの残留不確実性を考慮する。テストで原因が特定できないまま無差別に交換すると、作業が長引き、事後分析が困難になる。交換対象は仮説の優先度に沿って絞り込む。
4.4.2 代替機・代替経路の活用
代替機や代替経路は、時間制約下で復旧の成功率を上げる手段となる。代替先の性能、互換性、設定差、監視の有無を事前に把握しておくことで、切替後の検証負荷が下がる。
5 検証とサービス復帰
復旧後は「動いたように見える」状態と、「基準を満たしている」状態を分けて確認する。ここで手を抜くと、再停止につながりやすい。
5.1 機能確認
機能確認では、最小限の疎通から段階的に広げ、異常の再発や隠れた劣化を探す。
5.1.1 主要通信の疎通確認
主要な経路や代表的な通信フローについて、応答の可用性とエラー率を確認する。可能なら複数地点から観測し、片方向だけ回復している等の見落としを減らす。
5.1.2 性能・遅延の目視・測定
遅延やスループットの劣化は、短時間では見過ごされる。監視値に基づき、レイテンシ、帯域、タイムアウト発生率などを測定し、通常時の分布と比較する。目視だけで終えず、記録可能な指標を残す。
5.2 総合テストと利用者確認
総合テストは複数の機能が連動して成立することを確認する工程である。利用者確認は、実運用に近い手触りで不具合を見つける役割を持つ。
5.2.1 サービス品質の基準
品質基準は、可用性、応答時間、成功率、再試行回数、観測エラーなどの指標で定義する。復旧完了の判定は、基準を満たしたかどうかで行うと、主観に依存しにくい。
5.2.2 パイロット運用の実施
全体公開の前に、対象を限定して運用を開始する。パイロットでは、問い合わせの増え方、典型操作の成功状況、監視の変化を観測し、本番展開の可否を判断する。問題が出た場合は、縮退や再切替が可能な設計になっていることが望ましい。
5.3 復旧完了の宣言
復旧完了は、作業が終わった合図ではなく、責任ある判断の宣言である。宣言後の誤解を避けるため、条件と承認を明確にする。
5.3.1 完了条件と責任者の承認
完了条件には、検証項目の達成、監視の安定、利用者影響の収束、記録の更新などを含める。責任者の承認により、後で検証範囲が争点になりにくくなる。
5.3.2 障害ステータスの更新
障害管理ツールや連絡チャネルのステータスを更新し、以後の問い合わせ導線を明確にする。残存懸念がある場合は、軽微な問題として扱わず、次の観測や追跡計画を添える。
6 再発防止と改善
再発防止は、復旧の価値を長期的に引き上げる工程である。原因が分かった時点で終わりではなく、仕組みとして改善を定着させる。
6.1 原因分析（ポストモーテム）
ポストモーテムは、感情的な追及ではなく学習のための整理として行う。データに基づき、因果のつながりを構造化する。
6.1.1 現象・根本原因の整理
現象、検知、判断、作業、復旧後の状態を時系列で再構成し、根本原因を特定する。原因は単一とは限らず、手順不足、監視設計、変更管理、教育、設計の欠落など複合要因として整理される。
6.1.2 再現性の確認
可能な範囲で再現性を確認する。再現により対策の検証がしやすくなる一方で、危険な再現を行う必要はない。代替としてログ解析や環境比較で裏付けを取る方法もある。
6.2 恒久対策
恒久対策は、同種障害の発生可能性を下げることを目的とする。暫定対応の再利用に留まらず、仕組みの変更として実装する。
6.2.1 設計見直し
設計見直しでは、冗長性、依存関係の整理、フェイルオーバー設計、監視ポイントの拡張などを検討する。変更は複雑さを増やし得るため、効果とコストを評価して優先度を決める。
6.2.2 運用ルールの更新
運用ルールの更新では、手順書の改訂、承認条件の調整、定期点検の頻度、変更管理の厳格化などが対象となる。特に、障害時に迷いやすかった箇所は具体的な判断基準として追記する。
6.3 教訓の共有と教育
教訓の共有は個人の記憶に依存しない仕組みである。ナレッジを資産化し、次の訓練へつなぐ。
6.3.1 ナレッジベースの更新
ナレッジベースには、障害概要、検知から復旧までの流れ、切り分けの要点、対策の結果、注意事項を整理して登録する。検索しやすい粒度で、関連プレイブックへのリンクも付与する。
6.3.2 次回訓練への反映
訓練に反映する際は、実際に起きた兆候や判断の誤りを教材化する。特定の操作手順だけでなく、どの指標を見てどう判断するかを重点に置くと再発率を下げやすい。
7 よくあるケース別の復旧方針
ケース別方針は、現場の判断を短縮するための参照枠である。実際の状況により優先順位は調整されるが、基本の考え方は共通する。
7.1 ネットワーク断（疎通不可）
疎通不可は、物理・論理のどちらにも原因があり得る。復旧は、段階的に到達性を測り、代替経路を活かして時間を稼ぐ。
7.1.1 配線・機器状態の確認
リンク状態、インターフェースのエラー、電源・冷却、設定の不整合、ケーブル種別と収容先の確認を行う。誤配線や収容変更は人為要因で起こりやすいため、直近の変更履歴も参照する。
7.1.2 代替経路の切り替え
代替経路がある場合は、収束までの時間と影響範囲を見ながら切り替える。切替後は経路が安定したこと、必要な通信が戻ったことを確認し、以後の恒久復旧へ繋げる。
7.2 設定ミス・変更後障害
変更後に障害が出た場合は、差分の追跡が最短ルートになる。復旧の初期は、原因の特定と被害の限定が中心となる。
7.2.1 変更履歴の追跡
変更履歴から、対象コンポーネント、実施時刻、適用順序、検証の有無を照合する。複数変更がある場合は、障害発生前後の順序関係を優先して絞り込む。
7.2.2 ロールバック手順
ロールバックは、安全性と時間制約を満たす範囲で実施する。戻す前に依存先の整合やデータ破壊の可能性を確認し、戻した後に検証項目を再度満たすことを基準にする。
7.3 リソース枯渇（過負荷・タイムアウト）
リソース枯渇は、急激な需要増や構成不整合、障害の連鎖によって起こる。復旧はまず安定化を図り、次に原因を潰す。
7.3.1 ボトルネック特定
CPU、メモリ、ディスクI/O、ネットワーク帯域、キュー長、スレッド枯渇などの指標を見て、どこで詰まっているかを特定する。タイムアウトの発生箇所と、遅延の増加が始まった時刻の対応を確認する。
7.3.2 スケール・制限変更
スケールアウト、バッチ分割、上限値の調整、ワークロードの優先制御などで負荷を均す。恒久対策としては、容量計画や自動スケーリングの閾値調整を検討し、急変に耐える設計へ寄せる。
7.4 認証・暗号関連の不具合
認証や暗号は、通信は通っていても利用不能に直結しやすい。証明書・鍵・信頼チェーンの整合を最優先で確認する。
7.4.1 証明書・鍵の状態確認
有効期限、更新履歴、秘密鍵の所在、チェーン構成、署名アルゴリズムの互換性を確認する。複数システムで同時に更新されている場合は、更新順序による一時不整合も疑う。
7.4.2 検証と再発行手順
検証では、クライアント側とサーバ側の両方の観測を揃える。再発行は影響が大きいため、段階的なローテーションや代替証明書の利用が可能かを検討し、ロールバック計画とセットで扱う。
8 運用上の留意点
運用は「復旧を成立させる環境」を維持する活動である。変更、セキュリティ、文化の三点を整えると、障害が起きても耐えやすくなる。
8.1 変更管理と影響評価
変更管理は、障害を未然に抑えると同時に、障害が起きた際の追跡可能性を高める。
8.1.1 緊急変更の扱い
緊急変更は速度を優先するが、逸脱が恒常化すると品質が下がる。緊急変更でも、影響範囲の最小化、承認の記録、復旧手段の用意、完了後の本記録化を行う。実施後は通常フローへ戻し、ギャップを埋める。
8.1.2 後追い記録の要否
後追い記録は、見落としやすい変更点を後で補うための仕組みである。どの粒度まで残すかを決め、記録されていない変更が「原因分析の盲点」にならないようにする。
8.2 セキュリティとコンプライアンス
復旧作業は攻撃や監査上のリスクと隣り合わせである。セキュアな運用は、復旧を妨げるのではなく、損害を防ぐ。
8.2.1 監査ログの保全
ログは復旧判断と事後分析の材料になる。改ざん防止、保管期間、アクセス権、収集漏れの検知を整備し、障害対応中も監査ログが途切れないようにする。
8.2.2 権限と手順の統制
権限は最小化し、手順は実行可能な形で制御する。特に、設定改変、証明書の再発行、データ復元のような影響が大きい操作は、承認と監査の枠組みと結び付ける。
8.3 障害対応のコミュニティ的側面
障害対応は技術だけでなく、チームの相互理解で品質が変わる。情報共有のしやすさは、判断の正確さを支える。
8.3.1 報告文化（安心して共有できる場）
報告文化は、ミスや発見を隠さずに共有できる状態を指す。責めるより学ぶ姿勢を明確にし、短い報告でも称賛することで、兆候段階での対処が増える。
8.3.2 軽い息抜きの入れ方（現場の空気づくり）
緊張が続くと判断が鈍るため、適度な息抜きが現場の持続力を支える。たとえば作業の合間に短い雑談を許容したり、作業後に“うまくいった点”を一言共有したりするなど、軽さを適切に保つ。息抜きは気を散らす行為ではなく、コミュニケーションの潤滑油として扱う。