1 復旧確認の位置づけ
復旧確認は、障害対応や中断から復帰した後に、その状態が「単なる復帰」ではなく、事前に定めた機能要件と品質基準を満たすことを確かめる工程である。運用現場では、復旧作業の完了宣言と利用者影響の収束確認が混同されやすいが、復旧確認は両者を区別し、検証にもとづく判断を行う点に特徴がある。
1.1 障害対応プロセスにおける役割
障害対応は概ね「検知・診断・応急処置・復旧・再発防止」と段階化される。復旧確認は復旧の後半に位置し、機能の回復だけでなく、監視の正常性、データの整合、業務の継続性などを確認してから完了扱いとするため、品質保証のゲートとして機能する。特に、応急処置で一時的に見かけ上の稼働が得られても、内部状態の不整合や周辺サービスの遅延が残るケースでは、復旧確認が影響の拡大を抑える。
1.2 復旧の定義と確認基準
「復旧した状態」の定義は、サービスごとに異なるが共通して「期待される機能が実際に動作している」ことを基準に置く。確認基準は、疎通の成立、応答時間やエラー率の水準、整合性の保持、監視アラートの収束、業務フローの再開など、複数の観点の組み合わせで定める。基準の重要度は優先度（クリティカルな機能から確認）で整理し、どこまで満たせば暫定提供として扱うか、全面復旧の条件は何かを明文化する。
1.3 期待される成果物（証跡・報告）
復旧確認では、判断を後から追跡できる成果物を残すことが求められる。代表的には、確認項目の実施結果（合否、数値、観測条件）、参照したログや監視ダッシュボードの記録、テスト手順と結果、切戻しの要否、残課題の有無などである。報告は、技術的な事実と運用判断（完了／継続／暫定）を対応づけ、関係者が同じ前提で理解できる粒度に整える。
2 復旧確認の対象領域
復旧確認の対象は、通信経路からアプリケーション、さらに業務の実行体制まで広がる。障害の形態は多様であり、単一箇所の復元では全体が成立しないことがあるため、領域ごとの確認を積み上げて全体整合を担保する。
2.1 通信・ネットワーク機能
通信層とネットワーク層では、到達性と名前解決、経路選択、収容状態などの観点で「つながる／届く」を検証する。復旧時にありがちな誤りは、限定的な疎通だけで合否を決めることであり、経路や機器の切替が想定通りかも同時に確認する。
2.1.1 疎通確認
疎通確認は、エンドポイント間で通信が可能になったことを、対象範囲を明確にして確かめる作業である。確認対象は機器だけでなく、利用形態に近いプロトコルや経路（本番相当）を含めると、見落としが減る。
2.1.1.1 端末・経路・名前解決の確認
端末の到達性（送受信の成立）、経路の整合（意図しない迂回がないこと）、名前解決の機能（DNSや類似の仕組みが有効であること）を確認する。経路が復帰しても名前解決が不安定だと実利用が成立しないため、両者は分けて扱い、観測結果を紐づける。
2.1.2 収容・経路切替の確認
収容・経路切替は、冗長構成や冗長経路を前提にした動作を検証する工程である。フェイルオーバー後に期待した優先度や収容割当が維持されているか、特定セグメントだけが不利な経路に固定されていないかを確認する。切替が正しく行われない場合、後続の性能劣化や断続的な失敗につながるため、ルーティングの状態や収容テーブルの変化を確認項目に含める。
2.2 システム・サービス機能
システム・サービス側では、性能と可用性、内部状態とデータ整合、依存関係の健全性を確認する。特に、復旧直後はキャッシュ再構築やキュー再処理などの「遅れて効いてくる変化」が起こりやすく、短時間の観測だけで合否を出すと後から問題が表面化する。
2.2.1 応答性能と可用性の確認
応答性能と可用性の確認は、利用者体験に直結する指標を用いて行う。監視の稼働表示だけでは十分でないため、一定時間にわたる観測と、要求種別ごとの応答差を意識する。
2.2.1.1 レイテンシ・エラー率の観点
レイテンシは応答までの遅れ、エラー率は失敗の発生頻度として扱う。復旧確認では「平均」だけでなく分布や上位パーセンタイルを参照し、遅延の尾が残っていないかを見る。エラーについては、クライアント起因のものとサーバ起因のものを分離できる範囲で整理し、再発の兆候を見つける。
2.2.2 データ整合性と状態復元の確認
データ整合性と状態復元の確認は、復旧手順で扱ったデータが期待通りに戻ったことを検証する。整合性は、参照整合、更新整合、重複や欠落の有無といった観点に分けられる。状態復元では、セッションやジョブの進捗などの内部状態が矛盾なく再開しているかを確認し、必要ならリプレイや再同期の範囲を見直す。
2.3 運用・業務プロセス
運用・業務プロセスの確認は、基盤の復元と利用可能性の橋渡しを行う工程である。バッチや外部連携のように、遅延して表に出る失敗を見落とさないよう、時間軸を踏まえた検証が重要になる。
2.3.1 バッチ・ジョブの再開確認
バッチ・ジョブの再開確認では、停止中の処理が再開されたこと、実行結果が想定範囲に収まっていることを確認する。単にジョブが起動しただけでは不十分であり、完了状態、再実行による重複の有無、入力待ちの滞留が残っていないかなどを追跡する。依存関係のあるジョブは順序を踏まえて、再開タイミングのズレが影響を残していないかを見る。
2.3.2 利用者影響の解消確認
利用者影響の解消確認は、技術指標と実際の体験が一致していることを検証する。典型的には、代表的な業務操作の成功、例外の発生率の低下、待ち時間の回復、問い合わせ増の収束などを指標化して扱う。復旧直後に問い合わせが減らない場合は、内部では回復していても利用導線側で遅延やキャッシュ反映遅れが残っていることがあるため、導線の検証を含める。
3 復旧確認の手順
復旧確認は「計画して、実施し、段階的に確定する」流れとして設計する。特定のテクニックよりも、確認項目の優先度、観測条件、合否の判断基準を先に定めることが再現性を高める。
3.1 計画と準備
計画と準備では、確認の対象範囲、観測手段、必要な権限を整える。ここが曖昧だと、復旧後に証跡が欠落したり、確認が属人的になる。
3.1.1 確認項目の洗い出し
確認項目の洗い出しでは、障害の影響範囲と依存関係を起点に行う。通信経路が中心か、アプリ層が中心か、データ層が中心かで項目は変わる。復旧確認は全網羅を目指すよりも、復旧完了条件に直結する要素を重点化し、必要に応じて段階追加する。
3.1.2 確認環境・権限の準備
確認環境と権限の準備は、検証を成立させるための基盤である。ログ参照、監視閲覧、管理APIの呼び出し、テスト用エンドポイントへのアクセスなど、実施に必要なアクセス権を事前に整理する。復旧中はネットワーク経路や認証状態が変化するため、代替経路や手順も用意しておくとよい。
3.2 実施
実施段階では、時間軸を意識しつつ、観測結果を記録する。自動と手動を組み合わせ、見逃しと誤検知の両方を抑える。
3.2.1 自動監視による健全性チェック
自動監視による健全性チェックでは、アラートの収束、主要なメトリクスの回復、死活監視の整合などを確認する。重要なのは、復旧作業に伴う一時的なバラツキと、持続的な劣化を区別する点である。監視ダッシュボードや時系列ログを参照し、観測時刻と根拠をセットで残す。
3.2.2 手動確認とテスト手順
手動確認では、利用者に近い操作や代表トランザクションを再実行する。テスト手順は手順書として定義し、対象アカウント、投入データ、期待結果、タイムアウト条件を明記する。これにより、担当者が変わっても同等の検証ができ、後日の監査や原因分析にも役立つ。
3.3 段階的な復旧（段階リリース・切戻し）
段階的な復旧は、いきなり全面を開放せずに影響を小さくしながら確認を進める考え方である。復旧確認の結果が境界を超えない場合は切戻しを行い、再適用の再手順につなげる。
3.3.1 一部提供から全面提供への移行
一部提供から全面提供への移行では、機能の優先度に沿って対象範囲を広げる。例えば、読み取り系を先に解放し、次に書き込み系、最後に周辺機能を段階投入するなどの運用が考えられる。移行判断は、性能指標とエラー率が基準内に収まること、整合性リスクが残らないことを条件として行う。
3.3.2 再発兆候への対応
再発兆候への対応では、回復後に上昇し始めたエラーや特定リソースの逼迫を早期検知する。観測時刻を基準にし、直近だけでなくトレンドの変化率を参照する。兆候が基準に近づいた段階で、保守的に提供範囲を縮小するか切戻しを選ぶかを判断する。
4 復旧確認で用いる観点と指標
復旧確認では、観測の一貫性と証跡の品質が重要になる。指標は多すぎても判断できず、少なすぎても不十分になるため、復旧完了条件に直結する要素に絞り込む。
4.1 監視指標（稼働・応答・エラー）
稼働は「起動している」ことの確認であり、応答とエラーは「動作している」ことの確認である。応答は遅延の度合い、エラーは失敗の頻度と種類として扱う。指標は監視設定の閾値と同調させ、復旧確認では閾値未満に収まっただけでなく、回復の持続性を見て判断する。
4.2 ログ・イベントの整合性
ログ・イベントの整合性では、時系列のつじつま、関連するコンポーネント間の整合、追跡可能性を確認する。イベントが欠落していないか、順序が逆転していないか、復旧操作に対応する記録が残っているかを点検する。復旧確認の証跡は監視だけに依存せず、ログで裏取りすることで説明可能性が高まる。
4.3 例外系（想定外の切替、部分断）
例外系の確認は、正常系が見えていても潜む問題を拾うために行う。例えば、意図しない切替が一部で発生していないか、部分断として特定の経路や機能だけが残留障害を抱えていないかを点検する。全体が復旧しているように見えても、条件付きで失敗する挙動は利用者のクレームにつながりやすい。
4.4 証跡の品質（再現性・監査性）
証跡の品質は、再現性と監査性の観点で評価する。再現性とは、別担当者が同じ手順・同じ対象条件で確認できることを指す。監査性とは、いつ誰が何を確認し、どの根拠に基づいて判断したかが追跡できることを意味する。観測条件（対象範囲、時間帯、負荷状態）を残すと後工程の品質が上がる。
5 失敗時の再対応
復旧確認は「成功の確認」だけでなく、「失敗した場合の扱い」を前提に設計する必要がある。不完全な復旧を誤って完了扱いにしないことが、二次被害を防ぐ。
5.1 復旧不完全の判断
復旧不完全の判断は、基準未達や再劣化の兆候を根拠として行う。例えば、応答の回復が一時的であり、観測窓の終わりで再び悪化している場合、あるいは整合性の検証が未完である場合などが該当する。判断には、監視指標だけでなくログや実テスト結果を併用し、誤判定を減らす。
5.2 再切替・再適用の手順
再切替・再適用では、復旧操作をやり直す範囲と手順を整理する。切戻し後に同じ手段で再適用しても改善しない場合があるため、再試行の条件（いつまで、どの条件なら実施）を決める。安全のため、再適用のたびに証跡を更新し、直前の判断理由と関連付ける。
5.3 原因分析へのフィードバック
原因分析へのフィードバックは、復旧確認で得られた事実を後段の学習に接続する活動である。不完全な復旧は、基盤側の問題だけでなく、確認基準の不足やテスト観点の欠落に起因することもあるため、技術面と運用面を同時に振り返る。
5.3.1 恒久対策につなげる観点
恒久対策につなげる観点では、再発の可能性が高い要因を優先して潰す。復旧確認で繰り返し見つかる欠陥（監視の穴、ログの欠落、手順の曖昧さ、確認時間不足など）を具体化し、監視設計、手順書、権限設計、性能許容量のいずれかに反映する。軽微な改善を積み重ねることで、将来の復旧確認が短時間で確実になる。
6 関係者連携とコミュニケーション
復旧確認は技術活動であると同時に、組織的な合意形成を必要とする。誰がいつ何を根拠に「完了」と判断するかを共有することで、連絡の手戻りを減らす。
6.1 利用者・関係部門への報告タイミング
利用者や関係部門への報告は、状況が変わる節目で行う。例えば、暫定復旧の開始、全面復旧の見込み、切戻しの実施、再発兆候の検知などである。報告内容は、技術の詳細よりも影響範囲と見通しを中心に整理し、問い合わせ対応の負荷を抑える。
6.2 チケット運用と引き継ぎ
チケット運用では、復旧確認の実施結果をチケットに紐づける。手順と観測結果、根拠へのリンク、残課題を残し、引き継ぎ時に「なぜその結論に至ったか」が追える状態にする。特にオンコールや交代勤務がある場合、時刻と担当の明確化が引き継ぎ品質を左右する。
6.3 合意形成（復旧完了の合意プロセス）
合意形成では、技術担当の判断だけでなく、運用や関係部門が同じ基準を共有することが重要である。復旧完了の合意プロセスは、確認基準の達成状況、残留リスク、段階提供の継続有無を提示し、最終判断者が意思決定できる形に整える。記録された合意は後日の説明責任にもつながる。
7 記録・テンプレート・運用改善
復旧確認は繰り返し行われるため、記録様式と学習の仕組みが効果を持つ。テンプレートは単なる書式ではなく、品質の下限を保証する仕組みとして扱う。
7.1 復旧確認チェックリスト
復旧確認チェックリストは、確認項目を漏れなく実行するための台帳である。通信、サービス、業務の順序で整理し、各項目に観測手段（どこを見て何を確認するか）と合否条件を記載する。チェック結果は証跡へリンクし、後から再確認できる構造にしておくと監査性が高まる。
7.2 レポート例と記載項目
復旧確認レポートには、障害の概要、復旧実施内容、確認項目と結果、利用者影響の状況、残課題、次回への改善案を含める。記載項目は「事実」と「判断」を分け、観測値（数値・時刻）を優先して記述する。例として、応答性能の回復を示すグラフと観測窓、エラー率の推移、整合性検証の結果などをまとめると理解が速い。
7.3 過去事例の学習と改善（軽微な“あるある”対策含む）
過去事例の学習では、再発を防ぐ観点から、確認基準や手順をアップデートする。よくある不備として、監視が復旧しているのにログ参照権限が不足して証跡が欠ける、テストが代表経路に偏って部分断を見落とす、暫定復旧のまま時間が経ってしまう、といったパターンが挙げられる。これらは手順書とチェックリストの更新により、次回の復旧確認をより確実にする。