ITサービス継続性管理 / 応用情報の復習

復旧オプションを、ひと目で。

ポイントは、予備のデータセンターがどこまで準備できているか。
下の図で「準備済み」が増えていく様子を見てみよう。

01 / THE BIG PICTURE

① 4種類の違い

緑＝準備済み・稼働中／グレー＝これから準備

準備が少ない / 復旧は遅め準備が多い / 復旧は速め →

※ 図はこの試験問題に合わせた単純化です。ウォームのソフト・データの準備範囲は構成によって異なります。準備・費用・復旧時間は相対的な傾向です。秒数・日数の固定基準を示したものではありません。「場所だけ」は代替拠点の準備状態であり、バックアップ不要という意味ではありません。

02 / BEFORE → AFTER

災害が起きたら、何をする？

方式と時点を切り替えて確認。

復旧までの流れ代表的な手順のイメージ

03 / DON'T MIX THESE UP

ホットと即時復旧。
見るのは「平常時の役割」。

今回のイとエは、どちらも機器がある。決め手は「すでに業務を分担しているか」。

イ / 高速復旧（ホット）

準備した予備へ、切り替える。

主系
業務を処理··· →予備系
復旧に備える

災害前：同一構成の機器とデータのバックアップを用意。
災害後：遠隔地へ切替え、必要な復旧処理で再開。

判断語：準備しておき、切り替える

エ / 即時的復旧

複数拠点が、すでに働いている。

拠点A
業務を処理⇄拠点B
業務を処理

災害前：同時被災しにくい拠点で分散稼働。
災害後：残る拠点が引き継ぎ、深刻な停止を避ける。

判断語：分散して稼働、深刻な停止なし

用語の注意：即時復旧も「ホット」と呼ぶ資料がある？

あります。ITIL 2011を扱う学習資料には、高速復旧と即時的復旧の両方に「ホット・スタンバイ」を付けるものもあります。名称だけで別物だと決めず、設問の説明を読みましょう。

実務でも、ホット／ウォームの境界は製品・サービスで異なります。AWSではウォームを縮小構成で稼働させ、ホットを十分な容量の待機構成とする説明があります。実際の設計では、同期方法、切替の自動化、容量、復旧試験の結果で判断します。

RTO：いつまでに復旧するか（時間の目標）。RPO：どの時点のデータまで戻せればよいか（データ損失の許容範囲）。「ホット」という名前だけで両方は決まりません。

実務の参考：AWSの復旧戦略 ↗

04 / ANOTHER WAY TO CONTINUE

ほかの2つは、別の軸で考える。

相互協定と手作業は「温度」の次の段階ではない。誰の資源を使うか、どう業務を続けるかの選択。

⇄

相互協定

他の組織のIT資源を借りる

災害前　他組織と、災害時の相互利用を合意。

協定を発動 → 相手の資源を確保 → 復旧

自社と相手が同時に被災した場合や、容量・互換性の不足に注意。今回の選択肢ウ。

✎

手作業のワークアラウンド

ITの復旧を待つ間、人が業務を代替

災害前　紙の様式、手順、担当者を準備。

手作業へ移行 → 業務を継続 → 復旧後に照合・入力

例：受付を紙に記録する。処理量や正確さに限界があり、ITシステム自体の復旧ではない。

05 / CHECK YOUR UNDERSTANDING

平成31年春期午前問55

応用情報技術者試験

ITIL 2011 editionのITサービス継続性管理で、段階的復旧（コールド・スタンバイ）に当たるのはどれ？

設問・選択肢は復習用の要約です。選択肢を押すと判別ポイントが表示されます。

TAKEAWAY / 試験直前のひとこと

冷たいほど、これから準備。
即時は、もう働いている。

場所 → 機器 → データまで準備 → 分散稼働

比較図に戻る ↑