【ITパスポート練習問題 6.3対応】(2) システムの信頼性

【解説】

正解: 1 システムが正常に稼働している時間の割合

この問題は、稼働率が何を示す指標なのか、その定義を正しく理解しているかを確認するものです。特に、稼働率が「時間の割合」を扱う指標であることをイメージできているかが問われています。

正解は1の「システムが正常に稼働している時間の割合」です。稼働率は、観測対象の期間（全稼働時間）のうち、システムが停止せずに正常に動いていた時間がどれだけの割合を占めているかを示す指標です。値が高いほど、システムが長く止まらずに利用できる状態にあったことを意味します。

選択肢2の「システムの故障が発生する頻度」は、一定時間あたりに何回故障するかを示す「故障率」に関する説明であり、稼働率とは別の指標です。選択肢3の「システムの修復にかかる平均時間」は、故障から復旧までの平均時間を示す「MTTR」の説明であり、これも稼働率そのものを表すものではありません。

【解説】

正解: 3 故障発生回数

この問題は、稼働率の計算式にどのような要素が含まれるかを理解しているかを確認するものです。特に、「時間」を基準とする指標と、「回数」を扱う指標を区別できているかがポイントです。

正解は3の「故障発生回数」です。稼働率は、全稼働時間のうち正常に稼働していた時間の割合を計算する指標であり、基本的には「全稼働時間」と「停止していた時間（故障時間）」の二つがあれば算出できます。故障が何回起きたかという回数そのものは、稼働率の計算には直接登場しません。

選択肢1の「故障時間」は、システムが停止していた時間であり、全稼働時間から差し引くことで正常稼働時間を求めるなど、稼働率の算出に必要な要素です。選択肢2の「全稼働時間」も、対象期間の長さとして分母に相当する基本的な情報であり、稼働率を求める際に欠かせない要素です。一方で、3の故障発生回数は、故障率など別の指標で利用される値です。

【解説】

正解: 2 長時間安定して動作している

この問題は、稼働率が高いシステムが現場でどのような状態にあるのか、イメージできているかを確認するものです。稼働率の定義だけでなく、その結果としてどのような運用状況になるのかを理解しているかがポイントです。

正解は2の「長時間安定して動作している」です。稼働率が高いということは、観測期間の中でシステムが停止している時間が少なく、利用者から見て「いつ見ても使える状態が続いている」という状況に近いことを意味します。故障や停止が少ないため、サービス提供の安定性が高いシステムといえます。

選択肢1の「故障が頻繁に発生する」は、停止時間が増えやすくなり、結果として稼働率を下げる要因となります。選択肢3の「修復時間が長い」も、一度故障するたびに長時間停止することを意味するため、正常稼働時間の割合が減り、稼働率は低下します。したがって、稼働率が高いシステムの特徴として適切なのは2だけです。

【解説】

正解: 2 故障が頻繁に発生する

この問題は、故障率という指標がどのような状態を表しているかを理解しているかを確認するものです。故障率は「どれくらいの頻度で故障するか」を表す指標であることをイメージできているかが問われています。

正解は2の「故障が頻繁に発生する」です。故障率が高いということは、一定時間あたりの故障回数が多い状態を意味し、システムがしばしば停止してしまうというイメージになります。その結果、ユーザーから見ても「よく止まるシステム」と感じられます。

選択肢1の「安定して長時間稼働する」は、故障が少ない状態を示しており、故障率が低いシステムの特徴です。選択肢3の「修復時間が短い」は、故障した後の復旧の速さに関する特徴であり、故障率そのものではなく「MTTR」に関連する内容です。そのため、故障率が高いシステムの特徴として適切なのは2だけです。

【解説】

正解: 3 稼働時間

この問題は、故障率の計算に必要な情報を理解しているかを確認するものです。特に、「時間あたりの故障のしやすさ」を表す指標がどのような数値を使って算出されるかが問われています。

正解は3の「稼働時間」です。故障率は、一般に「一定期間の故障回数 ÷ その間の稼働時間」で表されることが多く、分母としてシステムの稼働時間が必要になります。稼働時間が長いほど、同じ故障回数でも故障率は低く計算されます。

選択肢1の「修復時間」は、故障が発生してから復旧するまでの時間であり、「MTTR」を算出するために用いられる値です。選択肢2の「システムの価格」は、導入コストや投資額に関する情報であり、故障率の計算とは直接関係しません。そのため、故障率の計算に必要な要素として適切なのは3のみです。

【解説】

正解: 1 故障回数

この問題は、故障率を計算する際にどのような数値が直接使われるかを理解しているかを確認するものです。特に、「何回故障したか」という回数情報が故障率の中心であることを押さえられているかがポイントです。

正解は1の「故障回数」です。故障率は、一定期間に発生した故障の回数を、その期間の稼働時間で割ることで求める指標です。そのため、分子として「故障回数」を使うことが不可欠です。

選択肢2の「修復回数」は、故障が発生した数とほぼ一致する場合もありますが、指標としては故障率ではなく、修復作業の回数に関する情報であり、直接の定義には含まれません。選択肢3の「稼働率」は、正常稼働時間の割合を示す別の指標であり、故障率を計算する材料ではなく、むしろ故障率と組み合わせてシステムの信頼性を評価する側面で使われます。

【解説】

正解: 2 システムが故障するまでの平均動作時間

この問題は、MTBF（Mean Time Between Failures）が何を表す指標なのか、その定義を理解しているかを確認するものです。MTBFが「時間の長さ」を扱う信頼性指標であることをイメージできているかが問われています。

正解は2の「システムが故障するまでの平均動作時間」です。MTBFは、「ある期間の総稼働時間 ÷ 故障回数」で求めることができ、故障と故障の間にどれくらいの時間正常に動作しているかを平均的に示します。MTBFが長いほど、一度故障してから次の故障までの間隔が長い、つまり信頼性が高いと評価できます。

選択肢1の「故障から修復するまでの平均時間」は、故障が発生してから復旧するまでの時間を平均したものであり、これはMTTR（平均修復時間）の説明です。選択肢3の「システムが正常に稼働している時間の割合」は、全体のうちどれだけの時間が正常稼働かを示す「稼働率」の説明であり、MTBFの定義とは異なります。

【解説】

正解: 1 故障回数

この問題は、MTBFを計算する際に最低限必要となる情報を理解しているかを確認するものです。特に、「総稼働時間」と組み合わせて使うべき数値が何かを押さえられているかがポイントです。

正解は1の「故障回数」です。MTBFは、「総稼働時間 ÷ 故障回数」で求められます。そのため、ある期間においてシステムが何回故障したかという故障回数の情報が必要になります。故障回数が少ないほど、同じ稼働時間でもMTBFは長く計算されます。

選択肢2の「修復時間」は、故障から復旧までにかかった時間であり、MTTRを計算する際に重要となる情報です。選択肢3の「修復回数」も、作業の回数としては把握されることがありますが、MTBFの定義式には直接登場しません。そのため、MTBFの計算に必要な情報として適切なのは1だけです。

【解説】

正解: 1 故障が少ない

この問題は、MTBFが大きい（長い）ということがシステムの状態にどのように反映されるかを理解しているかを確認するものです。MTBFの数値と、現場感覚としての「故障の少なさ」を結び付けられているかがポイントです。

正解は1の「故障が少ない」です。MTBFは、故障と故障の間の平均動作時間を表すため、この値が長いということは、同じ観測時間内で発生する故障の回数が少ないことを意味します。つまり、MTBFが長いシステムほど、長い時間にわたって問題なく動作し続ける傾向があります。

選択肢2の「修復時間が短い」は、故障してから復旧するまでの時間に関する特徴であり、MTTRの評価に関係します。選択肢3の「稼働率が低い」は、停止時間の割合が高い状態を示すため、通常は故障が多かったり復旧に時間がかかったりする場合に見られます。MTBFが長いシステムはむしろ稼働率が高くなりやすく、3のような特徴にはなりにくいです。

【解説】

正解: 3 システムの修復にかかる平均時間

この問題は、MTTR（Mean Time To Repair）がどのような内容を表す指標かを理解しているかを確認するものです。特に、MTTRが「故障から復旧までの時間」に着目した指標であることを押さえられているかが問われています。

正解は3の「システムの修復にかかる平均時間」です。MTTRは、ある期間に発生した複数の故障について、それぞれの修復に要した時間を合計し、故障回数で割ることで求めることができます。この値が短いほど、障害発生時に素早くサービスを復旧できるシステム・運用体制であると評価できます。

選択肢1の「システムの稼働時間」は、システムが動作していた時間の長さであり、稼働率やMTBFなどの計算に使われる情報です。選択肢2の「システムの故障率」は、一定時間あたりにどれくらい故障するかを示す指標であり、故障の頻度を表すものであって、修復にかかる時間そのものではありません。

【解説】

正解: 2 修復時間

この問題は、MTTRを具体的に計算する際にどのような情報が必要になるかを理解しているかを確認するものです。特に、「時間」に着目した指標であることを式のレベルでイメージできているかがポイントです。

正解は2の「修復時間」です。MTTRは、各故障について発生から復旧までにかかった修復時間を合計し、それを故障回数で割ることで算出します。そのため、基礎となるデータとして「どの故障にどれくらいの時間がかかったか」という修復時間の情報が必要です。

選択肢1の「故障回数」は、MTTRを求める際に分母として用いられることがありますが、この設問は「あくまで必要な要素がどれか」という観点であり、MTTRの中心となるのは修復時間です。選択肢3の「稼働時間」は、MTBFや稼働率など他の指標で利用される値であり、MTTRの計算そのものには直接関係しません。

【解説】

正解: 1 修復が速い

この問題は、MTTRが短いシステムがどのような特徴を持つかを理解しているかを確認するものです。障害は避けられないとしても、その影響をどのように抑えるかという観点での理解が問われています。

正解は1の「修復が速い」です。MTTRが短いということは、一度障害が発生しても復旧までの時間が短く済むことを意味します。その結果、システムの停止による影響時間が短くなり、利用者への影響やビジネスへの損害を抑えやすくなります。

選択肢2の「稼働率が低い」は、停止時間が長いことを示唆するため、通常はMTTRが長かったり、故障頻度が高かったりする場合に見られる特徴です。選択肢3の「故障が多い」は、故障率が高いシステムの特徴であり、MTTRが短いか長いかとは別の観点です。MTTRが短くても、故障回数が多ければ運用上の問題は残る点に注意が必要です。

【解説】

正解: 3 処理を二重に行い信頼性を高める

この問題は、デュアルシステムという冗長構成の特徴を理解しているかを確認するものです。特に、「同じ処理を二重に行うこと」によって信頼性を高めるという考え方を押さえられているかがポイントです。

正解は3の「処理を二重に行い信頼性を高める」です。デュアルシステムは、同じ機能を持つシステムを2系統同時に稼働させ、両方で同じ処理を行うことで、片方に異常があってももう片方の結果と比較して検知したり、片系の故障時にも処理を継続できるようにする構成です。このように、処理を二重化することで全体としての信頼性や障害検出能力を高めます。

選択肢1の「全く同じシステムを同時に動作させない」は、二重化構成の考え方と逆であり、デュアルシステムの説明として不適切です。選択肢2の「故障後に自動で切り替わる」は、待機系と現用系を切り替える「デュプレックスシステム」の特徴であり、デュアルシステムとは別の構成方式の説明です。

【解説】

正解: 1 ミッションクリティカルな環境

この問題は、デュアルシステムがどのような場面で採用されやすいか、用途のイメージを持てているかを確認するものです。特に、「止まっては困るシステム」でどのような構成が求められるかを考えられるかがポイントです。

正解は1の「ミッションクリティカルな環境」です。ミッションクリティカルなシステムとは、停止すると人命、安全、社会インフラ、金融取引などに重大な影響を与えるようなシステムを指します。このような環境では、処理結果の正しさや連続稼働が強く求められるため、処理を二重化して信頼性を高めるデュアルシステムが採用されることがあります。

選択肢2の「一般的なオフィスシステム」は、メールや文書作成など、多くの場合一時的な停止が大事故にはつながらないため、デュアル構成はコスト過剰になりやすい領域です。選択肢3の「単一処理を行う小規模システム」も、冗長構成を組むコストや運用負荷に見合わないことが多く、デュアルシステムが優先的に採用される環境とは言えません。

【解説】

正解: 2 故障時でもシステムが停止しない

この問題は、デュアルシステムを採用することによって得られる利点を理解しているかを確認するものです。特に、「冗長化によってサービス継続性を高める」という発想が持てているかがポイントです。

正解は2の「故障時でもシステムが停止しない」です。デュアルシステムでは、同一機能を持つ2系統が並行して処理を行っているため、一方の系統で故障が発生しても、もう一方で処理を継続できます。その結果、全体としてはサービス停止を回避しやすくなり、高い信頼性と可用性を実現できます。

選択肢1の「システムの運用コストが低い」は、二重化によるハードウェア・ソフトウェア・運用コストの増加を考えると、むしろデュアルシステムの特徴とは逆です。選択肢3の「システムの設定が簡単である」も、複数系統の同期や監視、切り替えロジックなどを考慮する必要があるため、一般的には単一構成よりも設定や運用が複雑になります。

【解説】

正解: 2 一方のシステムが故障した際に自動で切り替わる

この問題は、デュプレックスシステムの動作イメージを理解しているかを確認するものです。特に、「現用系」と「待機系」という構成で、自動切り替えによってサービスを継続する仕組みをイメージできているかがポイントです。

正解は2の「一方のシステムが故障した際に自動で切り替わる」です。デュプレックスシステムでは、通常は片方のシステム（現用系）が処理を担当し、もう片方（待機系）は待機状態または軽負荷状態で控えています。現用系に障害が発生すると、自動的に待機系へ処理を切り替えることで、サービス停止時間を最小限に抑えます。

選択肢1の「同時に2つのシステムが並行して稼働する」は、両系統で同じ処理を同時に行うデュアルシステムの説明に近い内容です。選択肢3の「常に両方のシステムを稼働させる」も、二重処理を前提とする構成のイメージであり、待機系を持って切り替えを行うデュプレックスシステムの特徴とは異なります。

【解説】

正解: 3 故障時でも運用が継続できる

この問題は、デュプレックスシステムを導入することで得られる主な利点を理解しているかを確認するものです。特に、障害発生時のサービス継続性という観点から利点を説明できるかがポイントです。

正解は3の「故障時でも運用が継続できる」です。デュプレックスシステムでは、現用系に障害が発生した場合でも、待機系へ自動的に切り替えることで、利用者から見たサービス停止を最小限に抑えられます。この仕組みにより、単一構成と比べて運用の継続性が大きく向上します。

選択肢1の「システム設定が容易である」は、冗長構成ならではの切り替え制御や同期などを考えると、必ずしも容易とは言えません。選択肢2の「コストが安い」も、待機系を別途用意する必要があるため、単一構成よりハードウェアや運用コストが高くなるのが一般的であり、デュプレックスシステムの利点としては不適切です。

【解説】

正解: 1 信頼性が重視される環境

この問題は、デュプレックスシステムがどのような場面で利用されるのが適切かを理解しているかを確認するものです。特に、「多少コストが増えても止めたくないシステム」がどのような環境かをイメージできているかがポイントです。

正解は1の「信頼性が重視される環境」です。金融システム、重要な基幹系業務、社会インフラを支えるシステムなど、障害が発生してもすぐに運用を続ける必要がある環境では、デュプレックスシステムのような冗長構成が採用されます。待機系への自動切り替えにより、サービス停止時間を短く抑えることができます。

選択肢2の「一般的なデータバックアップ」は、バックアップの取得や保存の仕組みの話であり、リアルタイムの運用継続を目的とするデュプレックス構成とは目的が異なります。選択肢3の「開発中のシステム検証」は、稼働中サービスの高信頼運用よりも、テストや検証の柔軟性が重視される場面であり、デュプレックスシステムが優先的に求められる場面とは言えません。

【解説】

正解: 3 障害が発生した際にシステムを停止させる

この問題は、フェールセーフという設計思想が「安全側に倒す」ことを重視している点を理解しているかを確認するものです。特に、「止めないこと」よりも「危険な状態を避けること」が優先される場面をイメージできているかがポイントです。

正解は3の「障害が発生した際にシステムを停止させる」です。フェールセーフでは、障害や異常が発生したときに、そのまま動作を続けてしまうと危険が生じる場合を想定し、あえてシステムを停止させたり、安全な状態に移行させたりすることで、人や設備への被害を最小限に抑えます。

選択肢1の「障害が発生した際に自動で切り替わる」は、待機系に切り替えることで運用継続を図るフォールトトレラントやデュプレックスシステムの考え方に近い内容です。選択肢2の「障害が発生してもシステムを稼働させ続ける」は、安全よりも可用性を優先した考え方であり、フェールセーフの目的と正反対です。

【解説】

正解: 2 エレベーターが故障時に最寄りの階で停止する

この問題は、フェールセーフの具体例を通じて、その設計思想をイメージできているかを確認するものです。特に、「障害時に安全な状態に移行する」という特徴を現実の装置に当てはめて考えられるかがポイントです。

正解は2の「エレベーターが故障時に最寄りの階で停止する」です。エレベーターで異常が検知された場合、動作を続けると利用者に危険が及ぶ可能性があります。そのため、最寄りの階で停止し扉を開けるなど、安全な状態で停止させるよう設計することがフェールセーフの考え方にあたります。

選択肢1の「ネットワークの自動切替」は、障害が発生してもサービスを継続するための仕組みであり、フォールトトレラントや冗長構成の例として捉えるのが適切です。選択肢3の「データの定期バックアップ」は、データ保全や復旧の観点で重要な取り組みですが、障害発生時に即座に安全な状態に移行するフェールセーフの典型例とは言えません。

【解説】

正解: 2 医療機器

この問題は、フェールセーフが特に重視される分野がどこかを理解しているかを確認するものです。特に、「障害が人命や重大な事故につながる可能性があるか」という観点で考えられるかがポイントです。

正解は2の「医療機器」です。医療機器は誤動作や制御不能な状態が発生すると、患者の生命や健康に直結した深刻な結果を招くおそれがあります。そのため、異常が起きた際には動作を継続するのではなく、安全な状態で停止する、警報を出すなど、フェールセーフの設計が特に重要となります。

選択肢1の「高速ネットワーク」は、障害が発生するとサービスの遅延や停止が問題になりますが、多くの場合は人命に直結するとは限りません。選択肢3の「エンターテインメントシステム」も、停止すると利便性は損なわれますが、安全面で医療機器ほど厳しいフェールセーフが求められるわけではありません。

【解説】

正解: 1 故障が発生してもシステム全体が停止しない

この問題は、フォールトトレラントという考え方が「故障があってもサービスを止めないこと」を目的としている点を理解しているかを確認するものです。特に、部分的な故障に対して全体としての機能を維持する設計をイメージできているかがポイントです。

正解は1の「故障が発生してもシステム全体が停止しない」です。フォールトトレラントシステムでは、CPUやディスク、ネットワークなどの重要な構成要素を冗長化し、一部に故障が起きても他の正常な要素に処理を引き継がせることで、システム全体としてのサービス提供を継続します。これにより、高い可用性が求められるシステムでも停止時間を最小限に抑えることができます。

選択肢2の「故障が発生したら即座にシステムを停止する」は、危険時に安全側へ倒すフェールセーフの考え方を表しており、フォールトトレラントとは異なります。選択肢3の「故障が発生した場合、自動的にシステムをリセットする」は、一時的な復旧方法として使われることはありますが、リセット中はサービスが止まるため、「停止させない」ことを目的とするフォールトトレラントの本質とは一致しません。

【解説】

正解: 1 高可用性が求められる金融システム

この問題は、フォールトトレラントがどのようなシステムに対して特に求められるかを理解しているかを確認するものです。特に、「システム停止が許されにくい業務」をイメージできているかがポイントです。

正解は1の「高可用性が求められる金融システム」です。金融システムは、取引の停止や誤処理が大きな損失や信用低下につながるため、24時間365日に近い稼働が求められます。こうしたシステムでは、一部の故障では全体を止めないフォールトトレラントな構成が重視されます。

選択肢2の「低コストで運用可能な小規模システム」は、コストを優先するケースが多く、フォールトトレラントのような高度な冗長構成は過剰になることが多いです。選択肢3の「単一の処理を行うスタンドアロンシステム」も、停止時の影響範囲が限定されることが多く、必ずしもフォールトトレラントが必要になるとは限りません。

【解説】

正解: 2 故障時でもサービスが継続される

この問題は、フォールトトレラントシステムを導入することで得られる主な利点を理解しているかを確認するものです。特に、「壊れないこと」ではなく「壊れても止まらないこと」を重視する考え方を押さえられているかがポイントです。

正解は2の「故障時でもサービスが継続される」です。フォールトトレラントシステムでは、冗長化された構成要素のどれかが故障しても、残りの正常な要素で処理を継続することで、利用者から見たサービス停止を防ぎます。これにより、障害発生時のビジネスへの影響を大幅に軽減できます。

選択肢1の「システムの修復が早い」は、障害対応プロセスや運用体制に関する利点であり、フォールトトレラントの構造そのものの利点とは言えません。選択肢3の「導入コストが低い」は、冗長構成によりハードウェアやソフトウェア、運用のコストが増えることを考えると、フォールトトレラントシステムの一般的な特徴とは逆です。

【解説】

正解: 3 ユーザーが誤操作しても安全に動作させる

この問題は、フールプルーフという設計思想が、ユーザーの誤操作を前提に安全性を確保しようとするものであることを理解しているかを確認するものです。特に、「人は間違える」という前提に立って設計する考え方をイメージできているかがポイントです。

正解は3の「ユーザーが誤操作しても安全に動作させる」です。フールプルーフ設計では、たとえユーザーが間違った操作をしても、重大な事故や故障につながらないように、構造やインタフェースを工夫します。これにより、利用者のミスによるトラブルを未然に防ぎ、安全性と使いやすさを両立します。

選択肢1の「システムの操作を完全に自動化する」は、自動化の方針に関する説明であり、誤操作への耐性を高めるフールプルーフの定義とは異なります。選択肢2の「システムが故障しないようにする」は、信頼性向上や予防保全の考え方に近く、フールプルーフの「誤操作をしても安全にする」という視点とは別のものです。

【解説】

正解: 2 電源プラグが逆向きには差し込めない設計

この問題は、フールプルーフの具体例を通じて、その設計思想を理解しているかを確認するものです。特に、「間違ったやり方を物理的・構造的にできないようにする」という考え方をイメージできているかがポイントです。

正解は2の「電源プラグが逆向きには差し込めない設計」です。コンセントや電源プラグが、正しい向きにしか差し込めないような形状になっているのは、誤った向きで接続してしまうことを防ぐフールプルーフの典型例です。ユーザーが迷ったり、多少雑に扱ったりしても安全な状態が保たれるように設計されています。

選択肢1の「ソフトウェアの自動更新機能」は、最新状態を保つための仕組みであり、誤操作を防ぐというよりは保守性やセキュリティ向上に関する機能です。選択肢3の「データのリアルタイムバックアップ機能」は、障害やデータ消失に備える仕組みであり、誤操作時の安全な動作というよりは、復旧手段の確保に関する取り組みです。

【解説】

正解: 1 産業機器

この問題は、フールプルーフが特に重視される分野を理解しているかを確認するものです。特に、誤操作が重大な事故や設備損傷につながる可能性があるかどうかという観点で考えられるかがポイントです。

正解は1の「産業機器」です。工場の生産設備や重機などの産業機器は、操作ミスが人身事故や大規模な設備損傷につながるおそれがあります。そのため、スイッチの配置や操作手順、インタロック機構などにフールプルーフ設計を取り入れ、誤操作そのものを起こしにくくしたり、誤操作をしても危険な状態にならないように工夫したりします。

選択肢2の「教育システム」や選択肢3の「ソーシャルメディアプラットフォーム」でもユーザーの誤操作を防ぐ工夫は重要ですが、一般的には産業機器ほど直接的に人命や物的損害に影響するわけではありません。そのため、フールプルーフが「特に重要」とされる分野として最も適切なのは1です。

【解説】

正解: 2 バックアップシステムを停止状態で待機させる

この問題は、コールドスタンバイという待機方式の特徴を理解しているかを確認するものです。特に、「バックアップ側は普段は動いていない」という運用イメージを持てているかがポイントです。

正解は2の「バックアップシステムを停止状態で待機させる」です。コールドスタンバイ構成では、現用システムのみが通常稼働し、バックアップシステムは電源オフやサービス停止状態などで待機させておきます。障害が発生した際に、バックアップ側を起動・設定して切り替えることで、サービスを再開します。

選択肢1の「常にバックアップシステムが稼働している」は、ホットスタンバイなど、バックアップ側も常時起動している構成の説明です。選択肢3の「障害発生時に即時に切り替わる」は、待機側がすでに稼働しているホットスタンバイ構成の特徴であり、起動操作を要するコールドスタンバイの特徴とは異なります。

【解説】

正解: 2 コストを抑えつつ信頼性を確保したいシステム

この問題は、コールドスタンバイ構成がどのようなニーズを持つシステムに適しているかを理解しているかを確認するものです。特に、「高可用性はある程度欲しいが、常時二重稼働させるほどのコストはかけられない」という状況をイメージできているかがポイントです。

正解は2の「コストを抑えつつ信頼性を確保したいシステム」です。コールドスタンバイでは、バックアップシステムを平常時には停止させておくため、ホットスタンバイに比べて電力や保守、ライセンスなどのコストを抑えやすくなります。一方で、障害時にはバックアップを起動して切り替えることで、一定の信頼性を確保できます。

選択肢1の「即時の切り替えが必要なシステム」は、停止時間をほとんど許容できないため、バックアップが常時稼働していてすぐ切り替えられるホットスタンバイのような構成が適しています。選択肢3の「常に高可用性が求められるシステム」も、ダウンタイムを極小化する必要があるため、起動に時間がかかるコールドスタンバイでは不十分な場合が多いです。

【解説】

正解: 3 起動に時間がかかる

この問題は、コールドスタンバイ方式の弱点・デメリットを理解しているかを確認するものです。特に、「バックアップ側が停止していること」が障害時の対応時間にどう影響するかを考えられるかがポイントです。

正解は3の「起動に時間がかかる」です。コールドスタンバイでは、バックアップシステムは通常停止しているため、障害発生後に電源投入やサービス起動、設定反映などの手順を踏む必要があります。その結果、ホットスタンバイに比べて切り替え完了までの時間が長くなり、サービス停止時間も伸びる可能性があります。

選択肢1の「高コストである」は、むしろ常時二重稼働する構成の方が高コストであり、コールドスタンバイはコストを抑えられるケースが多いです。選択肢2の「常に稼働しているため寿命が短い」も、バックアップ側は停止状態であることが多いため、コールドスタンバイのデメリットとは言えません。

【解説】

正解: 1 常にバックアップシステムが稼働している

この問題は、ホットスタンバイ構成の基本的な特徴を理解しているかを確認するものです。特に、「バックアップ側も平常時から起動している」という点を押さえられているかがポイントです。

正解は1の「常にバックアップシステムが稼働している」です。ホットスタンバイでは、現用系とバックアップ系の両方を稼働させておき、データ同期や状態監視を行いながら、現用系に障害が発生したときには迅速にバックアップ系へ切り替えられるようにしています。これにより、サービス停止時間を非常に短く抑えることができます。

選択肢2の「バックアップシステムを停止状態で待機させる」は、まさにコールドスタンバイの特徴です。選択肢3の「障害発生時に手動で切り替える」は、一部の構成で行われることはありますが、ホットスタンバイの利点である「即時性」「自動切り替え」とは必ずしも一致しません。

【解説】

正解: 1 高い可用性が求められるシステム

この問題は、ホットスタンバイ構成がどのようなシステムに向いているかを理解しているかを確認するものです。特に、「サービス停止時間をほとんど許容できないシステム」を具体的にイメージできているかがポイントです。

正解は1の「高い可用性が求められるシステム」です。決済システムやオンラインサービスなど、障害が発生してもほぼ途切れることなくサービスを提供し続ける必要がある場合、バックアップ側が常に稼働しているホットスタンバイ構成が有効です。障害検知後すぐに切り替えられるため、ユーザーが気付かないレベルで運用を継続できることもあります。

選択肢2の「コストを抑えつつ信頼性を確保したいシステム」は、ホットスタンバイよりもコールドスタンバイのような構成が検討されるケースが多いです。選択肢3の「定期的にシステムを停止しても問題ないシステム」は、一時的な停止が許容されるため、高コストなホットスタンバイを採用しなくても、メンテナンス停止などで対応できる場合が多くなります。

【解説】

正解: 2 高コストである

この問題は、ホットスタンバイ構成のデメリットを理解しているかを確認するものです。特に、「バックアップ側も常時稼働していること」がコスト面にどのような影響を与えるかを考えられるかがポイントです。

正解は2の「高コストである」です。ホットスタンバイでは、現用系と同等のバックアップシステムを常に稼働させるため、ハードウェア・ソフトウェア・電力・保守といったコストが二重にかかりやすくなります。また、データ同期や監視の仕組みも必要になるため、設計・運用面のコストも増加します。

選択肢1の「起動に時間がかかる」は、バックアップ側がすでに起動しているホットスタンバイの特徴とは逆であり、むしろコールドスタンバイに見られるデメリットです。選択肢3の「定期的なメンテナンスが必要ない」も誤りであり、ホットスタンバイ構成であっても、現用系・バックアップ系ともに定期的なメンテナンスや動作確認が必要です。