サービスマネジメントの用語
全115語。
電圧の変動を自動で調整し、一定に保つ装置。
⚠ 電池を持たないので停電時に電力を供給できない。停電や瞬断の対策なら UPS。
止められないシステムを守る BCP と UPS
事業が中断する原因とリスクを想定し、被害の回避と速やかな回復のための方針・行動手順を決めた計画。
⚠ BSC（4つの視点の戦略）、BPM（継続的な業務改善）、BPO（業務の外部委託）の説明と並べて出る。「事業中断」「回復」が BCP のキーワード。
止められないシステムを守る BCP と UPS
業務の流れを可視化し、一定のサイクルで継続的に改善していくマネジメント手法。
⚠ BPR は業務を根本から作り直す手法で、継続的な改善サイクルは含まない。「継続的・サイクル」なら BPM。
止められないシステムを守る BCP と UPS
業務プロセスをまとめて外部の専門業者に委託すること。
⚠ BCP の定義を問う問題のひっかけ。「外部に委託」「アウトソース」が出たら BPO。
止められないシステムを守る BCP と UPS
業務プロセスを根本から見直して作り直す手法。
⚠ BPM（可視化と継続的な改善）と混同しやすい。「根本から作り直す」なら BPR。
止められないシステムを守る BCP と UPS
財務・顧客・内部ビジネスプロセス・学習と成長の4つの視点から戦略を検討・評価する手法。
⚠ BCP の定義を問う問題のひっかけ。「4つの視点」が出たら BSC。
止められないシステムを守る BCP と UPS
構成アイテム（CI）とその関係を記録する、構成管理用のデータベース。
サービスマネジメントの全体像と SLA
出力する電気の電圧と周波数を一定に保つ電源装置。
⚠ 電気の質を一定に保つのが目的。「停電時にシステムを終了させるための電力」という説明なら UPS。
止められないシステムを守る BCP と UPS
サーバや記憶装置などの基盤を、事業者からサービスとして借りて使う形態。
キャパシティ管理と運用コスト
ITサービス運用のベストプラクティスを集めたフレームワーク。
⚠ SLA（合意）、共通フレーム（ソフトウェアライフサイクルプロセス）、ISO 9001（品質マネジメントの規格）と混同させる選択肢が出る。
サービスマネジメントの全体像と SLA
サービスマネジメントシステムの要求事項を定めた日本の規格（ISO/IEC 20000-1 に対応）。
⚠ ISO 9001 は品質マネジメントシステムの規格。
サービスマネジメントの全体像と SLA
目標の達成度を測るために継続して追いかける、重要な数値指標。
⚠ 可用性管理のKPIは中断回数や回復時間。SLA未達の項目数や性能インシデントの数は、別のプロセスの指標。
可用性と稼働率の計算
故障から次の故障までの平均時間で、長いほど信頼性が高い。
⚠ MTTRと逆向きに考える。MTBFは長いほど良く、MTTRは短いほど良い。
可用性と稼働率の計算
サービスの中断が起きてから次の中断が起きるまでの平均時間で、信頼性を表す。
⚠ 保守性の指標として出されたら誤り。保守性は回復時間（MTRS）。
可用性と稼働率の計算
サービスが中断してから利用者に再び提供されるまでの平均時間で、ITILでは保守性のKPIとされる。
⚠ MTBSI・MTBF（間隔＝信頼性）とは違う。「回復」が付くものが保守性。
可用性と稼働率の計算
故障してから修理が終わるまでの平均時間で、短いほど保守性が高い。
⚠ MTBFと混同しやすい。修理・回復にかかる時間は保守性の指標。
可用性と稼働率の計算
SLAを達成するために、サービス提供者がサービスデスクなどの内部グループと結ぶ合意。
⚠ SLAは対顧客、OLAは対内部グループ。
サービスマネジメントの全体像と SLA
OSを新しい版に入れ替えることで、上で動くDBやアプリへの影響を下の層から順に確認してから行う。
変更・構成管理と日々の運用作業
障害時に、どの時点のデータまで復旧できればよいかという目標。
⚠ RTO（復旧までの時間）と取り違えやすい。Point＝データの時点、Time＝かかる時間。
止められないシステムを守る BCP と UPS
障害が起きてから、業務をいつまでに復旧させるかという目標の時間。
⚠ RPO は「どの時点のデータまで戻すか」で、時刻の目標。RTO は「何時間で戻すか」で、時間の長さの目標。
止められないシステムを守る BCP と UPS
サービスの内容とサービス目標について、サービス提供者と顧客が交わす合意。
⚠ OLAは組織内部との合意、サービスカタログは全サービスの一覧。「顧客との合意」がSLAの決め手。
サービスマネジメントの全体像と SLA
サービス提供者と顧客のあいだで、可用性などのサービスの水準を数値で合意した取り決め。
可用性と稼働率の計算
サービス提供者の活動と資源を指揮し、管理するための一連の能力とプロセス。
⚠ 可用性や有効性の定義の選択肢に混ぜられる。「指揮し，管理する」とあればSMS。
サービスマネジメントの全体像と SLA
システムの導入から運用・維持管理までにかかる費用の総額。
⚠ 「開発費だけ」「導入時だけ」「通信運用費だけ」の選択肢は範囲が狭いので誤り。
キャパシティ管理と運用コスト
電池の電力で、瞬断や停電の瞬間から途切れずに短時間の電力を供給し、システムを安全に終了させる時間を稼ぐ装置。
⚠ 自家発電装置は長時間供給できるが起動が遅く、瞬断には間に合わない。AVR と CVCF は電圧などを整える装置で、停電時の供給が目的ではない。
止められないシステムを守る BCP と UPS
LAN経由の信号で、電源の入っていないPCを遠隔から起動する機能。
⚠ 監視や検知の機能ではない。用途は遠隔地のPCのソフトウェア保守などの「起動が必要な作業」。
変更・構成管理と日々の運用作業
ファイルが更新されたときに OS が付ける「前回から変わった」という目印で、試験では「ファイル更新を示す情報」と書かれる。
⚠ この目印をバックアップ後に消す（リセット）のがフルと増分、消さずに残すのが差分。
バックアップの方式・運用・復旧
業務の一部を外部の専門業者に委託すること。
⚠ 利点は「自社部門を企画・開発に専念させる」こと。元に戻しやすい・自社対応しやすい、は逆。
変更・構成管理と日々の運用作業
サービスに対する計画外の中断、サービスの品質の低下、またはまだ顧客や利用者へのサービスに影響していない事象。
⚠ 問題と混同しやすい。インシデントは「起きた異常（症状）」、問題は「その根本原因」。
インシデント管理と問題管理
ITサービスの予定外の中断や品質低下のこと。
⚠ 問題（problem）はインシデントの根本原因のこと。発生した事象そのものがインシデント。
変更・構成管理と日々の運用作業
障害などで止まったサービスを、できるだけ早く通常の状態に戻すプロセス。
⚠ 問題管理は根本原因の特定と再発防止。既知のエラーとの照合は「早く直す」ためなのでインシデント管理。
サービスマネジメントの全体像と SLA
インシデントを記録・分類・優先度付けし、必要に応じて段階的に取り扱いながら、サービスをできるだけ早く元に戻すプロセス。
⚠ 問題管理と混同しやすい。「早く戻す・既知の誤りとの照合・優先度付け」ならインシデント管理、「根本原因・再発防止・傾向分析」なら問題管理。
インシデント管理と問題管理
各PCのハードウェア・ソフトウェア情報を自動で集める機能で、不要なソフトの検出に使う。
⚠ ソフトウェア配信は「配る」機能、遠隔操作は「操作する」機能。「見つける」のはインベントリ収集。
変更・構成管理と日々の運用作業
人が誤りを起こしにくい、または起こしても影響が出にくい仕組みに作業や設備を変えること。
⚠ 教育訓練・休憩・ヒヤリハット共有は人への働きかけで、エラープルーフ化ではない。
入力データの品質管理と誤り防止
負荷の現状分析と将来予測を行い、サービス水準を保てるように CPU や回線などの資源を手当てする活動。
⚠ 遠隔地バックアップ（災害対策）、日常操作の標準化（運用管理）、要員の採用・配置（要員管理）と並べて出る。「将来予測＋資源＋サービス水準」がそろうのがキャパシティ管理。
キャパシティ管理と運用コスト
多数のPCの情報収集・遠隔操作・ソフト配信などをまとめて行う管理ソフト。
変更・構成管理と日々の運用作業
提供する全サービスの特徴・構成要素・料金などをまとめた一覧。
⚠ SLAは合意で、サービスカタログは情報の一覧。
サービスマネジメントの全体像と SLA
利用者とサービス提供組織の間に立つ単一窓口で、ITILではプロセスではなく「機能」に分類される。
⚠ インシデント管理などの「プロセス」と種別が違う。
サービスマネジメントの全体像と SLA
ITサービスを、合意した品質で利用者に届け続けるための管理活動の全体。
⚠ プロジェクトマネジメントは期限のある開発を管理するもの。サービスマネジメントは運用を継続的に管理するもの。
サービスマネジメントの全体像と SLA
サービスカタログとSLAを作って顧客と合意し、達成できているかを監視・見直すプロセス。
⚠ リスク評価はサービス継続・可用性管理、容量の計画はキャパシティ管理、費用の管理は予算業務及び会計業務。
サービスマネジメントの全体像と SLA
顧客と合意した、サービスを提供する時間帯の合計で、可用性の分母になる。
⚠ 24時間・暦日とは違う。時間帯の外の停止や計画停止は含めない。
可用性と稼働率の計算
情報・助言・サービスへのアクセス・事前に承認されている変更などを利用者が求めるもので、異常ではない。
⚠ インシデントと混同しやすい。使い方の問合せや教育依頼は要求であり、中断や品質低下ではないのでインシデントではない。
インシデント管理と問題管理
データが決められた順序（昇順・降順など）に並んでいるかを確かめる検査。
入力データの品質管理と誤り防止
模擬的にトランザクションを発生させ、応答時間やスループットを予測すること。
⚠ 「模擬的に発生させる」とあればこれで、傾向分析ではない。
キャパシティ管理と運用コスト
データベースに対する更新の内容を時刻順に記録したもので、復旧時にバックアップへ当てて最新状態にする。
⚠ バックアップ（ある時点のデータ全体の写し）とは別物。ジャーナルは「変更の履歴」。
バックアップの方式・運用・復旧
単位時間あたりに処理できる仕事の量。
⚠ 応答時間は1件にかかる時間、スループットは時間あたりの処理件数。
キャパシティ管理と運用コスト
ソフトや更新プログラムを管理サーバから各PCへ一斉に配布する機能。
⚠ インベントリ収集と取り違えやすい。検出が目的なら配信ではない。
変更・構成管理と日々の運用作業
データから一定の規則で検査文字を計算し、付加されている検査文字と一致するかで入力ミスを見つける検査。
⚠ ニューメリックチェックとの違いは「検査文字を算出」という語があるかどうか。
入力データの品質管理と誤り防止
受注や入金など日々発生する取引データを記録したファイルで、マスタファイルの更新に使う。
⚠ マスタファイル（台帳そのもの）と区別する。
バックアップの方式・運用・復旧
数値として扱う項目に、数字以外の文字が含まれていないかを確かめる検査。
⚠ チェックディジットチェックと混同しやすい。ニューメリックは文字の種類だけを見て、チェックディジットは計算した検査文字と比較する。
入力データの品質管理と誤り防止
機器どうしの接続関係を図にしたもので、構成変更の前提になる資料。
変更・構成管理と日々の運用作業
2つのパーセント値を単純に引き算した差を表す単位。
⚠ 「何%増えたか」（比率の変化）とは別物。98%→99.99%は1.99ポイント増だが、比率では約2.03%増になる。
可用性と稼働率の計算
複数の地域に分散した要員を通信技術で結び、利用者からは単一のデスクに見せるサービスデスク。
⚠ 「分散」とあってもローカルではない。「単一のように見える」ならバーチャル。
サービスマネジメントの全体像と SLA
業務が止まったときの影響を評価し、許容される最大停止時間や目標復旧時間を決める分析。
⚠ BCP のテスト・教育・見直しは BIA ではない。「時間を決める」が BIA。
止められないシステムを守る BCP と UPS
事故には至らなかったが、ヒヤリとした・ハッとした危ない出来事。
⚠ 情報共有は人の注意に頼る対策で、仕組みで防ぐエラープルーフ化とは別物。
入力データの品質管理と誤り防止
桁数や書式など、データの形式が決まりどおりかを確かめる検査。
⚠ ニューメリックチェックは数字かどうかだけを見る。桁数や書式まで見るのがフォーマットチェック。
入力データの品質管理と誤り防止
毎回すべてのファイルを保存する方式で、保存に一番時間がかかるが、復旧はそれ1つで済み一番速い。
⚠ 差分・増分はフルを土台に「変わった分」だけを保存する。全部保存するのはフルだけ。
バックアップの方式・運用・復旧
現在達成している性能を正確に反映した基準のモデルで、モデル化の第一段階として作る。
⚠ 「第一段階」「現在の性能を反映」はベースライン。将来を予測する傾向分析とは別物。
キャパシティ管理と運用コスト
顧客台帳や商品台帳のように、業務の基礎になるデータを持つファイル。
⚠ トランザクションファイルは日々の取引記録で、マスタファイルを更新する材料になる。
バックアップの方式・運用・復旧
顧客・商品など、業務で繰り返し参照される基本情報をまとめたファイル。
⚠ トランザクションファイル（日々の売上などの取引記録）は、マスタを参照する側のファイル。
入力データの品質管理と誤り防止
障害が起きると企業活動や社会に重大な影響を及ぼすシステム。
⚠ OS のような基盤ソフト、性能の限界近くで動くシステム、試験導入のシステムとは別物。「止まると社会や会社が大変」と書かれていれば正解。
止められないシステムを守る BCP と UPS
読みたい位置に直接移動して読み書きできるアクセス方法で、磁気ディスクや SSD が該当する。
⚠ 順次アクセス（先頭から順番に読む・磁気テープ）と対になる。長期保存にランダムアクセスは不要。
バックアップの方式・運用・復旧
チェックポイントに記録した状態から、処理を途中から再開すること。
⚠ リブート（OSなどの再起動）と取り違えさせる選択肢が出る。
可用性と稼働率の計算
バックアップからデータを元の場所に戻して復旧すること。
⚠ どの方式でも最初にフルを戻す。差分や増分だけでは戻せない。
バックアップの方式・運用・復旧
承認されたものを、正しい場所に適切な時期に展開するプロセス。
⚠ 変更管理は認可を決める段階、リリース管理は展開する段階。
サービスマネジメントの全体像と SLA
利用者の近くに置き、言語・文化の違いやVIPへの対応に向くサービスデスク。
⚠ 集中は1か所か少数に集める形、バーチャルは分散した要員が通信技術で単一の窓口に見える形。
サービスマネジメントの全体像と SLA
正常に終わらなかったトランザクションの更新を取り消し、そのトランザクションの開始直前の状態に戻すこと。
⚠ 「開始直前に戻す」はロールバック。「ロールフォワードで開始直前に戻す」は×。
バックアップの方式・運用・復旧
バックアップを戻した後、ジャーナルの更新後の内容を順に反映して、障害直前の状態まで進めること。
⚠ ロールバックは逆に「戻す」処理。フォワード＝前へ進める、バック＝後ろへ戻す。
バックアップの方式・運用・復旧
開発したシステムやサービスを本番運用の状態へ切り替えること。
変更・構成管理と日々の運用作業
一次サポートは窓口として初期情報を集め利用者と連絡を取り続けるグループ、二次サポートは専門的な技能と経験で解決にあたるグループ。
インシデント管理と問題管理
本番に近い環境で、実際の運用手順どおりにシステムを動かせるか確かめるテスト。
⚠ 運用部門だけで行う、または開発部門だけで行う選択肢は誤り。両部門で協働する。
変更・構成管理と日々の運用作業
監視・バックアップ・障害対応などの運用作業のしやすさ。
変更・構成管理と日々の運用作業
要求を出してから応答が返り始めるまでの時間。
キャパシティ管理と運用コスト
あらかじめ合意された時点や期間に、要求された機能を実行できるサービスの能力。
⚠ 有効性は計画した結果を達成した程度、サービス継続はリスクと事象を管理する能力。
サービスマネジメントの全体像と SLA
約束したサービス提供時間のうち、実際にサービスを使えた時間の割合。
⚠ 信頼性（壊れにくさ）・保守性（直しやすさ）とは別の性質。可用性は「結果として使えた割合」を表す。
可用性と稼働率の計算
システムや装置が正常に動いている時間の割合で、MTBF÷(MTBF＋MTTR)でも表せる。
⚠ 試験では可用性とほぼ同じ意味で使われる。故障率（1−稼働率）と取り違えないこと。
可用性と稼働率の計算
根本的な解決ができるまでの間、インシデントや問題の影響を減らしたり無くしたりする方法。
⚠ 恒久的な解決策と混同しやすい。回避策は原因を取り除かず、影響をしのぐだけ。
インシデント管理と問題管理
根本原因や回避策がすでに分かっている不具合。
サービスマネジメントの全体像と SLA
根本原因が特定されている、または回避策が存在する問題。
⚠ 新しいインシデントやプログラムの誤り一般と混同しやすい。「原因特定済み または 回避策あり」の「問題」であることが条件。
インシデント管理と問題管理
どの機器がどこに何台あり、どんな設定かを一覧にした記録。
変更・構成管理と日々の運用作業
入力原票を作成した、データの発生元となる部門。入力データの誤りはここが確認・修正する。
⚠ 運用部門はデータを処理する側で、データの正しい値を判断する立場にはない。
入力データの品質管理と誤り防止
特定の資源の利用状況を時系列で把握し、その推移から将来の利用の変化を予測する手法。
⚠ 分析モデル化（待ち行列などの数式）やシミュレーションモデル化（模擬トランザクション）と混同させられる。「時系列」が目印。
キャパシティ管理と運用コスト
サービスやプロセスを繰り返し見直して良くしていく活動。
インシデント管理と問題管理
保守などのために、あらかじめ予定して行うサービスの停止。
⚠ 障害による停止とは別扱いで、問題文では「除く」「行わない」と書かれることが多い。
可用性と稼働率の計算
サービスを構成する要素（CI）をCMDBで正しく把握し、他のプロセスに情報を提供するプロセス。
⚠ 変更管理は変更を認可するかどうかを決めるプロセス。
サービスマネジメントの全体像と SLA
ハード・ソフト・ネットワークなどの構成要素とその関係を記録し、常に最新に保つ管理活動。
⚠ 変更管理と組で出る。台帳・図・資産の識別の話なら構成管理。
変更・構成管理と日々の運用作業
それを取り除けば同じインシデントが起きなくなる、おおもとの原因。
インシデント管理と問題管理
最後のフルバックアップ以降に変わったファイルを毎回まとめて保存し、更新の印は消さない方式。
⚠ 増分と混同しやすい。基準が「最後のフル」で印を残すのが差分、基準が「直前のバックアップ」で印を消すのが増分。復旧は差分ならフル＋最新の差分1つ。
バックアップの方式・運用・復旧
業務を止めてもよい限界の時間。これを超えると事業に致命的な影響が出る。
⚠ BIA で決める値。BCP のテストや見直しで決めるものではない。
止められないシステムを守る BCP と UPS
インシデントの発生傾向を分析し、将来のインシデントを予防する方策を提案する活動。
⚠ 事後対応的な活動と混同しやすい。問題の分類・優先度設定、解決策の評価、再発の監視は、起きた問題への対応なので事後対応的。
インシデント管理と問題管理
容量あたりが安く長期保存に向くが、先頭から順に読む順次アクセスの記録媒体。
⚠ 「磁気テープでランダムアクセスを可能にする」は×。テープは順次アクセス。
バックアップの方式・運用・復旧
燃料で自ら発電し、停電時に長時間の電力を供給する装置。
⚠ 起動までに時間がかかるので瞬断には対応できない。短時間のつなぎは UPS。
止められないシステムを守る BCP と UPS
1拠点または少数の場所に集め、要員を効率的に配置して大量の問い合わせに対応するサービスデスク。
⚠ バーチャルは要員が分散している。集中は要員が物理的に集まっている。
サービスマネジメントの全体像と SLA
同じキーの値を持つレコードが複数件含まれていないかを確かめる検査。
⚠ 照合チェックはマスタに存在するかを見る。重複チェックは同じものが二つ以上ないかを見る。
入力データの品質管理と誤り防止
障害箇所を切り離し、機能や性能を落としてでもシステムの稼働を続けること。
⚠ 段階的停止、異常終了したジョブ以外の運用続行、ジョブのスケジュール変更とは別物。
可用性と稼働率の計算
電気の供給がほんの一瞬途切れること。
⚠ 長時間の停電とは別。瞬断対策には UPS が効き、自家発電装置は起動が間に合わない。
止められないシステムを守る BCP と UPS
ハードウェア導入、システム開発、導入教育など、導入時に1回だけかかる費用。
⚠ 年数倍しない。年数倍するのは「／年」の費用だけ。
キャパシティ管理と運用コスト
入力されたコードなどがマスタファイルに登録済みかを突き合わせて確かめる検査。
⚠ 重複チェックとは逆向きの検査。照合チェックは「無いこと」を、重複チェックは「二つ以上あること」をエラーとする。
入力データの品質管理と誤り防止
バックアップを上書きせず、複数の時点のもの（世代）を一定期間残しておく運用。
⚠ 「同じ媒体に上書き」は世代が残らないので×。必要な世代数がテープ本数の計算になる。
バックアップの方式・運用・復旧
関連するデータどうしの内容に矛盾がない状態のこと。
⚠ バックアップでは、更新処理の途中で取ると崩れるので、一連の更新が終わってから取る。
バックアップの方式・運用・復旧
直前のバックアップ以降に変わったファイルだけを保存し、更新の印を消す方式で、保存は最速だが復旧はフル＋全部の増分が要る。
⚠ 差分と混同しやすい。「直前」「リセットする」が増分の目印。
バックアップの方式・運用・復旧
自分たちで解決できないインシデントの解決を、より専門的なグループや上位の権限者に依頼して引き継ぐこと。
⚠ 回避策・予防処置と混同しやすい。一次サポートから二次サポートへ解決を依頼する、という「引き継ぎ」がエスカレーション。
インシデント管理と問題管理
すべての装置が動いて初めて全体が動く構成で、稼働率は各装置の稼働率を掛けたもの。
⚠ 並列と式を入れ替えやすい。直列は台数が増えるほど稼働率が下がる。
可用性と稼働率の計算
使用量が増えるほど単価が下がる料金方式で、総額のグラフは右上がりのまま傾きが段々ゆるくなる（上に凸）。
⚠ 逓増課金（傾きが段々急になる・下に凸）と取り違えやすい。総額は減らないので、右下がりのグラフは誤り。
キャパシティ管理と運用コスト
使用量が増えるほど単価が上がる料金方式で、総額のグラフは傾きが段々急になる（下に凸）。
⚠ 逓減は「減」で傾きがゆるくなり、逓増は「増」で傾きが急になる。
キャパシティ管理と運用コスト
システムへ入力するデータの元になる伝票や書類。
入力データの品質管理と誤り防止
通信費、保守費、運用費など、使っている間に毎年かかる費用。
⚠ TCO の計算では使用年数を掛ける。掛け忘れが定番のミス。
キャパシティ管理と運用コスト
複数のサービスで共有する費用を、リソース配分などの基準で各サービスに割り振ること。
⚠ 専任者の費用は配賦せず、そのサービスに全額のせる。配賦するのは共通費用だけ。
キャパシティ管理と運用コスト
値があらかじめ決めた上限・下限の範囲内にあるかを確かめる検査。
⚠ 論理チェックは複数項目の関係を見て、範囲チェックは1項目の大きさを見る。
入力データの品質管理と誤り防止
レコードを記憶領域から実際に消去すること。参照が残っていると整合性が壊れる。
⚠ 論理削除は削除の印を付けるだけでデータを残すため、後から参照や復元ができる。
入力データの品質管理と誤り防止
待ち行列理論などの数学的技法を使って、応答時間やスループットを予測すること。
⚠ 傾向分析とは違い、過去の推移ではなく数式で計算する。
キャパシティ管理と運用コスト
どれか1台が動けば全体が動く構成で、稼働率は「1 − 全部が止まる確率」で求める。
⚠ 1 − bⁿ ではなく 1 − (1 − b)ⁿ が正しい。(1 − b) は止まっている確率。
可用性と稼働率の計算
変更要求（RFC）の影響と優先度を評価し、認可するか却下するかを決めるプロセス。
⚠ リリース管理は、認可された変更を実際に展開するプロセス。
サービスマネジメントの全体像と SLA
システムへの変更を、影響評価・承認・記録の手続きに沿って安全に行う管理活動。
⚠ 構成管理は「いまの構成を正確に把握する」活動。変更管理は「変える手続き」、構成管理は「台帳」と覚える。
変更・構成管理と日々の運用作業
1つ以上のインシデント（潜在的なものを含む）の根本原因。
⚠ インシデントと混同しやすい。「プログラムの誤り」のような原因側が問題で、「異常終了」のような症状側がインシデント。
インシデント管理と問題管理
インシデントの根本原因を突き止め、再発を防ぐプロセス。
⚠ インシデント管理は回復を優先する。「根本原因」「再発防止」なら問題管理。
サービスマネジメントの全体像と SLA
インシデントの根本原因を突き止めて取り除き、インシデントの発生や再発を防ぐプロセス。
⚠ インシデント管理と混同しやすい。中断したサービスを合意した時間内に復旧するのはインシデント管理の目標。
インシデント管理と問題管理
インシデントにどの順番で対応するかの度合いで、影響度と緊急度を考えて決める。
⚠ 影響度だけ、緊急度だけで決めると誤解しやすい。両方を考慮する。
インシデント管理と問題管理
計画した活動が実行され、計画した結果が達成された程度。
⚠ 可用性の選択肢に混ぜられる。「計画した結果」とあれば有効性。
サービスマネジメントの全体像と SLA
まだ起きていない不具合について、その原因を取り除くための処置。
⚠ エスカレーションと混同しやすい。予防処置は原因への手当てで、解決の引き継ぎではない。
インシデント管理と問題管理
JIS Q 20000 でのキャパシティ管理の呼び名で、中身は同じ。
⚠ 問題文の呼び名が違うだけで、同じ問題が出る。
キャパシティ管理と運用コスト
販売数・在庫数・仕入数のように関連する項目どうしに矛盾がないかを確かめる検査。
⚠ 範囲チェックは1項目の値の大きさを見る。複数項目の関係を見ていれば論理チェック。
入力データの品質管理と誤り防止
レコードは残したまま、削除済みの印を付けて使わない扱いにすること。
⚠ 物理削除とは違い、データ自体は残る。
入力データの品質管理と誤り防止