ITパスポート試験 用語辞典
(Wikipedia サービスサポートより)
サービスサポート（Service Support）あるいはサービスサポートプロセスはITILを構成するプロセスのひとつ。通称『青本』と呼ばれ、主にITサービス運営における日々の運用の手法について記されている。
概要
サービスサポートは5つのプロセスと1つの機能で構成され、それぞれのプロセスごとに異なる役割と責任を持たせている。プロセスとして「インシデント管理」、「問題管理」、「構成管理」、「変更管理」、「リリース管理」、ファンクションとして「サービスデスク」とそれぞれ名称定義されている。また、ITILをベースとしたITサービスマネジメントにおける規格（ISO/IEC 20000）ではインシデント管理と問題管理を「解決プロセス群」、構成管理と変更管理を「コントロールプロセス群」、リリース管理を「リリースプロセス群」と分類している。
管理プロセス詳細
インシデント管理
「インシデント」とは提供するITサービスの中断（事故）を意味し、インシデント管理プロセスではその名の通り発生したインシデントに対して、インシデントの発生から対策、解決（クローズ）までの一連の流れを管理し、コントロールを行う。ただし、ITILは従来の運用で行われてきた管理と異なり、暫定対応と恒久対応を明確に分離し、インシデント管理では暫定対応のみを対象として管理し、恒久対応に関しては問題管理プロセスにて管理を行う。
インシデント管理の目的はあくまで業務復旧であり、業務への影響を最小限に抑える事を第一として考える。この目的を達成させる為に、インシデント管理では以下の達成目標を掲げている。
- 可能な限り迅速に平常時のサービスを提供できる状態にすること
- ビジネス業務への悪影響を最小限にとどめること
- SLAに則ったサービスレベルを維持すること
インシデント管理では上記達成目標に則った緊急度とインパクト評価における事由の優先順位を以下のように定義し、それぞれの解決目標時間を示している。
問題管理
問題管理でいう「問題」は、管理する側が意図的に認め、識別する事ではじめて発生する。例えばサーバの障害などにおいて、ある症状のインシデントを繰り返す、という事象が発生した場合、個々の暫定的な対応としてはプロセスの再起動などで可能であっても、根本的な解決には至っていない。臨時復旧によるサービスの中断は防ぐ事が出来ても、中長期的な観点で見ると、根本的な対策を行わない限り復旧作業などのコストが嵩み、大きな損失として計上されてしまう。
問題管理はインシデントに対しての問題点を認め、識別し、原因の調査と恒久的な対策を実施していき、インシデントの再発防止に努めるITサービスの品質を高めていく為のプロセスである。ただし、ITILでの問題管理の範疇としては問題点の解決策の提示までであり、それ以降の実際の対策実施の為の変更作業などは変更管理プロセスにてコントロールされる。
上述の通り、問題管理の目的は恒久対策であり、目的達成の為、以下の達成目標を掲げている。
- エラーに基づくインシデントの再発防止
- 資産利用の生産性向上
- 予防的な問題管理の実施
問題の発生から収束までを問題コントロールと呼び、特に問題の切り分け後から変更管理を経て解決に向かうまでのプロセスをエラー・コントロールと呼ぶ。問題管理では発生から収束まで大きく9つのプロセスに分けて管理・コントロールを行う事が推奨されている。
構成管理
サービスを提供する為の情報システムは、ライフサイクルの中で大なり小なり様々な変更が発生する。サービス開始時からその構成情報が一切変わる事無く、サービスの提供終了まで、あるいは情報システムの更改まで保たれるという事はまずありえない事である。
構成管理では実在する全ての構成アイテムを明確にしたITインフラストラクチャとサービスの論理モデルを提供する事で効率的なサービスを提供する為の情報の維持管理を行う事を目的として以下の目標を掲げている。
- すべてのIT資産の明確化
- 構成管理で管理する情報を他のプロセスへ提供する
- ITインフラストラクチャと構成記録の整合性検証を行う
変更管理
システムの持つリスクのひとつに「変更作業によるインシデントの発生」がある。既存システムになんらかの変更を行う場合、人為ミスによるインシデントの発生のみならず潜在的なエラーの表面化なども発生しうる可能性がある。変更管理ではこれら変更作業にともなうリスクを管理し、リスクとメリットを勘案して変更作業案件の管理とリリース管理プロセスへ引き継ぐかどうかの評価を行うプロセスである。
変更管理では既存ITサービスへの変更及び新規サービスの導入を効率的かつ安全に実施することを目的として以下の目標を掲げている。
- すべての変更作業に標準化した手法を適用する
- 効率的で迅速な変更処理の促進と評価を行う
- 変更作業のメリットとデメリットを明確化する
リリース管理
リリース管理は変更管理プロセスで承認された変更作業について、実際のサービス提供媒体へ変更作業を行うプロセスである。変更管理との綿密な連携が求められ、ITサービスへの変更作業を包括的に把握した上でリリース作業に対して技術面/非技術面の両方からの保障を行い、リリースの構築と実装を成功させる事を目的とし、以下の目標が掲げられる。
- 変更管理と連携した投入計画の調整と実施
- リリース計画と投入計画についての顧客とのコミュニケーションを行う
- リリースの設計から導入までの一貫したコントロール
リリースにはシステムの新規構築・更改（フルリリース）とソフトウェアのバージョンアップなどの部分的な変更作業（デルタリリースまたはパッケージリリース）があり、変更作業案件によって対策を行う規模やリソース量も異なる為、それぞれのリリース作業にあった計画の立案が必要となってくる。
サービスデスク
サービスデスクはサービスサポートを構成する唯一の機能組織であり、実態をもつものとして活動する。サービスデスクは利用顧客に対しての単一の窓口を提供し、様々な問い合わせを受け付け、その記録を一元管理すると共に問題解決を行う適切な部隊・あるいはプロセスへのエスカレーションを担当する。ITILではサービスデスクの機能のひとつである「単一窓口」をSPOC（Single Point Of Contact）と呼ぶ。
サービスデスクは利用顧客とITサービス提供者間の橋渡し的な役割を持ち、事業への影響度の軽減、通常のサービスへの復帰の支援を目的として以下の目標を掲げている。
- 単一窓口としてあらゆる問い合わせを受け付け、登録する
- インシデント対応によるエスカレーションを行い、問題解決までの状況を記録/管理する
出題例
- SLAで定められた時間内で解決できないインシデントは，問題管理へ引き継ぐ。
- インシデン卜の再発防止のための対策を実施する。
- インシデントの原因追究よりも正常なサービス運用の回復を優先させる。
- 解決方法が分かっているインシデントの発生は記録する必要はない。
正解
このページのWikipediaよりの記事は、ウィキペディアの「サービスサポート」(改訂履歴)の記事を複製、再配布したものにあたり、このページ内の該当部分はクリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下 に提供されています。