サービスマネジメントの要点とまちがえやすい点（ITパスポート試験 論点テキスト）

このページの論点

マネジメント系｜サービスマネジメント｜14論点・要点73本・まちがえやすい点49本・式1本

• サービスマネジメント
  • ITIL・ISO/IEC 20000・継続的改善
  • SLA・SLO・OLAの違い
  • サービスレベル管理と稼働率の計算
• サービスマネジメントシステム
  • インシデント管理と問題管理
  • サービス要求管理・カタログ・ナレッジ管理
  • 変更管理の区分とCAB
  • 構成管理とIT資産管理
  • リリース・展開管理と本番反映の手法
  • 可用性・キャパシティ・需要・アクセスの管理
  • 事業継続計画とRTO・RPO
  • ディザスタリカバリと代替サイト
  • サービスデスクの形態とエスカレーション
• ファシリティマネジメント
  • 電源・耐震設備とグリーンIT
  • 情報資産の物理的保護

サービスマネジメント

ITIL・ISO/IEC 20000・継続的改善

ITILとISO/IEC 20000の位置づけ、運用へ開発手法を取り入れるSRE、継続的改善の意味を扱う。

要点

• ITILは、ITサービスマネジメントにおけるベストプラクティスを体系化したフレームワークである。
• ISO/IEC 20000は、ITサービスマネジメントシステム（ITSMS）の構築・実装・維持・継続的改善に関する要求事項を定めた国際規格である。
• ISO/IEC 20000は、ITILのベストプラクティスを踏まえて策定された規格である。
• SREは、運用へソフトウェア工学の手法を取り入れ、自動化などで信頼性と拡張性を高める取組みである。
• 継続的改善は、現状評価と改善策の実施を繰り返し、サービスや業務プロセスの品質を絶えず高める活動である。

まちがえやすい点

• PMBOKはプロジェクトマネジメントの知識体系、CMMIは開発プロセスの成熟度を評価するモデルであり、ITサービス運用のベストプラクティスであるITILではない。
• ISO/IEC 27001は情報セキュリティマネジメントシステム、ISO/IEC 25010はソフトウェア製品の品質特性の規格であり、ISO/IEC 20000とは対象が異なる。
• ERPは経営資源を統合管理する仕組み、CRMは顧客関係管理であり、運用の信頼性を高めるSREとは別である。

SLA・SLO・OLAの違い

サービス提供者と利用者の合意であるSLA、その数値目標のSLO、組織内部の合意であるOLAの違いを扱う。

要点

• SLAは、サービス提供者と利用者の間でサービス内容や品質水準について合意し、文書化したものである。
• SLOは、SLAの中で稼働率や応答時間などの達成すべき具体的な数値目標として設定される品質水準の項目である。
• OLAは、サービス提供者内部の複数組織間で取り決める役割分担や対応時間などの合意で、利用者と交わすSLAを内部的に支える。
• クラウド事業者の標準的なSLAは事業者やプランによって異なるため、利用者は自社の要求水準に合うかを契約前に確認する必要がある。
• SLAの合意水準は、実績が合意した値と同じであれば満たしているとみなし、下回っていれば満たしていないと判断する。
• SLIは、稼働率や応答時間など、サービスの品質を実際に測定して得られる指標の値。

まちがえやすい点

• SLAは提供者と利用者の間の合意であり、サービス提供者内部で取り決めるOLAとは、合意の当事者が異なる。
• SLAは品質水準の合意文書であり、提案を依頼するRFP、作業を階層分解するWBS、役割分担を示すRACIチャートとは別である。
• SLAの補償は一般に利用料金の減額などで上限が設けられ、業務停止による損害額の全額を請求できるとは限らない。
• OLAは内部組織間の合意であり、利用者に対して示す品質目標であるSLOとは、合意の当事者や位置づけが異なる。

サービスレベル管理と稼働率の計算

SLAの達成状況を測り改善するSLM、水準の定め方と見直し、稼働率から許容停止時間を求める計算を扱う。

要点

• サービスレベルマネジメント（SLM）は、SLAで定めた品質水準の達成状況をモニタリング・レポーティング・レビューし、継続的な改善につなげる管理活動である。
• サービス水準は、稼働率や障害復旧までの時間など、測定できる指標で定める。
• 業務内容や利用状況が変われば必要な水準も変わるため、SLAは定期的に見直すことが前提となる。
• サービスレベル管理は、合意して終わりではなく、測って見直す活動までが一組になる。
• 稼働率が1桁変わるだけで許される停止時間は10倍変わるため、9がいくつ並ぶかを正確に読む必要がある。

まちがえやすい点

• SLAは合意した内容を記した文書そのものであり、達成状況を測って見直す活動であるSLMとは異なる。
• キャパシティマネジメントや可用性マネジメントは個別の管理活動でSLMの一要素にすぎず、SLM自体ではない。
• 停止時間の計算で、1%は432分、10%は4,320分に当たり、0.1%の43.2分とは割合の桁が異なる。

式

• 許容される停止時間期間（分）×（1−稼働率）30日間は43,200分。稼働率99.9%なら43,200×0.001＝43.2分

サービスマネジメントシステム

インシデント管理と問題管理

復旧を優先するインシデント管理と根本原因を除く問題管理の役割分担、優先度、既知の誤り、重大インシデントを扱う。

要点

• インシデント管理は、障害発生時に根本原因の追究より先に、応急処置で通常のサービス状態への復旧を優先するプロセスである。
• 問題管理は、インシデントの根本原因を調査・特定し、恒久的な対策によって再発防止を図るプロセスである。
• インシデントの優先度は、対応を急ぐ必要性を示す緊急度と、業務への影響の程度を示す影響度の2つの観点を組み合わせて決定する。
• 既知の誤りは、根本原因が特定され、回避策や恒久対策が文書化された問題であり、KEDBに蓄積される。
• 重大インシデントは、事業への影響が大きく、緊急かつ特別な体制での対処を要するインシデントである。
• インシデント管理の目的はサービスを早く元に戻すことであり、暫定的な回避策でも業務が続けられるなら優先される。
• 受付、優先度の判断、暫定的な回避策の適用はインシデント管理の中で行い、根本原因の分析と恒久対策は問題管理が担う。

まちがえやすい点

• インシデント管理は応急復旧が主目的で根本原因の解決までは踏み込まず、恒久対策を担う問題管理ではない。
• インシデントはサービスの中断や品質低下そのものを指し、原因の特定状況を示す既知の誤りとは意味が異なる。
• インシデント管理の第一の目的は早期のサービス復旧であり、根本原因を突き止めて再発を防ぐ問題管理とは別である。
• 重大インシデントは緊急対応を要する障害そのものであり、原因と回避策が判明した既知の誤りや、定型的な依頼であるサービス要求とは異なる。
• 変更管理は変更を計画的に承認・実施して混乱を防ぐ活動であり、復旧や原因究明を目的とするインシデント管理・問題管理ではない。

サービス要求管理・カタログ・ナレッジ管理

定型的な依頼を処理するサービス要求管理、サービスカタログ、対応記録を蓄積するナレッジ管理を扱う。

要点

• サービス要求管理は、パスワード再発行などの障害ではない定型的な依頼を受け付け、あらかじめ定めた手順に沿って処理するプロセスである。
• サービスカタログは、提供するITサービスの内容・提供条件・申込方法などを一覧化した文書で、利用者が申込み可能なサービスを把握する窓口になる。
• ナレッジ管理は、対応の知見や回避策・FAQを蓄積・共有し、問い合わせ対応の効率と品質を高める活動である。
• 対応の内容を記録に残すのは、同じ症状が再び起きたときに過去の対応を参照して復旧を速めるためで、問題管理の原因分析の材料にもなる。

まちがえやすい点

• サービス要求は障害ではない定型的な依頼であり、サービスの中断や品質低下を扱うインシデントとは性質が異なる。
• サービスカタログはサービスの一覧であり、個々のサービスの品質水準を合意して定めるSLAとは目的が異なる。
• 対応の記録の目的は復旧を速める知識の蓄積であり、人事評価や責任の回避とは別である。

変更管理の区分とCAB

標準変更・通常変更・緊急変更の区分、変更諮問委員会の役割、変更時に行う承認と切り戻し手順を扱う。

要点

• 標準変更は、リスクが低く手順が確立し、事前承認済みで、都度の承認が不要な定型的な変更である。
• 緊急変更は、重大インシデント対応など通常の承認を待てない状況で、簡略・迅速な手順で行う変更である。
• 通常変更は、変更諮問委員会（CAB）の評価を経て実施する変更である。
• 変更諮問委員会（CAB）は、変更要求の評価・優先順位付け・承認について変更管理責任者に助言する、関係者から構成される諮問組織である。
• 本番環境への変更は、影響範囲を評価して承認を得てから実施し、失敗に備えて切り戻し手順をあらかじめ用意する。
• 変更は軽微に見えても、記録が無いと障害発生時にいつ何を変えたかをたどれないため、変更の大小にかかわらず記録を残す。

まちがえやすい点

• 重大変更という定型的な変更区分は一般的には用いられず、標準変更・通常変更・緊急変更の区分とは異なる。
• 標準変更は事前承認済みの定型変更であり、通常の承認を待てない状況で簡略化された手順を使う緊急変更ではない。
• CABは変更の諮問組織であり、利用者窓口のサービスデスクや、構成情報の格納庫である構成管理データベースとは別である。

構成管理とIT資産管理

構成品目とCMDBによる構成情報の一元管理、IT資産管理のライフサイクルとライセンス遵守を扱う。

要点

• 構成管理データベース（CMDB）は、構成品目（CI）の属性情報や相互の関連を一元的に保持するデータベースで、影響範囲の把握に活用される。
• 構成品目（CI）は、構成管理の対象として個別に識別・管理されるハードウェア・ソフトウェア・文書などの要素である。
• IT資産管理（ITAM）は、IT資産の調達から廃棄までのライフサイクル全体を把握し、コストの最適化やライセンス遵守を確保する活動である。

まちがえやすい点

• 既知の誤りデータベース（KEDB）は既知の障害と回避策を蓄積するものであり、構成情報を保持するCMDBとは格納する情報の性質が異なる。
• 構成品目は管理対象の要素であり、サービスの中断などの障害事象そのものを指すインシデントとは概念が異なる。
• IT資産管理はライフサイクルの把握が目的であり、将来の需要に対する処理能力を確保するキャパシティ管理や、継続稼働を確保する可用性管理とは目的が異なる。

リリース・展開管理と本番反映の手法

リリース管理と展開の計画、サービスの妥当性確認、環境の分離、CI/CD、ブルーグリーン方式を扱う。

要点

• リリース管理は、新機能や修正版を本番環境へ計画的かつ統制された手順で展開する活動で、展開のタイミングや対象範囲、ロールバック手順を定めておく。
• リリース及び展開管理は、承認された変更をビルド・テストしたうえで本番環境へ計画的に展開する一連の活動を管理するプロセスである。
• サービスの妥当性確認及びテストは、新規・変更したサービスを本番へリリースする前に、実際の利用条件のもとで要求どおりに機能するかを確認する活動である。
• 開発環境と本番環境を分離すると、開発・テスト中の未完成なプログラムの変更や不具合が、稼働している業務システムやデータに影響を及ぼすことを防止できる。
• CI/CDパイプラインは、ソースコードの変更を契機に、ビルド・テスト・環境への展開までを自動化された一連の流れとして実行する仕組みである。
• ブルーグリーンデプロイメントは、新旧2環境を用意して切替でリリースし、障害時は旧環境へ即時に切り戻せるため、ダウンタイムとリスクを抑えられる。

まちがえやすい点

• リリース管理は展開そのものを統制する活動であり、成果物や資源の情報を正確に維持する構成管理とは役割が異なる。
• 変更管理は変更要求の承認可否を判断するプロセスであり、承認後の実際の展開作業を扱うリリース及び展開管理とは役割が異なる。
• ローリングアップデートは順次更新、ビッグバン移行は一斉切替、パイロット移行は一部から段階導入する方式で、二環境の切替で即時に切り戻すブルーグリーンとは別である。
• キャパシティ管理や需要管理は処理能力や需要の見通しに関する活動であり、リリース前の妥当性確認とは目的が異なる。

可用性・キャパシティ・需要・アクセスの管理

稼働継続能力を保つ可用性管理、資源計画のキャパシティ管理、需要管理、利用権限を管理するアクセス管理を扱う。

要点

• 可用性管理は、システムが求められる時間帯に継続して稼働できる能力を維持・向上させる活動で、稼働率の監視や冗長化などの対策を含む。
• キャパシティ管理は、将来の業務量の変化を見据えて処理能力や記憶容量が過不足なく確保されるよう、現状監視と資源計画を行う活動である。
• 需要管理は、利用者側のサービス利用パターンやピーク時の需要を把握・予測し、キャパシティ管理と連携して資源配分を適切化する活動である。
• アクセス管理は、認可された利用者だけが資源を使えるよう利用権限の付与・変更・削除を管理し、認可されていない者の利用を防ぐ活動である。
• サービス可用性管理は、合意した稼働率や利用可能時間の目標を満たせるよう、稼働状況を監視し、障害の再発防止などに取り組む活動。

まちがえやすい点

• 可用性管理は稼働継続能力の維持に主眼を置く活動であり、処理能力や記憶容量の確保を扱うキャパシティ管理とは異なる。
• 財務管理はITサービスに関する予算やコストの管理を扱う活動であり、需要の把握・予測を主眼とする需要管理とは対象が異なる。
• アクセス管理は利用権限の付与・制御を扱い、構成品目の情報を扱う構成管理や、変更の統制を扱う変更管理ではない。

事業継続計画とRTO・RPO

BCPとBCMの違い、ITサービス継続管理、復旧時間の目標RTOと復旧時点の目標RPOの区別を扱う。

要点

• RTO（目標復旧時間）は、災害や障害の発生から業務・システムを復旧させるまでに許容される目標時間を表す指標である。
• RPO（目標復旧時点）は、障害発生時にどの時点までのデータを復旧させるかを示す目標値で、値が小さいほどデータ損失の許容範囲が小さい。
• 事業継続計画（BCP）は、緊急事態でも重要な事業を中断させない、または目標時間内に復旧させるために、あらかじめ策定する行動計画である。
• BCMは、BCPの策定・運用・訓練・見直しを継続的に回す、事業継続の管理活動全体を指す。
• BCPは、重要業務を絞り込んだうえで目標復旧時間と目標復旧水準を定め、訓練によって実効性を確かめておくものである。
• ITサービス継続管理は、災害などの重大な事象でもITサービスを継続提供できるよう、リスク評価や復旧手順・代替手段の計画・整備を行う活動である。

まちがえやすい点

• RTOは復旧までの許容時間を示し、データの復旧時点を示すRPOや、復旧後の業務レベルを示すRLOとは着目する観点が異なる。
• BCPは計画の策定を指し、策定後の教育・訓練・定期的な見直しまで継続的に運用する管理活動であるBCMではない。
• ITサービス継続管理は大規模災害を想定する点で、通常運用における稼働継続性の維持向上を目的とする可用性管理とは、対象とするリスクの規模が異なる。
• BCPは非常時に重要業務を優先して復旧させる計画であり、すべての業務を同時に平常水準へ戻すことを前提とするものとは異なる。
• BCPは緊急時の事業継続が目的であり、平常時のサービス品質を取り決めるサービスレベル合意書とは性格が異なる。

ディザスタリカバリと代替サイト

遠隔地に代替環境を置くディザスタリカバリと、ホット・ウォーム・コールドサイトの違いを扱う。

要点

• ディザスタリカバリ（DR）は、被災に備えて遠隔地に代替システム環境を用意し、被災時に業務システムを早期に復旧させるための対策・仕組み全般を指す。
• ホットサイトは、本番環境とほぼ同等のシステムを常時稼働させた状態で待機させる形態で、短時間で切り替えられるが維持コストが高い。
• コールドサイトは、設備や回線のみを用意し、機器の設置やデータ復元を被災後に行う形態で、切替えに時間を要するが平常時の維持コストが最も低い。
• ウォームサイトは、機器をあらかじめ設置してデータを定期的にバックアップし、被災時に最新データを復元して再開する、ホットサイトとコールドサイトの中間的な形態である。

まちがえやすい点

• フェールオーバーは同一拠点内などで障害時に予備系へ自動的に切り替える仕組みを指すことが多く、遠隔地での災害対策を主眼とするDRとは想定する被害の規模が異なる。
• ミラーサイトは常時同期で平常時の維持コストが高く、維持コストが最も低いコールドサイトとは異なる。
• ウォームサイトは中間的な形態であり、常時稼働で即切替えのホットサイトや、設備のみのコールドサイトとは別である。

サービスデスクの形態とエスカレーション

問い合わせの単一窓口であるサービスデスク、中央・バーチャルの形態、エスカレーション、記録とFAQを扱う。

要点

• サービスデスクは、利用者からの問い合わせや障害報告を一元的に受け付ける単一の窓口（SPOC）として機能し、インシデント管理プロセスの起点となる。
• 中央サービスデスクは、複数拠点の窓口機能を1か所に集約して一元的に受け付ける形態で、対応品質の統一や運用コストの効率化が図りやすい。
• バーチャルサービスデスクは、担当者が分散していても通信技術で利用者からは単一の窓口のように応対する形態である。
• エスカレーションは、一次対応で解決できない問い合わせを、より専門的な知識を持つ二次対応の担当者や権限を持つ上位者へ引き継ぐ対応である。
• エスカレーションは、技術的な難易度で引き継ぐ機能的エスカレーションと、権限の必要性で引き継ぐ階層的エスカレーションに分けられることがある。
• サービスデスクは、問合せの窓口を一元化して対応状況を追跡できるようにし、記録を蓄積してFAQに育てることで、対応の質と速さを安定させる。
• SPOCは、利用者からの問合せや要求の受付窓口を一つに集約し、連絡先に迷わないようにする考え方。
• AIOpsは、AIや機械学習を活用し、システム運用での異常検知や原因分析などを自動化・効率化する取組。

まちがえやすい点

• ローカルサービスデスクは拠点ごとの設置、中央は1か所に集約、フォロー・ザ・サンは時差を利用して拠点を引き継ぐ方式で、バーチャルとは異なる。
• ロールバックは変更を実施前の状態に戻す操作であり、対応の引き継ぎであるエスカレーションではない。
• サービスデスクは利用者対応の単一窓口であり、変更の承認判断を行うCABや、根本原因の調査を担う問題管理チームとは別である。
• 記録を残さない個別対応は、記録を蓄積して追跡できる対応とは異なり、担当者が不在のときに引き継げず改善につながらない。

ファシリティマネジメント

電源・耐震設備とグリーンIT

UPSと自家発電装置の役割分担、免震構造と耐震・制振構造の違い、環境負荷を下げるグリーンITを扱う。

要点

• UPS（無停電電源装置）は、停電や電圧異常を検知した際に一定時間電力供給を継続し、システムを安全にシャットダウンする時間を確保する機器である。
• 自家発電装置は、UPSがカバーできる時間を超える長時間の停電に、燃料で電力を供給し続ける設備である。
• 免震構造は、建物の基礎と本体の間に免震装置を設けて、地震の揺れが建物本体に伝わりにくくする構造である。
• グリーンITは、サーバの仮想化や省電力機器の導入、空調効率化などを通じて、運用に伴う消費電力や環境負荷を低減しようとする取組みである。
• サージ防護は、落雷などで電源線や通信線に流れ込む瞬間的な過電圧から、機器を保護するための対策。

まちがえやすい点

• UPSは短時間の停電や電圧異常への一時対応を担い、長時間の給電継続に向く自家発電装置とは役割が異なる。
• 耐震構造は建物の強度を高めて倒壊を防ぎ、制振構造はダンパー等で揺れを吸収する構造であり、免震構造とは地震対策のアプローチが異なる。
• シャドーITは組織の管理外で利用者が独自に導入するIT機器やサービスを指し、環境負荷の低減を目的とするグリーンITではない。

情報資産の物理的保護

クリアデスク・クリアスクリーン、入退室管理、記録媒体の廃棄時のデータ消去など物理的な保護策を扱う。

要点

• クリアデスク・クリアスクリーンは、離席時に書類を机上に放置せず施錠保管し、画面をロックして、情報の盗み見や持ち出しを防ぐ考え方である。
• 記録媒体を廃棄する際は、専用の消去ソフトウェアによる上書き消去や物理的な破砕など、復元が事実上不可能な方法でデータを消去する。
• 入退室管理は、入退室を記録し、許可された人だけが入れるよう認証装置で制限する、物理的なセキュリティの対策である。

まちがえやすい点

• クイックフォーマットやパーティションの削除、ファイルの移動は管理情報を書き換えるだけで、データの実体が記録媒体上に残るため、完全消去や物理的な破壊とは異なり十分な対策ではない。
• クリアデスク・クリアスクリーンは机上・画面の管理を指し、部屋への出入りを記録する入退室管理や、接続記録を監視するアクセスログ管理とは別である。
• 空調を止めて扉を開放する運用は、設備の可用性と物理セキュリティの両方を損なう点で、入退室管理による保護とは異なる。

ほかのページ

出典と作り方

この読み物は、IPA「ITパスポート試験 シラバス Ver.6.5」の中分類の順に、アプリ「ITウカール」の収録問題の解説をもとにアプリ製薬が作成したものです。公式の文章の転載ではありません。問題文・選択肢は載せていません。

• ITパスポート試験 シラバス Ver.6.5（IPA）