[情報セキュリティマネジメント試験]サービスマネジメント[無料講座・例題付き!]

2021年5月28日

セキュリティ

今回は情報セキュリティマネジメント試験における、サービスマネジメントについて学習します。

くろん
くろん
ようやく依頼されてたシステムを納品できたにゃ!これでミッションコンプリートだにゃ!
モナ
モナ
お客さんと良い関係を続けたいなら、その後もしっかりサービスマネジメントすることが大事だニャ

サービスマネジメント

サービスマネジメントは顧客の要求を満たすサービスを提供するため、サービスの提供者の活動を管理することです。

情報システムでは「開発して納品すればお終い」ではなく、その後の運用に関してもサポートする必要があります。

また、トラブルが起きた場合の対応方法も定めておき、万が一の際に迅速かつ的確に対応できる取り組みが必要です。

サービスマネジメントの概要

サービスマネジメントの概要や重要語句について押さえていきましょう。

ITIL

ITIL(Information Technology Infrastructure Library)は、システムを安定的かつ効率的に運用する攻略本です。

英国政府が策定したデファクトスタンダードとなっています。

キュー
キュー
デファクトスタンダードは前も出てきたけど、事実上の標準の事やな

サービスマネジメントにおいては完璧を目指すとかえって費用や時間がかかることから、目標保証型と努力目標型に区分けし、どこまで許容するかといったラインを予め決めておきます。

ITILでは当事者間でのサービスレベルを策定しており、その対象者に応じてSLAとOLAがあります。

SLA

SLA(Service Level Agreement)は、サービスの提供者と利用者の間で結ばれる合意書です。

OLA

OLA(Operational Level Agreement)はサービスの提供者同士で結ばれる合意文章です。

顧客からのインシデントを受付するサービスデスクと、そのインシデントを解決するためにサービスデスクを支援する社内の別の部署との間で結ばれます。

サービスマネジメントプロセス

サービスマネジメントプロセスはITILを実践するための活動です。

よく出題されるサービスマネジメントプロセスと、インシデントに対応した例は以下の通りです。

プロセス 説明
インシデント管理 発生したインシデントを、通常のサービスへ復旧させるプロセス。 サーバが停止した際に原因究明を後回しにし、再起動をさせる。
問題管理 インシデントの根本原因を突き止め、解決策や再発防止策を実施するプロセス。 サーバが停止した根本原因を究明し、対策をする。
構成管理 現状を把握するため、情報機器やソフトウェア・関連資料を格納したデータベースを参照・更新するプロセス。 サーバの仕様や構造を把握し、過去のインシデントを参考にしたうえで修理の下準備をする。
変更管理 変更要求に関して、変更に伴う影響を調査したうえで変更するかどうか検討するプロセス。 サーバを修理した場合の影響を検討する。
可用性管理 SLAの目標を達成するため、インシデントが発生しないように継続的に可用性を高めるプロセス。 定期的にサーバのメンテナンスや点検を行う。
キャパシティ管理 システム障害を防ぐため、将来必要となるシステム資源のキャパシティの状況を監視・分析・予測するプロセス。 サーバの老朽化対策やへたり具合の監視を行う。
サービスレベル管理 SLAで合意された業務要件 上記までの活動を継続的に行う。

問題管理とインシデント管理の違い

問題管理とインシデント管理の違いは次の通りです。

  • 問題管理・・・インシデントの根本原因を突き止め、インシデントそのものを取り除くことを目的としています。
  • インシデント管理・・・発生したインシデントをとりあえず抑えることを目的とします。
キュー
キュー
問題管理は火災で言えば防火対策、インシデント管理は消火活動って感じやな

可用性管理

  • RTO(Recovery Time Objective)・・・インシデント発生後に、どのくらいの時間でシステムを復旧させるかの目標時間。値が小さいほど時間が短く優れている。
  • RPO(Recovery Point Objective)・・・インシデント発生時に、どのくらい前までさかのぼったデータを使ってシステムを復旧させるかの目標時間。値が小さいほど時間が短く優れている。

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

ファシリティマネジメントは企業・役所・設備を維持保全するための取り組みや仕組みです。

例としては

  • 盗難防止のためにセキュリティワイヤを敷く
  • 停電による被害を防ぐための無停電電源装置(UPS)を用意する

などが挙げられます。

サービスデスク

サービスデスクはサービスの利用者からの問い合わせに対して、単一の窓口機能を提供し担当部署への引継ぎや対応結果の記録、記録管理などを行う部署です。

具体的なサービスデスクの形態は以下の通りです。

  • ローカルサービスデスク・・・拠点ごとにサービスデスクを設置する形態です。利用者の近くにサービスデスクがあるため、担当者が直接出向きやすく拠点ごとの言語や文化に合わせて対応しやすくなっています。
  • 中央サービスデスク・・・複数の拠点を統括し、1拠点にサービスデスクを設置する形態です。集中的に問い合わせを受け付けるため、サービス要員を効率的に配置したり、大量の問い合わせに対応したりできます。
  • バーチャルサービスデスク・・・実際には複数拠点に存在しているものの、ITを活用してあたかも1拠点にサービスデスクを設置しているように見える形態です。
  • フォロー・ザ・サン・・・24時間体制を構築するため、地理的に分散し時差がある複数拠点を組み合わせる形態です。全拠点を中央統括管理する方式の為、ある拠点でその日のうちに対応できなかった問い合わせを、時差のある別の拠点で引き継いで対応するなど、統制の取れたサービスを提供できます。
スポンサーリンク

サービスマネジメント・例題

実際に例題を解いて問題に慣れていきましょう。

問題

問1

ディザスタリカバリを計画する際の検討項目の一つであるRPO(Recovery Point Objective)はどれか。(H.29/春)

ア 業務の継続性を維持するために必要な人員計画と交代要員の要求スキルを示す指標
イ 災害発生時からどのくらいの時間以内にシステムを再稼働しなければならないかを示す指標
ウ 災害発生時に業務を代替する遠隔地のシステム環境と,通常稼働しているシステム環境との設備投資の比率を示す指標
エ システムが再稼働したときに,災害発生前のどの時点の状態までデータを復旧しなければならないかを示す指標

問2

ITサービスマネジメントにおける運用レベル合意書(OLA)の説明はどれか。(H.29/春)

ア サービス提供者と供給者との間で取り交わした合意文書であり,サービス及びサービス目標を定義した文書である。
イ サービス提供者と顧客との間で取り交わした合意文書であり,サービス及びサービス目標を定義した文書である。
ウ サービス提供者と内部グループとの間で取り交わした合意文書であり,サービス及びサービス目標を定義した文書である。
エ サービス内容を顧客に提示するための文書であり,提供する全てのサービスの種類や構成を定義した文書である。

問3

ITサービスマネジメントにおける問題管理プロセスの目的はどれか。(H.29/春)

ア インシデントの解決を,合意したサービス目標及び時間枠内に達成することを確実にする。
イ インシデントの未知の根本原因を特定し,恒久的な解決策を提案したり,インシデントの発生を事前予防的に防止したりする。
ウ 合意した目標の中で,合意したサービス継続及び可用性のコミットメントを果たすことを確実にする。
エ 全ての変更を制御された方法でアセスメントし,承認し,実施し,レビューすることを確実にする。

解説(クリックで展開)

サービスマネジメント・まとめ

今回はサービスマネジメントについて学習しました。

SLAやOLA、サービスマネジメントプロセスの各プロセスについて押さえておきましょう。

カズ
カズ
範囲は狭いけど頻出だよ!

次回はシステム監査について学習します。


スポンサーリンク