RTOではなく「WRT」で考える“システム復旧を長引かせる真犯人”：復旧ではまりがちな落とし穴【後編】

企業はシステム障害などの有事の際に、業務を素早く通常通りに戻すための戦略を練っておく必要がある。復旧を円滑に進めるには、システムを復旧することに加えて、もう一歩進んだ準備が重要だ。何をすればよいのか。

[Stuart Burns，TechTarget]

　システム障害や災害などの緊急事態が発生した際、業務を通常通りに戻すためには、さまざまな“想定外”を考えておく必要がある。システムを復旧させれば業務は元通りになると考えがちだが、実はそれだけでは思い描いた通りに進みにくい。「WRT」（Work Recovery Time：業務復旧時間）を軸にして、復旧作業の実効性を高める工夫を考える。

WRTで分かる「システム復旧を長引かせる“本当の犯人”」

併せて読みたいお薦め記事

連載：復旧ではまりがちな落とし穴

• 前編：RTOでもRPOでもない「WRT」とは何か？　復旧の順序は？

システム障害に備える

• 「サーバがダウンしました」をうまく伝える方法
• いまさら聞けないRPO（目標復旧時点）とRTO（目標復旧時間）の違い
• AWS障害からの復旧計画時に意識したい「RPO」「RTO」とは？

　WRTは、システム復旧後の時間に焦点を当てる指標だ。必要不可欠なシステムが立ち上がるだけではなく、業務全体が通常の状態に戻るまでに要する時間を対象にする。この点は、システムの復旧に要する時間を示す「目標復旧時間」（RTO）とは異なる。業務を早急に元通りにするには、WRTの短縮が欠かせない。

　災害復旧（DR）において重要でありながら軽視される傾向にあるのが、各システムの統合的なテストだ。単一のシステムが復旧できたかどうかを確かめるだけではなく、複数のシステムが互いに依存関係にある場合は、関連する全てのシステムが正常かどうかを確認するための大規模なテストが欠かせない。このテストを実施することで、システム復旧を長引かせる可能性のある問題が浮き彫りになりやすい。例えば

• ファイアウォールの設定の問題
• ルーティング（通信経路）の設定の問題
• システム間の気付きにくい依存関係

などがテストによって見えてくる。

　システムを正確に復旧できるかどうかで、WRTに大きな差が生じる。頻繁にテストを実施することで、システムを要求通りに動作させるための条件がより明確になる。総じてシステムは動的であり、システム間の依存関係は変わりやすい。そのため頻繁にテストを実施することが重要になる。

　DRにおいてWRTを短縮するには、業務を通常通りに戻すために何が求められているのかを従業員に理解してもらう必要がある。WRTには、さまざまな部門や従業員が関係する。従業員が居住する地域やタイムゾーン（時間帯）が異なることは珍しくない。システムやデータの復旧だけでは、業務が通常通りに戻る保証はない。

　システムが正しく動作することの確認に加えて、そのシステムを必要とする人が正常に利用できるかどうかを確認するテストを、DR計画に組み込んでおこう。それがWRTを短縮し、一刻も早く業務を再開するための鍵を握る。

TechTarget発　先取りITトレンド

米国TechTargetの豊富な記事の中から、最新技術解説や注目分野の製品比較、海外企業のIT製品導入事例などを厳選してお届けします。