1 トラブル復旧の基本
1.1 目的と前提条件
1.1.1 影響範囲の切り分け
復旧手順では、まず障害の及ぶ範囲を切り分ける。利用者、機能、拠点、データ領域、外部連携先など、観点ごとに影響を整理することで、作業の優先順位が決まる。範囲の不確実性が高いまま復旧を進めると、未対応の領域が残りやすくなるため、観測可能な範囲から段階的に絞り込む。
1.1.2 優先度（安全・データ・サービス）の整理
優先度は、一般に安全、データ、サービスの順で組み立てる。安全は物理的リスクや運用上の危険を避ける観点であり、データは消失や改ざんの防止、サービスは可用性と業務継続の観点である。加えて、規約・契約・法令に関わる要件がある場合は別枠で扱う。優先度が現場ごとに異なると判断が割れるため、意思決定の基準を事前に合意しておく。
1.2 標準フローの全体像
1.2.1 検知・初動・判断
検知から初動までの流れは、被害を広げないための“止血”を目的とする。監視アラート、ログ、ユーザー報告などから状況を把握し、暫定的な整理を行う。判断段階では、復旧の可否、影響の拡大要因、そして後戻りの条件を定める。ここでの誤りは後工程の手戻りに直結するため、根拠となる観測情報を記録しながら進める。
1.2.2 復旧・検証・再発防止
復旧は“動かすこと”だけで完了しない。再稼働後に検証を行い、機能・性能・データ整合性を確認する必要がある。さらに、再発防止は恒久対策の設計と教育・手順更新により成立する。復旧作業と再発防止を切り離さず、調査結果をそのまま恒久対策へ接続することが、長期的な安定運用につながる。
2 初動対応（止血フェーズ）
2.1 現状把握と記録
2.1.1 影響範囲とユーザー影響の確認
初動では、影響範囲とユーザー影響を最短で把握する。具体的には、どの画面・API・ジョブが失敗しているか、応答遅延の程度や成功率の低下があるか、特定条件（特定時間帯、特定バージョン、特定地域）に偏りがあるかを観測する。利用者数や業務影響度を把握することで、復旧の目標時点と完了基準を後で決めやすくなる。
2.1.2 タイムラインと証跡の収集
時系列は、原因調査と説明責任の両方で重要になる。検知時刻、直前の変更（デプロイ、設定変更、証明書更新など）、障害の最初の兆候、段階的な悪化の様子を並べる。ログ、メトリクス、アラート履歴、変更管理の記録、外部からのアクセス記録など“根拠になる情報”を保存し、改変や消去を避ける。証跡が不足すると、復旧方針の選択が感覚頼みになりやすい。
2.2 被害拡大の抑制
2.2.1 関連機能の停止・隔離
被害を広げないために、関連機能の停止や隔離を検討する。例えば、失敗が連鎖する処理を止める、無限リトライを抑える、影響の大きい処理系統だけを一時的に切り離すといった手段がある。止める範囲は“復旧後に再開すべき対象”を損なわない範囲に制限し、復帰手順も同時に設計する。
2.2.2 通信遮断とアクセス制御
通信の遮断やアクセス制御は、被害の伝播を止めるために用いる。外部連携が原因か結果かを見極めるまで、一次的に通信経路を調整することで被害の増幅を抑える。遮断の設計では、内部から外部、外部から内部のいずれの方向が影響しているかを意識し、復旧時の再接続手順や再認証の必要性も確認する。
3 原因調査と復旧方針の決定
3.1 ログ・メトリクス・状態の確認
3.1.1 アプリケーションログの読み解き
アプリケーションログは、失敗の“理由”を示す手がかりになる。例外メッセージ、エラーコード、リクエストIDの追跡、処理手順の分岐（どの段階で止まったか）を確認する。ログが多い場合は、最初の異常発生点と、同時刻で増えているパターンを優先して読む。あわせて、ログ出力の欠落やタイムゾーンの不整合がないかも点検する。
3.1.2 インフラ指標（CPU、メモリ、通信）の観測
インフラ指標では、リソース逼迫や通信劣化の兆候を把握する。CPUやメモリの急変、スレッド枯渇、ディスクI/Oの逼迫、ネットワークのパケットロスや帯域飽和、接続数の増減などを時系列で見る。単一指標に飛びつくのではなく、アプリ側のエラーと同じタイミングで変化しているかを突き合わせることで、原因の当たりをつける。
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 検索条件・前提の固定
検索や照合作業では条件が変わると結果が変わるため、前提を固定する。例えば対象バージョン、対象環境、期間、フィルタ条件、優先するログIDなどを明示し、途中で揺らさない。復旧作業中に新しい条件へ切り替える場合は、理由と影響範囲を記録してから行う。
4.2 バックアップと復元
4.2.1 バックアップ種類と使い分け
バックアップには完全、差分、増分、スナップショット、論理バックアップなどの方式がある。復旧の目的（時点復元、部分復元、検証用復元）に応じて選択する。どのバックアップがどの時点をカバーするか、復元に必要な時間、整合性保証の範囲を事前に理解しておくことで、復旧の意思決定を速められる。
4.2.2 復元後の整合性確認
復元後は、データが壊れていないことを確認する。参照の辻褄、外部キー整合、スキーマの整合、論理的な一貫性（例：集計の整合）などを点検する。可能であれば復元元と比較し、件数差やハッシュ差分などの検証指標を用いて確認する。検証が不十分なまま再稼働すると、後から不具合が顕在化する。
4.3 フェイルオーバー／再起動
4.3.1 フェイルオーバーの手順
フェイルオーバーは、待機系へ切り替えることで可用性を維持する。切り替え前に、待機系の健全性（受信準備、同期状態、必要な依存サービスの稼働）を確認する。切り替えの対象（ロードバランサ、ルーティング、コントロールプレーンなど）を明確にし、切り替え後にトラフィックが意図した経路を通っているかを確認する。
4.3.2 再起動の順序と監視項目
再起動は順序が重要である。依存関係の逆転があると、起動不能や機能停止につながりやすい。先に基盤となるコンポーネントを起動し、次にアプリ層、その後に周辺連携を戻すといった考え方が一般的である。監視項目として、ヘルスチェック、エラーレート、応答時間、接続成功率、キュー滞留、リソース使用率などを定義し、安定化するまで観測する。
4.4 ネットワーク・設定の復旧
4.4.1 設定変更履歴の照合
ネットワークや設定の復旧では、変更履歴の照合が中心になる。ルーティング、ファイアウォール、セキュリティグループ、環境変数、サービスディスカバリ情報など、影響の範囲が広い項目は特に丁寧に照合する。復旧後に“以前の値に戻した”だけでは足りず、運用上の整合（参照先が存在すること、証明書が有効であることなど）まで確認する。
4.4.2 ネーム解決・ルーティングの確認
名前解決と経路は、見落とすと症状が残りやすい領域である。DNSや名前解決のキャッシュ、リゾルバ設定、レコード整合、TTLの扱い、ルーティングテーブルやプロキシの経路を確認する。外形監視で疎通できても内部の解決が誤っている場合があるため、利用経路に近い形で確認する。
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 ダッシュボードの確認
ダッシュボードは、復旧の見通しを共有するための可視化手段である。主要KPIが更新されているか、時刻のズレがないか、グラフが欠損していないかを確認する。可視化が不十分だと、異常が起きても気づくのが遅れるため、表示の整合性を確認する。
6 記録・報告・引き継ぎ
6.1 インシデント記録の作成
6.1.1 再現条件と影響範囲
記録には、再現に必要な条件と影響範囲を含める。どの入力、どのバージョン、どの環境、どのタイミングで発生したかを整理することで、後の検証や演習に使える。影響範囲は“今わかっていること”と“未確定”を分け、誤った断定を避ける。
1.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 復旧手順書の更新
復旧手順書は、今回の知見を反映して更新する。手順の順序変更、追加の確認項目、判断基準の追記、ロールバックの具体化などを反映し、読み手が同じ判断に辿り着けるよう整える。文章化されていない“暗黙のコツ”を言語化することも有効である。
7.3.2 演習（訓練）とレビュー
訓練は、知識を行動へ変えるために実施する。ロールプレイ形式で情報共有の速度を測ったり、手順書の抜けを洗い出したりする。レビューでは、実施者の主観だけでなく、観測指標（復旧時間、誤操作率、記録の完全性）を使って改善点を抽出する。
8 よくあるトラブル別の復旧例（ネットワーク・アプリ・データ）
8.1 ネットワーク障害の場合
8.1.1 到達性低下の復旧観点
到達性低下では、経路と名前解決の両面を見る。ロードバランサ配下のヘルス、ルーティングの変更、ファイアウォールやセキュリティグループ、プロキシ設定の整合を順に確認する。切り戻しの判断では、直前のネットワーク変更と観測された症状のタイミングを照合する。
8.1.2 設定不整合の復元手順
設定不整合の復元では、目的の状態を“差分”で捉える。誤って適用された値、片側だけ更新された構成、証明書や鍵の不整合などを特定し、復元先の設定体系に揃える。復元後は疎通だけでなく、クライアントの種類ごとの挙動差も確認しておくと漏れが減る。
8.2 アプリケーション障害の場合
8.2.1 デプロイ失敗時の対応
デプロイ失敗では、ビルド成果物と実行環境の整合を確認する。環境変数や依存ライブラリの差、設定ファイルの読み込み先、権限の不足などが原因になり得る。ロールバックが可能なら切り戻しを優先し、不可なら限定的な起動や設定修正で最小限の復旧を図る。
8.2.2 依存サービス障害時の迂回
依存先が不調の場合、迂回は“外部への依存を減らす”方向で設計する。キャッシュ参照、遅延処理への切り替え、読み取りモードへの縮退などが例となる。迂回の境界条件を決め、データの欠落や整合性の崩れが発生しない範囲で運用する。
8.3 データ障害の場合
8.3.1 読み書き不能の復旧手順
読み書き不能では、ストレージやトランザクション制御の異常を優先して確認する。ロックの競合、ディスク容量、I/Oエラー、レプリケーション遅延、接続先の誤りなどを点検する。復旧方針は、データ保全を最優先にし、復元手段を選ぶ前に状況を観測して損失を増やさない。
8.3.2 復元後の検証項目
復元後は、整合性と業務上の意味の両方で検証する。件数、更新時刻、参照関係、集計の正しさ、主要な帳票の再生成などを確認する。加えて、復旧作業に伴う再処理（再送、再計算）が必要かどうかも評価し、二重計上を防ぐ。
9 付録（実務で使う考え方）
9.1 チェックリストひな形
9.1.1 初動チェック項目
初動チェック項目は、影響、証跡、暫定措置の三つを軸にする。影響範囲と症状、検知時刻と変更履歴、ログやメトリクスの保存、隔離や遮断の要否、連絡先と担当の確定を含める。時間を節約するため、質問形式ではなく確認の行動に落とす。
9.1.2 復旧・検証の最終確認項目
最終確認では、再稼働、検証、監視、記録の完成度を見直す。主要機能の疎通と目標値達成、整合性チェックの完了、アラートの再有効化、ダッシュボード更新、インシデント記録の保存、引き継ぎ内容の反映までを並べる。完了基準は“誰が見ても同じ判定になる表現”にする。
9.2 コミュニケーションのコツ
9.2.1 用語の統一と共有
コミュニケーションでは用語を統一する。例えば「復旧」「再稼働」「完了」「迂回」の定義を共有し、会話の中で意味がズレないようにする。略語やシステム名の表記も揃えると、記録や報告の解釈が容易になる。曖昧さは後工程の誤解につながるため、短い確認で潰す。
9.2.2 進捗の見せ方（短い報告）
進捗報告は短く、構造化する。現況、直近の観測、次の作業、見込み時間、必要な意思決定という順でまとめると、読む側が迷いにくい。数値がある場合は優先して示し、ない場合は“調査中”と“次の確認予定”をセットで伝える。
9.3 ユーモアを活かした注意喚起（軽い注意）
9.3.1 「焦り」を減らす合図の作り方
軽い合図は、焦りによる早とちりを抑える目的で使える。たとえば、手順の前に「確認→実行→記録」の小さなコールを入れると、思考が戻りやすい。笑いを狙うより、注意を引くための短い定型句として設計する。
9.3.2 ありがちな勘違いの防止術
勘違い防止には、よくある誤解を“先に言語化”する。例として、「ログは保存したから大丈夫」と誤って判断せず、保存先と期間を確認するよう促す、といった注意書きが有効である。手順書の該当箇所に軽い注意ラベルを添えると、視線が止まりやすくなる。冗談は最後に添え、判断の妨げにならない粒度を保つ。