〔図2〕 BC/DR実践ステップ 「N社の取組み事例」 (‘95.1.17) 〔1〕事前準備、体制整備 ◆災害復旧計画 被害想定:局地/広域災害 ◇最優先業務 受発注、財務会計 ◇RTO(目標復旧時間) 24時間以内 ◇RPO(目標復旧時点) 前日の業務処理終了時点 ◇データ等のバックアップ 日次バッチ処理終了後 (‘95.1.23 ~) 〔2〕応急対応 (‘95.4.23 ~) 〔3〕暫定復旧 〔4〕本格復旧 ◆社員等の安否確認 ★本番センターへの切替 ◆非常時の最高意志決定機能、連絡体制の早期確立 ・BCサービス契約から ◇被害状況の把握、代替策の検討 ◇代替本社、データセンターの手配検討 ⇒ アウトソーシング契約へ ◆DRP発動決定 《 BC利用予告 ⇒ ⇒ 利用宣言 利用宣言 》 》 DRP発動決定 《 BC利用予告 ◇システム運用要員等の確保 ◇システム運用要員等の確保 ◇直近データ、バイタルレコードの救出、保全 想定外の事態発生 実際の立上げ・切替時間 立上げ時間:約24時間 直近のバックアップ・ データが被災エリア内 バックアップ・テープの救出~搬送、 リストア、追いかけ処理:約123時間 業務の優先順位 被害の状況 業務復旧・継続方針の決定 レベル1 RTO ≦ 24h 本 社 本社機能 < 東京> 受発注業務システム 復旧不能 ◇代替オフィス <工場> 財務会計(売掛・買掛) 人員被害無し ⇒ 新本社ビルの調達 レベル2 RTO ≦ 1ヶ月 データセンター データセンター機能 販売情報 復旧不能 要員の安全確認 ◇BCサイトの延長利用 近在の工場等 被害軽微 近在の工場等 給与、予算管理 レベル3 RTO ≦ 5ヶ月 その他 ⇒新データセンター体制 本社社員の受け入れ ・本番環境用リソース ・BCサービス資源の追加 ◆運用体制(委託)の確立 ・・・ 事前のテスト・訓練 ‘94,12 ◆資源の追加投入 ・ホスト運用業務の受託支援 (約 3年後) ★新システムへの移行 ・ホスト集中型システムから ⇒ 分散処理システムへ 汎用システム オフコン系 集中処理型 分散処理型
© Copyright 2024 Paperzz