迅速かつ円滑なディザスタリカバリのためにしておくべきこと
包括的な業務継続計画書を作成するためのポイント
災害に備えた業務継続計画書の作成・運用のポイントと、復旧作業に取り組む際のガイドラインとなる「ディザスタリカバリテンプレート」に盛り込むべき項目を具体的に示す。
システム障害のほとんどはマイナーなものだが、重大な、あるいは予想外のインシデントが発生する可能性もある。そうした場合は業務継続計画書を活用することで、ミスを最小限に抑え、コストを減らし、時間を節約することができる。
業務継続計画書を作成するための最良のアプローチは、この文書をシステム開発ライフサイクルに組み込むことだ。企業はディザスタリカバリテストの際にこの文書を評価し、開発者が大規模なアプリケーション変更や技術的な変更を行ったら、この文書を改訂し、その正確性と最新性を維持しなければならない。
包括的な業務継続計画書がない企業は、ディザスタリカバリ情報の貴重なリポジトリとなるこの文書を腰を据えて作成する必要がある。この文書の作成では、すべての必要な情報を時間をかけて集めることが必要になる場合もある。また、システム変更が発生したり企業のニーズが変化した場合は、変更管理プロセスの一環としてこの文書を改訂するとよい。
業務継続計画書の保存
重要なアプリケーションごとに業務継続計画書を作成したら、管理者はそれを電子フォーマットで保存しなければならない。わたしはWindows SharePoint Services上の専用のドキュメントライブラリに保存している。セキュリティ対策やチェックアウト管理、承認フローといった機能が利用できるからだ。また、イントラネットサイトやネットワークドライブ上のライブラリに保存する方法もある。
大事な注意点として、既存の文書ファイルのコピーを作成しないことが挙げられる。文書の保守を2カ所で行うと、そのうち同期が取れなくなる。2つの異なるコピーの存在は、必ずリカバリ作業に混乱を招いてしまう。適切なアプローチは、ファイル名を記録するか、既存ドキュメントがあるWindows SharePoint Servicesドキュメントライブラリの場所を記録しておき、必要に応じて参照することだ。
データセンターが災害に見舞われた場合、スタッフのごく一部がリカバリサイトに赴くことになるだろう。個別の問題の専門家をオフサイトに派遣するのは実際上不可能であることから、業務継続計画書には、専門家の連絡先情報を盛り込まなければならない。リカバリチームのメンバーがリカバリ対象アプリケーションに精通していなかった場合に、専門家は誰か、どうやって連絡を取るかを調べられるようにするためだ。
ディザスタリカバリテンプレートの作成
企業は迅速かつ円滑にリカバリを行うために、リカバリチームが重要なビジネスアプリケーションの復旧に取り組む際のガイドラインとなるテンプレートを作成しておかなければならない。以下では、このディザスタリカバリテンプレートに設けるべきセクションごとに、どのような情報を盛り込むべきかを説明する。
アプリケーションシステムの概要
このセクションでは、そのアプリケーションシステムの、ほかのシステムとの関連における重要性とリカバリ時間の目安を示す。また、主なリカバリ手順を概説する。具体的には、次のような情報を含める。
- アプリケーションシステムの名前
- リカバリの優先順位(優先順位ごとのリカバリ時間の目安。例えば「高:1日以内」「中:2、3日」「低:4日以上」など)
- そのシステムなしでユーザーが業務を行える日数
- リカバリ要件の概要
文書変更の管理ログ
文書変更の監査証跡とタイムスタンプを継続的に記録する。次のような情報を含める。
- 作成日/作成者
- 最終更新日/更新者
- 最終レビュー日/レビュアー
- 最終テスト日/テスター
業務継続のための連絡先
リカバリプロセスに関与する可能性がある主要な業務関係者や技術関係者全員の連絡先情報を保守する。対象者の例は次の通り。
- アプリケーションのディザスタリカバリ責任者
- アプリケーションシステムの担当マネジャー
- 開発チーム
- データベースの管理者と技術者
- システムのオーナーやその上司の役員オーナー
各ベンダーとの連絡に必要な情報
ディザスタリカバリインシデントが発生した場合、ソフトウェアベンダーから製品のアクティベート、ライセンスの付与、サポートの提供といった支援を受けなければならなくなるかもしれない。各ベンダーと連絡を取るための次のような一般的な情報を記録しておく。
- ソフトウェア製品またはハードウェア製品の名前
- ベンダーの名前とWebサイト
- ベンダーのメールアドレス
- ベンダー側の担当者
- ベンダーのサポート窓口
- 技術サポートWebサイト
- 自社の顧客ID
- 製品のライセンスキー
技術ドキュメントライブラリの場所
リカバリチームのメンバーが対象アプリケーションに精通していない場合を想定し、次のような情報を含むオンラインドキュメントを作成しておき、その保管場所を示しておく。
- システムの説明
- I/Oインタフェース
- システムフローチャート
- ネットワーク/ワークフロー図
- アプリケーションのソースコードライブラリ
- 主要な入力ファイル、画面、帳票、出力ファイル
技術的なリカバリ情報
サーバやワークステーション、通信ネットワーク、そのほかのリソースをゼロから構築しなければならない場合に備え、技術的なフレームワークを記述する。次のような情報を含める。
- メインフレームの要件
- オンラインバッチ処理の要件
- サーバハードウェア/サーバOSの要件
- サーバミラーリングの考慮点
- ネットワークトポロジ/ネットワーク通信の要件
- Webサーバの要件
- クライアントハードウェアとクライアントOSの要件
- クライアントソフトウェアとサポートソフトウェアの要件
アプリケーションセキュリティの考慮点
リカバリプロセスにおいて、セキュリティを確保するための要件は複雑なことが多いため、明確に文書化しなければならない。次のような領域を考慮する。
リカバリ後の考慮点
オフサイトでのリカバリが必要な大規模災害に備え、復旧したデータセンターにアプリケーションを戻すための計画を策定しておく必要がある。
ダウンタイムは1分1秒ごとにビジネス機会の損失を招いてしまう。適切な業務継続計画書は、企業におけるアプリケーションのリカバリに役立つだけではない。研修や日々のサポートにも重宝するほか、特別なプロジェクトでコンサルタントから支援を受ける上でも便利だ。業務継続計画書の検証と改善は、こうしたメリットを高めることにつながる大事なステップだ。
大規模災害は、幸いまれにしか起こらないが、いつでも起こり得る。例えば、わたしの以前の勤務先の1つは、最も重要なオフィスの1つがワールドトレードセンターから1ブロックの場所にあった。2001年9月11日の米国同時多発テロの後、われわれは業務継続計画書を実際に2カ月以上にわたって運用しなければならなかった。
後は実践あるのみだ。業務継続計画書は保険証券に似ている。どちらも保護を提供してくれるが、できれば使わずに済ませたいものだ。しかし、いざというときにはこの計画書を活用することで、誰もがリカバリ作業のコスト、時間、質の面で直接恩恵を受ける。
本稿筆者のハリー・L・ウォルドロン氏は、IT業界で35年以上の経験を持つ。Microsoft MVPの受賞者で、Fairfax Information Technology Servicesで上級開発者として働いており、主要な開発プロジェクトを技術、ビジネス、管理面でサポートしている。セキュリティとそのベストプラクティスについて幾つかの技術フォーラムに寄稿している。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
4
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
5
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
7
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
8
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
9
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
10
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー