この記事の結論
全システムを同時に最短で復旧する計画は、小規模な体制では実行が難しい場合があります。何の業務を先に戻すかを決め、認証・通信・データ・人の依存関係を整理します。
システム名より業務への影響を見る
受注、顧客連絡、請求、給与など、止まると困る業務を挙げます。同じ停止時間でも締め日や繁忙期で影響が違います。担当部門と、どの時点から許容できない影響が出るかを確認します。全てを最重要にすると復旧順を選べないため、理由を付けて優先順位を決めます。
時間とデータの目標を分ける
RTOはサービス中断から復旧までの目標時間、RPOはどこまで過去へ戻るデータ損失を許容するかの目標です。バックアップ間隔だけで達成を断定せず、失敗や復元時間を含めて評価します。AWSの指針も業務影響と実現可能性を踏まえて目標を定義しています。
依存関係と代替業務を整理する
ファイルを戻しても認証やDNSが使えなければアクセスできない場合があります。必要な通信、ID、外部サービス、担当者、端末を対応付けます。復旧まで電話や手作業で続ける範囲を決め、後でシステムへ入力し直す場合は重複や漏れを防ぐ記録方法を用意します。
机上確認から実際の復元へ進める
連絡網と手順が障害中でも読めるかを確認し、担当不在や通信障害の場面で机上訓練を行います。次に安全な環境で復元時間と内容を測ります。計画との差があれば目標、構成、体制を調整します。文書を作った年だけで終わらせず、業務や契約変更の後に更新します。
連絡網を止まっている社内システムにしか置いていないと、計画を実行できません。閲覧できる代替手段を用意し、取り扱う情報の機密性に応じて保護します。契約番号や保守窓口も更新日を記録して、使えない連絡先が残らないようにします。
| 項目 | 決める内容 | 確認相手 |
|---|---|---|
| 優先度 | 止まる影響と復旧順 | 業務責任者 |
| 目標 | 復旧時間と許容データ損失 | 業務・IT担当 |
| 実行 | 依存先・代替作業・連絡 | 担当者と委託先 |
導入・見直しのチェックリスト
- 重要業務と復旧順を決めたか
- 時間とデータ損失の目標を分けたか
- 依存先と代替作業を訓練したか
参考資料と確認範囲
- AWS：停止とデータ損失の復旧目標 — RTO・RPOと業務影響に基づく目標設定。