なぜ失敗したのか？　復旧にかかった時間は？

災害復旧プランの検証──自分の失敗から学ぶ

最高の災害復旧プロセスは、日常的な失敗の中にある。既存の出来事を活用して予想外の問題を検証すれば、大規模災害への備えは大きな前進を遂げる。

公開 2007年08月06日 05時00分

更新 2012年09月04日 19時34分

著者

Russell Olsen

[TechTarget]

印刷する

　IT災害復旧プランの検証には主に4つの要素がある。既存のプロジェクトを例として使うこと、自分の失敗から学ぶこと、ソースファイルを特定すること、口頭によってプランを確認することだ。後ろの2つについては以前取り上げた。

既存のプロジェクト利用

　どこの部署にも、災害復旧プラン検証を実地に組み込めるプロジェクトが必ずあるものだ。

　開始したばかりのプロジェクト、あるいはこれから実施予定のプロジェクトは、手っ取り早く災害復旧プランを検証する好機になる。こうしたプロジェクトは、新しいハードウェアの導入を伴う場合も多い。新しいハードウェアが意味することは2つある。まず、誰かが最初からサーバの設定をする（自分が再構築した手順をテストする絶好の機会が提供される）、そして、古いサーバの引退は、バックアップをテストして自分のサーバのイメージを再構築する絶好の機会になる。

　例えば自分の会社が別の会社を買収し、両社のユーザーとコンピュータを統合して自社のActive Directoryの組織単位（OU：Organizational Unit）に組み込むとする。

　適切なロールバックプロセスでこのプロジェクトの計画を立てれば、もともとあったOUのAuthoritative Restoreテストを実行し、自分の移行計画が適切かどうかを確認できる。プロジェクトは何日か長引くかもしれないが、（業務に影響を与えない）実地検証には、数日余分に費やすだけの価値がある。

　この方法で行う災害復旧プラン検証の要点は、自分が既にやっていることの活用にある。各所に手順を追加することにより、経費がかさむ社外でのテストを実施することなく、自分のプロセスを効果的に検証できる。

失敗から学ぶ

　IT災害復旧プラン検証を実施する場合、計画的な検証を行ってインプットをコントロールしなければ、結果に確証は持てないと思われがちだ。しかしわたしの経験では、最高の災害復旧プロセスは、自分たちの日常的な失敗の中にある。

　手違いは毎日のように発生する。新しいドメイン管理者がOUを削除してしまう、Microsoft SQL Serverのデータベース管理者がデータベーススキーマのバックアップを忘れる（そしてプロダクションデータベースが落ちてからそのことに気付く）、ハードウェアの問題でExchange Serverがダウンする、などなど。

　こうした日々の問題を好機ととらえて事後検証を行い、以下のことを問い掛けてみるといい。

問題が発生したとき、対策のために災害復旧計画書を利用したか

　もし利用したのなら、さらに2つの問い掛けが必要になる。解決策はDRP（災害復旧計画書）の中に含まれていたか。もしそうでなければ、自分の計画が適切かどうかを検討しよう。全システムが完全に失われた場合にしか役に立たないとすれば、恐らくカバー範囲が広過ぎて、ちょっとした障害に対処するための詳細情報が得られないのかもしれない。

　もし利用しなかったとすれば、それはなぜなのか。災害復旧計画はチームメンバー全員が把握しておくべきものだ。災害が起きたとき、誰がそこにいて復旧作業を手伝うことになるかは分からない。

問題はどうやって発見されたのか

　これは大切だ。自分たちのチームが業務のモニタリングに使っている公式、非公式の慣行を理解する一助になるからだ。適切なモニタコントロールにより、ささいな障害が大きな問題にならないことを保証できる。

完全復旧までにどれくらい時間がかかったか

　大規模な障害が起きた場合に復旧にかかる時間をここから推定し、その時間が許容できるかどうかを判断できる。例えばActive Directoryオブジェクトの一部がうっかり削除されてしまい、その復旧に3人が2日がかりで16時間かかったとすれば、計96時間というのはかかり過ぎだと分かるだろう。1カ所で複数のドメインコントローラが失われたとして、復旧にはどのくらいかかるのか。それは許容範囲と言えるだろうか。

　問い掛けるべきことはほかにもあるだろう。しかし自分が管理しているのがActive Directoryグループであろうと、Microsoft SQL Serverチームであろうと、考え方は同じだ。日々の出来事を最大限に活用すること。多数のささいな障害は、対処法次第で、1つの致命的な障害に匹敵することもあれば、普段と変わりない業務とすることもできる。

　IT災害復旧プランの検証は、社外で大規模プロジェクトとして実施することも可能だが、1年に1回しか実施しなければ、真の意味は失われる。日常的なIT事例の検証には大きな価値がある。大規模プロジェクトにはない、想定外の事態を提供してくれるからだ。疑問を投げ掛け、チームを巻き込んで口頭で検証を行い、既存の出来事を活用して予想外の問題を検証すれば、大規模災害への備えは大きな前進を遂げるだろう。

本稿筆者のラッセル・オルセン氏は医療データマイニング企業のCIO。以前は会計大手4社の1社に勤めていた。共著論文に「A comparison of Windows 2000 and RedHat as network service providers」がある。MCPとGSNAの資格を保有。