台風、地震などの災害と「情報システム業務継続計画」について(4) – システム復旧計画の管理

台風、地震などの災害と「情報システム業務継続計画」について(4) – システム復旧計画の管理

2018年9月11日 2 投稿者: ティー・ナカジマ

経営者の皆様、こんにちは。「ITのちからで地域に貢献したい」でお馴染みの、『わかるラボ』ティー・ナカジマです。

今日は、情報システム業務継続計画策定のステップ「システム復旧計画の管理」についてお話したいと思います。この記事は、経済産業省「情報システム管理基準」をベースに作成しています。

今回は実に情報システムっぽい話が出てまいりますが、どうか最後までお目通し頂けますと幸甚です。

システム復旧計画の管理の中で行うこと

システム復旧計画の管理の中では、以下の4点を整理します。

  1. 情報システム、データ及び関連施設のバックアップ方法及び復旧方法を定める。
  2. 情報システムに関わるバックアップ方法及び手順を検証する。
  3. 復旧までの代替処理手続き及び体制を定め、検証する。
  4. 復旧手続き及び体制を定め、検証する。

それでは順を追ってご説明して参ります。

情報システム、データ及び関連施設のバックアップ方法及び復旧方法を定める。

すでに経営陣、関係部門と合意済みの業務の復旧目標に対応して、確実に情報システムを復旧するための、バックアップ方法と手順を定めます。対象には情報システムだけでなく、データと関連設備も含めます。

バックアップ手法には多くの種類があり、業務復旧の優先度や要求速度に応じて検討します。当然、速やかに復旧できる(究極にいうと”止まらない”)仕組みとするのであれば、それなりの初期投資と運用費用が必要となります。このため、効率性や経済性を考慮したバックアップ体制を設計することが肝要です。

技術的な検討が必要ですので、ここはシステムベンダーやITコーディネータなど、ITの見識者とともに作業を行うのが良いかと存じます。

ポイントとしては、

  • 業務別のバックアップ対象を明確にすること。各業務間のバックアップの整合を図ること。簡単な例では、受注システムで発生した受注データと、販売管理システムで発生した売上データとの間は整合性が取れるようにバックアップと復旧を行わなければいけません
  • 業務の復旧許容時間と復旧順位に対応する。災害や重大な障害が発生した際、r利用部門として半日を許容時間とした場合には、情報システムの復旧を半日以内に行うように設計します。システム復旧の優先順位も、関係者と合意形成した順番に実施します。
  • バックアップ要員と予算の確保。バックアップは基本的に自動で行うよう設計しますが、バックアップ自体の構築作業、バックアップ成否の確認作業、復旧作業のためにIT要員が必要となります。これらのための予算も確保する必要があります。
  • データをどの時点まで戻すか。目標復旧時点という言葉があります。これは、バックアップデータを戻した際、いつの時点の状態に戻るかを示すものです。例えば毎日で夜間にバックアップを行っている情報システムが、翌日の夕方に被災したとします。ここでバックアップデータを戻す作業を行う場合、バックアップは昨日夜に実行したものですので、データを戻すと昨日の夜の状態となり、被災当日の日中に入力したデータが消えた状態となります。そのデータを手作業でリカバリするのか。それとも、日中も1時間ごとに入力データのバックアップを取っておき、差分も含めて復旧するのか、など。業務の性質やデータ量に応じて決めておくことが肝要です。

情報システムに関わるバックアップ方法及び手順を検証する。

バックアップが正しく復旧できるかどうかを検証します。検証はシナリオを策定して実施し、検証の結果を記録に残し、不備があればバックアップ方法や手順を修正します。

災害や重大な障害はどのように発生するかわかりません。以下を考慮しながらシナリオを作成するようお願い致します。

時間

災害や重大な障害は、いつ発生するかわかりません。夜中のバッチ処理中にシステムが停止する時。日中の業務利用中に発生する時。他社からデータを取り込んでいる時、または他社へデータを送信している時など。連携する情報システムが多ければ、影響度が大きくなりますので、多くのシナリオで復旧手順を検証するようお願い致します。

場所

会計時に使用するPOSレジ。Excelファイルを置いているファイルサーバ。通信回線の故障。停電など。100%動作を保証する機器はありません。情報システムも、緊急時の想定外のデータ連携や、緊急処理の潜在的な不具合から停止する可能性もあります。どの部分が停止するかもわかりませんので、今回は○○が停止した想定で。次回は△△が停止した想定で。という形で、検証シナリオを確認して頂ければと存じます。

復旧までの代替処理手続き及び体制を定め、検証する。

情報システムを目標復旧時間までに復旧することを想定してきました。復旧までの代替処理手続きと体制について定め、検証しておくことが必要です。

通常使える情報システムが利用できないと、臨時の帳票をデータベースから直接出力する作業依頼だとか、過去のデータをバックアップテープから抽出欲しいといった、通常業務にはない特殊な作業依頼がIT部門に殺到することがあります。IT担当者は復旧作業にかかりきりの状態ですので、このような作業依頼がくると、IT部門はパニックに陥ります。

まず、IT部門としては、情報システムの復旧に携わる担当、利用部門からの作業依頼に対応する担当と分けられればベストですが、多くの人員を抱えかつその人員が災害や重大な障害発生時に100%業務遂行できる場合はともかく、出勤ができない、遠隔地からの接続ソフトも使えず、情報システム復旧に関わる要員を十分に確保できないケースもありえます。

どんな代替作業が必要になりうるのか。どれだけのリソースが必要になりうるのか。担当者のスキルに依存した作業になっていないかなど、実現可能性を詳細に確認しておきます。

また、ユーザー部門やIT担当者の責任も明確に出来るようにしておき、情報や指揮命令が錯綜しないよう体制を整理しておくことが必要です。情報の錯綜は、復旧作業の効率を落とすばかりか、誤った指示による復旧ミスの発生など、人災とも言える二次災害を誘発しかねませんので、慎重に設計するようにして下さい。

復旧手続き及び体制を定め、検証する。

災害や重大な障害が発生し、情報システムの復旧作業のスタート指示をするのか誰なのか。事前に体制を作り検証しておく必要があります。

IT現場優先で行うのか、必ず管理者や経営者に報告してから作業に着手するのか。被災する情報システムの性格に応じて、担当者が円滑に動くことが出来るような整備が必要です。

また、復旧状況を関係者に通知するための体制も整備が必要です。IT担当者は情報システムの復旧に専念していますので、通知担当者を設けるのがベストですが、リソースの都合で難しいようであれば、管理者や経営者が率先して情報共有に務めることが望ましいかと考えます。また、メールが使えないことも多くありますので、グループウェアへの掲示や館内放送、人員による伝令なども予め整理しておく必要があります。


システム復旧計画の策定は、業務の要求に合わせるために、大変複雑になるものです。経験豊富なシステムベンダーやITコーディネータなどを検討に参画させて、客観的に、漏れなく、実現可能性は維持されているかなどを検証しておくことが肝心です。

いざという時に迅速に効率よく確実に復旧するためには、正確なシステム復旧計画が必要であり、バックアップ設計の一番難しい部分と言えます。

計画通りの時間で復旧できないことも珍しいことではなく、その際の代替手段はどうするかについては、利用者部門も十分に理解していることが肝要です。経営者の皆様は、どうかこのテクニカルで複雑な領域にも目をつぶらず、自社の事業継続に必要不可欠なものとして、率先して対応状況を確認するようお願いしたいと想います。


次回は、設定した計画の実行精度を上げるため「訓練の管理」についてお話したいと思います。

本日もブログをご覧いただきましてありがとうございました!

最終更新日:2018年12月20日