システム構成要素の用語
全121語。
クライアントが表示と業務処理を担当し、サーバがデータベースを管理する構成。
⚠ 3層との違いは業務処理を行う場所。クライアントで業務処理を行う、SQL 文がネットワークを流れる、と書いてあれば2層の特徴。
クライアントサーバと Web の3層構成
プレゼンテーション層、ファンクション層、データ層の3つに分け、クライアントは表示だけを担当する構成。
⚠ 2層と比べる問題が多い。業務処理はサーバ側で行うので、クライアントはシンクライアントでよい。
クライアントサーバと Web の3層構成
ある時間のうち、CPU が実際に処理をしていた時間の割合。
⚠ 遊休時間はその残りの時間。使用率と遊休の割合を足すと100%になる。
CPU 使用率・待ち行列と必要台数の計算
同じ仕様の待機系サーバを用意し、障害時に処理を丸ごと引き継いで、スループットを落とさずに続ける構成。
⚠ 負荷分散クラスタは処理を複数台に振り分けるので拡張しやすいが、1台壊れると残りの負荷が上がり性能が下がる。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
ディスクやプリンタなどとのデータのやり取りで、その間 CPU は使わない処理。
CPU 使用率・待ち行列と必要台数の計算
CPU・ストレージ・ネットワークなどの基盤だけを提供し、OS から上は利用者が用意するサービス。
⚠ PaaS はミドルウェアまで提供される。OS への設定・制御ができる自由度の高さが IaaS の特徴。
クラウド・仮想化・エッジと性能の増やし方
電源投入時などに最初のプログラムを読み込んで、システムを初期状態から立ち上げること。
⚠ コールドスタートの別名として問われる。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
到着がポアソン分布、処理時間が指数分布に従い、窓口が1つの待ち行列モデル。平均応答時間は処理時間 ÷ (1 − 使用率)。
CPU 使用率・待ち行列と必要台数の計算
CPUが1秒間に何百万命令を実行できるかを表す、CPU単体の速さの指標。
⚠ システム全体の処理量（スループット）とは別物。計算では「×100万命令/秒」に直す。
性能指標の基本と性能評価
回復してから次に故障するまでの稼働時間の平均。信頼性の指標。
⚠ MTTR と逆にしやすい。B は Between（故障と故障の間）なので、動いている時間。
信頼性の考え方（RASIS とフェール系の用語）
故障してから次に故障するまでの間に、システムが動いていた時間の平均。
⚠ MTTRと取り違えやすい。MTBFは「動いていた時間」で長いほど良く、MTTRは「直していた時間」で短いほど良い。稼働時間と修理時間の合計はMTBFではない。
MTBF・MTTR と稼働率の計算
故障してから回復するまでの時間の平均。保守性の指標。
⚠ MTBF と逆にしやすい。R は Repair（修理）なので、止まっている時間。
信頼性の考え方（RASIS とフェール系の用語）
故障が起きてから修理が終わって再び動くまでにかかった時間の平均。
⚠ 「回復してから次の故障までの時間」と書かれていたら、それはMTBFの説明なので誤り。
MTBF・MTTR と稼働率の計算
LAN に直接つなぎ、ストレージ側がファイルシステムを持ってファイル単位で共有させる記憶装置。
⚠ SAN は専用ネットワークでつなぎ、ファイルシステムはサーバ側にある。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
アプリの開発・運用に必要な OS やミドルウェアまでを提供し、利用者はその上でアプリを作って動かすサービス。
⚠ SaaS はアプリまで提供される。『自分でアプリを開発する』とあれば PaaS。
クラウド・仮想化・エッジと性能の増やし方
目標とのズレの比例・積分・微分の3要素を組み合わせて調整するフィードバック制御。
⚠ PLCの説明として出たら誤り。PLCはラダー図によるシーケンス制御。
リアルタイム処理と制御
工場などの産業機器を、主にラダー図で書いたシーケンスプログラムで制御する専用装置。
⚠ 「リレー回路のハードウェアで制御」は、PLCが置き換えた旧方式。「A/D変換」はA/Dコンバータの役割。
リアルタイム処理と制御
複数のディスクを1台に見せ、ストライピングやミラーリング・パリティで速さと信頼性を高める技術。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
ブロック単位でデータを分散し、パリティも全ディスクに分散して書く方式。使える容量は（台数−1）台分。
⚠ RAID3 はバイト単位＋専用パリティディスク、RAID4 はブロック単位＋専用パリティディスク。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
システムの良さを、信頼性・可用性・保守性・完全性・安全性の5つの観点で評価する考え方。
信頼性の考え方（RASIS とフェール系の用語）
完成したアプリまで提供し、利用者はそれをそのまま、またはカスタマイズして使うサービス。
⚠ 自由度は最も低いので、社内独自の機能の移行や自由な開発環境には向かない。
クラウド・仮想化・エッジと性能の増やし方
サーバとストレージをストレージ専用のネットワークで結び、ブロック単位で読み書きさせる構成。
⚠ NAS は普通の LAN につなぎ、ファイルシステムはストレージ側にある。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
1秒あたりに処理できるトランザクションの件数。
⚠ MIPS は CPU が1秒間に実行する命令数（百万単位）で、業務の処理件数ではない。
CPU 使用率・待ち行列と必要台数の計算
プログラムを実行し、表示用の HTML 文書を動的に生成するサーバ。
⚠ DB の管理（DB サーバ）、不正パケットの排除（ファイアウォール）、名前と IP アドレスの変換（DNS）とは別の機能。
クライアントサーバと Web の3層構成
記憶装置に読み書きを要求してから、実際に読み書きが始まるまでの時間。
⚠ 利用者の要求に対する反応時間はレスポンスタイム。アクセスタイムは記憶装置の話。
性能指標の基本と性能評価
システムが止まらずに、使いたいときに使える度合い。
⚠ スケーラビリティと混同しない。可用性は『止まらないこと』。
クラウド・仮想化・エッジと性能の増やし方
データが生まれる場所の近くにあるサーバでデータを一次処理し、リアルタイム性を高める方式。
⚠ サーバレスは必要なときだけ起動する方式。リッチクライアントは画面処理をクライアント側で行う方式。『データ発生源の近く』がエッジ。
クラウド・仮想化・エッジと性能の増やし方
エラーの記録や実行した命令の履歴を残す機能で、故障の原因を早く見つけられるためMTTRが短くなる。
⚠ 「MTTRが長くなる」という選択肢は誤り。
MTBF・MTTR と稼働率の計算
本来の処理以外に余分にかかる時間や資源（OSの管理処理など）。
⚠ 計算問題では「無視する」とあれば足さない。書いてあれば合計に含める。
性能指標の基本と性能評価
サーバなどの機器を自社で保有し、自社の施設で運用する形態。
⚠ クラウドと対になる言葉。
クラウド・仮想化・エッジと性能の増やし方
必要なデータが高速なメモリ（キャッシュ・バッファ）上で見つかった割合。
⚠ バッファ容量の不足を疑うときに調べる。断片化の調査ではない。
性能指標の基本と性能評価
将来の業務量を見込み、必要なハードウェアやシステム構成を前もって計画すること。
⚠ 手順は「現状把握→需要・要件の把握→限界時期・構成の検討→評価・増強」。増設の検討を先に置く選択肢はひっかけ。
性能指標の基本と性能評価
サーバにサービスを要求し、その結果を受け取って利用する側のコンピュータやソフトウェア。
⚠ サーバと役割を入れ替えた選択肢に注意。要求を出すのはクライアント。ただし、サーバが別のサーバに頼むときはそのサーバもクライアントになる。
クライアントサーバと Web の3層構成
サービスを頼むクライアントと、サービスを提供するサーバが協調して処理を進める分散処理の形態。
⚠ 密結合システムと混同しやすい。クライアントサーバはネットワークでゆるくつながる分散処理で、主記憶は共有しない。
クライアントサーバと Web の3層構成
サーバやストレージなどの資源をネットワーク経由で提供し、必要な分だけ手軽に使えるようにする形態。
⚠ グリッドコンピューティングは多数の PC の計算力を束ねるもの。資源を『提供』するのがクラウド。
クラウド・仮想化・エッジと性能の増やし方
予備拠点の場所や設備だけを確保しておき、被災後に機器とバックアップを運び込んで復元する方式。
⚠ ウォームサイトはハードウェアまで用意しておく中間の段階。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
障害のあと、ログによる前処理をせずにシステムを初期状態から起動し直すこと。IPL とも呼ぶ。
⚠ ウォームスタートは障害直前の状態を引き継いで再開する。ロールバック・ロールフォワードは DB の回復手法。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
待機系が普段は停止しているかバッチ処理などをしていて、切替のときに業務プログラムを起動する方式。
⚠ ホットスタンバイより切替が遅い。コールドスタート（再開方法）とは別物。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
クライアントからの要求を受けてサービスを提供する側のコンピュータやソフトウェア。
⚠ 機能ごとに必ず別のマシンに分ける必要はなく、クライアントと OS をそろえる必要もない。
クライアントサーバと Web の3層構成
記憶装置に続けてアクセスするとき、1回のアクセスを始めてから次のアクセスを始められるまでの周期。
⚠ アクセスタイムに次のアクセスまでの準備時間を足したもの。システムの応答とは関係ない。
性能指標の基本と性能評価
あらかじめ決めた順序や条件に従って、制御の各段階を順に進めていく方式。
⚠ フィードバック制御は「結果を常に測ってズレを直す」。順序どおりに進めるだけならシーケンス制御。
リアルタイム処理と制御
システムのモデルを作って模擬的に実験し、将来を含めた性能を予測する手法。
⚠ 実物で標準プログラムを動かすのがベンチマーク。「モデル」「模擬」ならシミュレーション。
性能指標の基本と性能評価
入出力と画面表示だけを担当し、処理やデータはサーバに任せる、機能を絞った端末。
クライアントサーバと Web の3層構成
負荷に合わせて、システムの規模や能力を増やしたり減らしたりしやすい性質。
⚠ アベイラビリティは止まらずに使える性質。スケーラビリティは『増減のしやすさ』。
クラウド・仮想化・エッジと性能の増やし方
サーバの台数を増やして、システム全体の処理能力を上げる方法。
⚠ CPU 交換・メモリ増設・上位機種への入れ替えはすべてスケールアップ。『台数』が出てきたらスケールアウト。
クラウド・仮想化・エッジと性能の増やし方
CPU の交換、メモリの増設、上位機種への入れ替えなどで、1台のサーバを高性能にする方法。
⚠ 台数を増やすのはスケールアウト。
クラウド・仮想化・エッジと性能の増やし方
データを細かく分けて複数のディスクに並べて書き、読み書きを速くすること。
⚠ これだけでは冗長性がない。RAID0 はストライピングのみ。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
システムが単位時間あたりに処理できる仕事の量で、処理能力を表す指標。
⚠ レスポンスタイム・ターンアラウンドタイムは1件あたりの「時間」。「単位時間当たり」「能力」とあればスループット。
性能指標の基本と性能評価
単位時間あたりに処理できる仕事の量。
⚠ 応答時間は1件あたりにかかる時間。スループットは量、応答時間は速さの指標。
CPU 使用率・待ち行列と必要台数の計算
期限に遅れると品質は下がるが、致命的にはならないリアルタイムシステム。
⚠ 座席予約・バンキング・Web配信は、重要そうに見えてもソフトに分類される。
リアルタイム処理と制御
ジョブを投入してから、結果の出力がすべて終わるまでの時間。
⚠ レスポンスタイムは最初の反応まで。「すべて」「完了」ならターンアラウンドタイム。
性能指標の基本と性能評価
OSが複数のプロセスにCPUを順番に割り当てるときの、1回分の持ち時間。
⚠ 性能指標ではない。指標を問う問題では外す選択肢。
性能指標の基本と性能評価
OS が、複数のタスクのうちどれにいつ CPU を使わせるかを決める仕組み。
CPU 使用率・待ち行列と必要台数の計算
データベースにデータを保管し、管理する層で、DB サーバが担当する。
⚠ 認証サーバやプロキシサーバはデータ層ではない。データ層がない構成は3層にならない。
クライアントサーバと Web の3層構成
2系統で同じ処理を同時に独立して行い、結果を照合して正しさを確かめ、片方が壊れたら残りで縮退運転する構成。
⚠ デュプレックスと間違えやすい。「照合」「同時に同じ処理」ならデュアル、「待機」「切替」ならデュプレックス。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
現用系と待機系の2系統を持ち、現用系が壊れたら待機系に切り替えて続ける構成。待機系は普段バッチ処理などをしていてもよい。
⚠ デュアルは両系が同じ処理を同時に行う。デュプレックスは片方が控え。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
デュプレックスは片方を待機させて故障時に切り替える構成、デュアルは2台で同じ処理を同時に行い結果を照合する構成。
⚠ どちらもマルチプロセッサの密結合・疎結合とは別の分類。密結合を問う問題で、ひっかけの選択肢として出る。
クライアントサーバと Web の3層構成
処理期限を1回でも守れないと、重大な事故や損害につながるリアルタイムシステム。
⚠ ソフトリアルタイムは、遅れても品質が落ちるだけ。人命や設備に関わるかどうかで見分ける。
リアルタイム処理と制御
故障率を時間の経過に沿って描いた、下がる→横ばい→上がる形の曲線。
MTBF・MTTR と稼働率の計算
ためておいたデータやジョブを、決められた手順でまとめて自動的に処理する方式。
⚠ リアルタイム処理と逆で、すぐには処理しない。
リアルタイム処理と制御
データから計算した検査用の値で、ディスク1台分のデータが消えても残りから計算し直せるもの。
⚠ RAID3・4 は専用ディスク1台に、RAID5 は全ディスクに分散して書く。RAID2 はパリティではなく ECC。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
「やや多い」「少し速い」のようなあいまいな基準を使って制御する方式。
⚠ 「あいまい性」という言葉があればファジィ制御。
リアルタイム処理と制御
業務処理（計算・判断・データ操作の指示）を行う層で、AP サーバが担当する。
⚠ データの保管はデータ層の仕事なので、ファンクション層と取り違えないこと。
クライアントサーバと Web の3層構成
制御した結果を常に測り、目標値とのズレを打ち消すように修正する方式。
⚠ フィードフォワードは外乱を予測して先回りする。フィードバックは予測できない外乱にも強い。
リアルタイム処理と制御
予測できる外乱をあらかじめ想定し、影響が出る前に修正動作を行う方式。
⚠ フィードバックは結果を見てから直し、フィードフォワードは結果が出る前に直す。
リアルタイム処理と制御
利用者が誤操作しても異常が起きないように、または誤操作しにくいように設計する考え方。
⚠ 誤操作が話題でも「確実に安全側の動作になる」とあればフェールセーフ。
信頼性の考え方（RASIS とフェール系の用語）
故障や誤動作・誤操作が起きたときに、必ず安全側へ動作させる（止める）設計の考え方。
⚠ フェールソフトは動かし続ける側。「安全側・安全に停止」とあればフェールセーフ。
信頼性の考え方（RASIS とフェール系の用語）
障害が起きたとき、機能や性能を落としながら（縮退運転）システムを動かし続ける設計の考え方。
⚠ フェールセーフは止める側、フォールトトレラントは冗長化で機能を保つ側。「縮退・性能低下・機能制限」が目印。
信頼性の考え方（RASIS とフェール系の用語）
信頼性の高い部品を使ったり十分に検証したりして、故障そのものが起きにくいようにする考え方。
⚠ フォールトトレラントは「壊れても続ける」、こちらは「そもそも壊れないようにする」。
信頼性の考え方（RASIS とフェール系の用語）
構成を冗長化し、部品が故障してもシステム全体としては処理を続けられるようにする設計の考え方。
⚠ フェールソフトとの区別が難しい。「冗長化・多重化」とあればこちら、「縮退・性能低下」とあればフェールソフト。「全体の機能を維持」だけではどちらとも言えない。
信頼性の考え方（RASIS とフェール系の用語）
データが記憶領域の飛び飛びの場所に散らばった状態で、ディスクI/Oが増えて遅くなる原因になる。
⚠ 調べるのは「データの格納状況」。キャッシュのヒット率はバッファ容量不足を調べる項目。
性能指標の基本と性能評価
利用者からの入力を受け付け、結果を画面に表示する層。
⚠ 業務処理は担当しない。業務処理はファンクション層の仕事。
クライアントサーバと Web の3層構成
利用者の要求に応じて資源を動的に割り当て、不要になったら回収する仕組み。
⚠ ライブマイグレーションは稼働中のサーバの移動。プロビジョニングは資源の割り当て。
クラウド・仮想化・エッジと性能の増やし方
主記憶が足りないとき、ページ（決まった大きさの区画）単位でデータを主記憶とディスクの間で出し入れすること。
⚠ 主記憶の取り合いを表すのはページング発生頻度。メモリ使用率は使用量にすぎず、実行待ち時間はCPUの取り合いを表す。
性能指標の基本と性能評価
標準的な測定用プログラムを実際に実行して処理性能を数値化し、他の製品と比べる性能評価の手法。
⚠ モニタリングは稼働中のシステムの計測、シミュレーションはモデルで模擬、机上解析は実行しない、負荷テストは想定量に耐えるかの判定。
性能指標の基本と性能評価
一定時間にランダムな出来事が何回起きるかを表す分布で、ここでは要求の到着の仕方を表す。
⚠ 指数分布は1件の処理にかかる時間の分布。到着はポアソン分布、処理時間は指数分布と覚える。
CPU 使用率・待ち行列と必要台数の計算
遠隔地に同じシステムを導入して稼働させ、データを常時更新しておき、被災時にすぐ業務を再開できる予備拠点。
⚠ コールドサイトは場所だけ確保し、被災後に機器と媒体を運び込む。「媒体を搬入」ならホットではない。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
待機系が現用系と同じプログラムを起動済みで監視し、障害を検知したらすぐ処理を引き継ぐ方式。
⚠ コールドスタンバイは待機系が停止中か別の仕事中で、切替時に起動する。「同時に同じ処理をする」はデュアル。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
処理の流れの中で最も能力が低く、全体の性能を決めてしまう箇所。
CPU 使用率・待ち行列と必要台数の計算
1つのサーバや DB を複数の利用者で共有しながら、利用者ごとのデータを分けて扱う方式。
⚠ ライブマイグレーションの問題でひっかけとして出る。キーワードは『共有しつつ分離』。
クラウド・仮想化・エッジと性能の増やし方
OS とアプリの間で、共通の機能を提供するソフトウェア（DBMS など）。
クラウド・仮想化・エッジと性能の増やし方
2台のディスクに同じ内容を書き込み、片方が壊れても他方で続けられるようにすること（RAID1）。容量は半分になる。
⚠ ストライピングはデータを分けて並べて書くだけで、冗長性はない（RAID0）。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
監視・計測用のプログラムで、稼働中のシステムの状態や資源の使い方を測定する手法。
⚠ ベンチマークは標準プログラムを実行して他製品と比べる点が違う。
性能指標の基本と性能評価
稼働中の仮想サーバを、OS やソフトを止めずに別の物理サーバへ移す技術。
⚠ プロビジョニングは資源の割り当てと回収。『停止せずに移す』ならライブマイグレーション。
クラウド・仮想化・エッジと性能の増やし方
はしご状の回路図の形で、シーケンス制御のプログラムを書く表記法。
リアルタイム処理と制御
データの発生と同時に処理を始め、決められた制限時間内に結果を返す処理方式。
⚠ バッチ処理は「ためてまとめて」、時分割処理は「1台を複数人で共用」。「発生と同時」「制限時間内」があればリアルタイム処理。
リアルタイム処理と制御
要求の入力を終えてから、最初の処理結果が出始めるまでの時間。
⚠ ターンアラウンドタイムは結果がすべて出終わるまで。「出始める」ならレスポンスタイム。
性能指標の基本と性能評価
不正アクセスによる破壊や情報の盗難を防げること。機密性ともいう。
⚠ フェールセーフの「安全側」とは別の話。RASIS の安全性は不正アクセス対策のこと。
信頼性の考え方（RASIS とフェール系の用語）
保守担当者が現地に行かずにネットワーク経由で診断や対処を行う保守で、MTTRを短くする。
⚠ 「遠隔保守でMTBFが短くなる」「MTTRが長くなる」は、どちらも誤り。
MTBF・MTTR と稼働率の計算
1台の物理マシンの資源を分けて動かす、ソフトウェア上のコンピュータ。
⚠ 物理マシンは実際の機械。縮退運転の問題では、止まるのは物理マシンで、その上の仮想マシンは残りの物理マシンに移る。
CPU 使用率・待ち行列と必要台数の計算
1台の物理機器の中に、ソフトウェアで複数の仮想的なサーバなどを作る技術。
⚠ グリッドコンピューティングは逆に、複数の機器を1つの計算資源のように束ねる。
クラウド・仮想化・エッジと性能の増やし方
項目ごとの大きさの違いを重みとして付けて求める平均（ここでは月ごとの総時間で重みを付ける）。
⚠ 単純平均は重みを付けずに足して個数で割るため、分母の大きさが違うと誤った値になる。
CPU 使用率・待ち行列と必要台数の計算
必要なときにいつでもシステムを使える状態であること。稼働率で表す。
⚠ 保守性（修理のしやすさ）や安全性（不正対策）の説明が選択肢に混ざる。「いつでも使える」とあれば可用性。
信頼性の考え方（RASIS とフェール系の用語）
全体の時間のうち、システムが使えた時間の割合で、MTBF ÷（MTBF＋MTTR）で求める。可用性の指標。
⚠ 分母は MTBF＋MTTR。分母を MTTR だけにしたり、分子を MTTR にしたりする誤りに注意。
信頼性の考え方（RASIS とフェール系の用語）
全体の時間のうち、システムが正常に動いていた時間の割合で、MTBF÷(MTBF＋MTTR)で求める。
⚠ MTBF−MTTRは稼働率でも正常な時間でもない。
MTBF・MTTR と稼働率の計算
制御対象に外から加わり、狙った状態からずらそうとする予期しない影響。
リアルタイム処理と制御
データが壊れたり矛盾したりせず、正しい状態を保てること。保全性ともいう。
信頼性の考え方（RASIS とフェール系の用語）
初期の不具合が収まり、故障が偶然に起きるだけで故障率がほぼ一定になる期間。
⚠ 信頼性を比べるための稼働率はこの期間に測る。期間の長さは「終わりの点−始まりの点」で読む。
MTBF・MTTR と稼働率の計算
装置が動いた時間の累計があらかじめ決めた値に達したら行う保全で、時間計画保全の一種。
⚠ 定期保全は暦（毎月など）を基準にし、経時保全は累積動作時間を基準にする。どちらも時間計画保全に含まれる。
MTBF・MTTR と稼働率の計算
一定の時間あたりに故障が起きる割合で、偶発故障期間では 1÷MTBF とみなせる。
⚠ 稼働率と名前が似ているが、故障率は「壊れやすさ」、稼働率は「動いている時間の割合」。
MTBF・MTTR と稼働率の計算
短い値が多く、長い値ほど少なくなる時間の分布で、ここでは1件あたりの処理時間を表す。
⚠ ポアソン分布（到着する件数）と対で出題される。
CPU 使用率・待ち行列と必要台数の計算
あらかじめ決めた時間で行う保全の総称で、暦の期間で行う定期保全と、累積動作時間で行う経時保全がある。
⚠ 状態監視保全は時間ではなく、装置の状態（振動・温度など）を見て必要なときに行う。どちらも摩耗故障期間向けの予防保全。
MTBF・MTTR と稼働率の計算
CPUを短い時間単位で切り替え、1台を複数のユーザが専用機のように同時利用できるようにする方式。
⚠ 「複数ユーザに共用」「専用に見せかける」がキーワード。リアルタイム処理の説明ではない。
リアルタイム処理と制御
CPU が空けばすぐ動ける状態で、CPU の割当てを待っているタスクの状態。
⚠ 待ち状態（I/O の完了などを待っていて、CPU が空いても動けない）や実行状態（いま CPU を使用中）と区別する。
CPU 使用率・待ち行列と必要台数の計算
故障した部分を切り離し、性能や機能を落としてでも処理を続けること。
⚠ フォールバック（前のレッスン）とほぼ同じ意味。デュアルシステムの説明に出てくる。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
故障した部分を切り離し、性能や機能を落としたまま運転を続けること。
⚠ フェールセーフ（危険を避けるため安全側に止める）とは逆で、止めずに運転を続ける。
CPU 使用率・待ち行列と必要台数の計算
使い始めの、設計ミスや製造不良による故障が多く、故障率が時間とともに下がっていく期間。
⚠ 対策は設計審査・故障解析の強化。部品の事前交換や経時保全は摩耗故障期間の対策。
MTBF・MTTR と稼働率の計算
同じ機器や機能を複数用意し、1つが壊れても残りで処理を続けられるようにすること。多重化・二重化ともいう。
信頼性の考え方（RASIS とフェール系の用語）
装置の状態を監視し、劣化の兆しが見えたときに保全を行う方式。
⚠ 時間計画保全は時間で行い、状態監視保全は状態を見て行う。
MTBF・MTTR と稼働率の計算
故障しにくいこと。MTBF が長いほど高い。
⚠ 可用性と混同しやすい。信頼性は「壊れにくさ」、可用性は「使える時間の割合」。
信頼性の考え方（RASIS とフェール系の用語）
静的コンテンツは誰が見ても同じ固定の内容、動的コンテンツはリクエストごとにプログラムが作る内容。
⚠ 静的は Web サーバ、動的は AP サーバが担当するのが Web サーバと AP サーバを分けたときの役割分担。
クライアントサーバと Web の3層構成
それぞれ独立した主記憶と OS を持つ複数のプロセッサを、磁気ディスクの共有や通信線でつなぐ構成。
⚠ 負荷はジョブ単位で分ける。主記憶の共有や単一 OS と書いてあれば疎結合ではない。
クライアントサーバと Web の3層構成
直前のバックアップ（フルでも増分でも）から変わった分だけを保存する方式。復元にはフルとそれ以降の増分がすべて要る。
⚠ 差分バックアップは直前のフルからの変更をすべて保存するので、復元はフル＋最新の差分1本で済む。
冗長構成とバックアップ（デュアル・デュプレックス・RAID）
処理を待つ要求が並ぶ列のこと。また、その長さや待ち時間を計算する理論。
CPU 使用率・待ち行列と必要台数の計算
構成する装置が全部動いているときだけ全体が動くつなぎ方で、稼働率は各装置の稼働率の積になる。
⚠ 並列システムは1台でも動けばよく、1−(1−a)(1−b)で計算する。
MTBF・MTTR と稼働率の計算
資源が離れた場所や複数のサーバにあっても、利用者がそれを意識せず手元の資源と同じように扱える性質。
⚠ 通信コストの削減や信頼性の向上は分散処理の利点で、透過性の説明ではない。アクセス先のサーバを知る必要があるなら透過性はない。
クライアントサーバと Web の3層構成
光を当てて、その反射の強さを測るセンサ。黒は光を吸収するため、黒に掛かるほど反射が弱くなる。
⚠ この過去問では「黒に掛かるほど出力が小さい」。出力の大小を逆に読まないこと。
リアルタイム処理と制御
想定した量のトランザクションをかけて、システムが耐えられるかを確かめるテスト。
⚠ ベンチマークは性能を数値化して他製品と比べるもので、耐えられるかの判定ではない。
性能指標の基本と性能評価
処理を複数のコンピュータに分けて行う方式。
⚠ 集中処理と比べると、故障に強く拡張しやすい一方で、運用管理が複雑になり、セキュリティの確保が難しい。
クライアントサーバと Web の3層構成
要求を出してから処理が終わって結果が返るまでの時間の平均で、待ち時間と処理時間の合計。
⚠ 処理時間（実際に処理している時間）は待ち時間を含まない。応答時間 ＝ 待ち時間 ＋ 処理時間。
CPU 使用率・待ち行列と必要台数の計算
故障の発見・診断・修理がしやすいこと。MTTR が短いほど高い。
⚠ 可用性と混同しやすい。「問題の判別・診断・修理」とあれば保守性。
信頼性の考え方（RASIS とフェール系の用語）
長く使って部品が劣化し、故障率が時間とともに上がっていく期間。
⚠ 初期故障期間と対策を入れ替える選択肢に注意。こちらは予防保全や部品交換が効く。
MTBF・MTTR と稼働率の計算
複数のプロセッサが主記憶を共有し、1つの OS で制御される構成。タスクはどのプロセッサでも実行できる。
⚠ 疎結合はプロセッサごとに主記憶と OS を持つ。「主記憶共有」「単一 OS」「タスク間の同期が必要」と書いてあれば密結合。
クライアントサーバと Web の3層構成
実行可能なタスクのうち、優先度の最も高いものに CPU を割り当てるスケジューリング方式。
⚠ 処理時間の短い順に渡す SJF（最短ジョブ優先）や、到着順に渡す FCFS（先着順）とは別物。優先度は処理時間の長さや到着順と関係ない。
CPU 使用率・待ち行列と必要台数の計算
CPU が実行する処理を持たず、何もしていない時間。
⚠ タスク側の I/O 待ちとは別物。あるタスクが I/O 待ちでも、ほかのタスクが CPU を使っていれば遊休ではない。
CPU 使用率・待ち行列と必要台数の計算
故障が起きる前に点検や部品交換を行い、故障そのものを減らす保守で、MTBFを長くする。
⚠ 遠隔保守と混同しやすい。予防保守は「壊れにくくする（MTBF）」、遠隔保守は「早く直す（MTTR）」。
MTBF・MTTR と稼働率の計算