サービスサポート

リンクを追加
出典: フリー百科事典『ウィキペディア（Wikipedia）』

サービスサポート（英:Service Support）あるいはサービスサポートプロセスはITILを構成するプロセスのひとつ。通称『青本』と呼ばれ、主にITサービス運営における日々の運用の手法について記されている。

概要[編集]

サービスサポートは5つのプロセスと1つの機能で構成され、それぞれのプロセスごとに異なる役割と責任を持たせている。プロセスとして「インシデント管理」、「問題管理」、「構成管理」、「変更管理」、「リリース管理」、ファンクションとして「サービスデスク」とそれぞれ名称定義されている。また、ITILをベースとしたITサービスマネジメントにおける規格（ISO/IEC 20000）ではインシデント管理と問題管理を「解決プロセス群」、構成管理と変更管理を「コントロールプロセス群」、リリース管理を「リリースプロセス群」と分類している。

プロセス プロセス群 概要
インシデント管理 解決プロセス群 迅速なサービスの復旧を行い、企業が行う事業活動への影響を最小限に抑える事を目的としたプロセス。
問題管理 解決プロセス群 インシデントや障害原因の追及と対策および再発防止策の策定を目的としたプロセス。
構成管理 コントロールプロセス群 ITサービスの構成アイテム（CI）情報の正確な収集、認識と収集した情報の維持管理および確認・監査を目的としたプロセス。
変更管理 コントロールプロセス群 CI情報の変更を安全確実かつ効率的に実施する事を目的としたプロセス。
リリース管理 リリースプロセス群 変更管理プロセスで承認された内容を本番環境（ITサービス提供媒体）に正しく反映させる為の作業（リリース作業）をコントロールする事を目的としたプロセス。
サービスデスク 機能組織 ITサービスを提供する組織とITサービスを利用する顧客の窓口的役割を担い、インシデント対応などのサポート業務を行う事を目的とした機能。

管理プロセス詳細[編集]

インシデント管理[編集]

「インシデント」とは提供するITサービスの中断（事故）を意味し、インシデント管理プロセスではその名の通り発生したインシデントに対して、インシデントの発生から対策、解決（クローズ）までの一連の流れを管理し、コントロールを行う。ただし、ITILは従来の運用で行われてきた管理と異なり、暫定対応と恒久対応を明確に分離し、インシデント管理では暫定対応のみを対象として管理し、恒久対応に関しては問題管理プロセスにて管理を行う。

インシデント管理の目的はあくまで業務復旧であり、業務への影響を最小限に抑える事を第一として考える。この目的を達成させる為に、インシデント管理では以下の達成目標を掲げている。

  • 可能な限り迅速に平常時のサービスを提供できる状態にすること
  • ビジネス業務への悪影響を最小限にとどめること
  • SLAに則ったサービスレベルを維持すること

インシデント管理では上記達成目標に則った緊急度とインパクト評価における事由の優先順位を以下のように定義し、それぞれの解決目標時間を示している。

/ 高 中 低
高 1時間以内 8時間以内 24時間以内
中 8時間以内 24時間以内 48時間以内
低 24時間以内 48時間以内 計画目標

問題管理[編集]

問題管理でいう「問題」は、管理する側が意図的に認め、識別する事ではじめて発生する。例えばサーバの障害などにおいて、ある症状のインシデントを繰り返す、という事象が発生した場合、個々の暫定的な対応としてはプロセスの再起動などで可能であっても、根本的な解決には至っていない。臨時復旧によるサービスの中断は防ぐ事が出来ても、中長期的な観点で見ると、根本的な対策を行わない限り復旧作業などのコストが嵩み、大きな損失として計上されてしまう。

問題管理はインシデントに対しての問題点を認め、識別し、原因の調査と恒久的な対策を実施していき、インシデントの再発防止に努めるITサービスの品質を高めていく為のプロセスである。ただし、ITILでの問題管理の範疇としては問題点の解決策の提示までであり、それ以降の実際の対策実施の為の変更作業などは変更管理プロセスにてコントロールされる。

上述の通り、問題管理の目的は恒久対策であり、目的達成の為、以下の達成目標を掲げている。

  • エラーに基づくインシデントの再発防止
  • 資産利用の生産性向上
  • 予防的な問題管理の実施

問題の発生から収束までを問題コントロールと呼び、特に問題の切り分け後から変更管理を経て解決に向かうまでのプロセスをエラー・コントロールと呼ぶ。問題管理では発生から収束まで大きく9つのプロセスに分けて管理・コントロールを行う事が推奨されている。

No プロセス内容 概要
1 問題の識別と記録 インシデントレコードを元に問題レコードを起票する。
2 問題の分類 問題を分類し、カテゴリ、緊急度、影響度、優先度を設定する。
3 問題の調査と診断 問題分析手法[1]を用いて問題発生となった原因の調査を行う。
4 エラーの識別と記録 発生していたエラーを識別し、KEDB[2]に記録する。
5 エラーの評価 エラー内容を調査し、恒久的な解決策を検討・立案する。
6 エラーの解決策を記録 現象の発生する条件などとともに解決策をKEDBに記録する。
7 変更要求（RFC） エラー対策の為、変更管理プロセスにシステム変更の要求を行う。
8 問題解決の進捗監視 変更管理プロセスを経た解決策に対し、リリース管理プロセスが行う実際の変更作業を監視する。
9 問題のクローズ リリース管理プロセスを経た解決策をレビューし、問題をクローズする。

構成管理[編集]

詳細は「構成管理」を参照

サービスを提供する為の情報システムは、製品ライフサイクルの中で大なり小なり様々な変更が発生する。サービス開始時からその構成情報が一切変わる事無く、サービスの提供終了まで、あるいは情報システムの更改まで保たれるという事はまずありえない事である。

構成管理では実在する全ての構成アイテムを明確にしたITインフラストラクチャとサービスの論理モデルを提供する事で効率的なサービスを提供する為の情報の維持管理を行う事を目的として以下の目標を掲げている。

  • すべてのIT資産の明確化
  • 構成管理で管理する情報を他のプロセスへ提供する
  • ITインフラストラクチャと構成記録の整合性検証を行う

変更管理[編集]

詳細は「変更管理 (ITシステム)」を参照

システムの持つリスクのひとつに「変更作業によるインシデントの発生」がある。既存システムになんらかの変更[3]を行う場合、人為ミスによるインシデントの発生のみならず潜在的なエラーの表面化なども発生しうる可能性がある。変更管理ではこれら変更作業にともなうリスクを管理し、リスクとメリットを勘案して変更作業案件の管理とリリース管理プロセスへ引き継ぐかどうかの評価を行うプロセスである。

変更管理では既存ITサービスへの変更及び新規サービスの導入を効率的かつ安全に実施することを目的として以下の目標を掲げている。

  • すべての変更作業に標準化した手法を適用する
  • 効率的で迅速な変更処理の促進と評価を行う
  • 変更作業のメリットとデメリットを明確化する

リリース管理[編集]

詳細は「リリース管理」を参照

リリース管理は変更管理プロセスで承認された変更作業について、実際のサービス提供媒体へ変更作業を行うプロセスである。変更管理との綿密な連携が求められ、ITサービスへの変更作業を包括的に把握した上でリリース作業に対して技術面/非技術面の両方からの保障を行い、リリースの構築と実装を成功させる事を目的とし、以下の目標が掲げられる。

  • 変更管理と連携した投入計画の調整と実施
  • リリース計画と投入計画についての顧客とのコミュニケーションを行う
  • リリースの設計から導入までの一貫したコントロール

リリースにはシステムの新規構築・更改（フルリリース）とソフトウェアのバージョンアップなどの部分的な変更作業（デルタリリースまたはパッケージリリース）があり、変更作業案件によって対策を行う規模やリソース量も異なる為、それぞれのリリース作業にあった計画の立案が必要となってくる。

サービスデスク[編集]

詳細は「サービスデスク」を参照

サービスデスクはサービスサポートを構成する唯一の機能組織であり、実態をもつものとして活動する。サービスデスクは利用顧客に対しての単一の窓口を提供し、様々な問い合わせを受け付け、その記録を一元管理すると共に問題解決を行う適切な部隊・あるいはプロセスへのエスカレーションを担当する。ITILではサービスデスクの機能のひとつである「単一窓口」をSPOC（Single Point Of Contact）と呼ぶ。

サービスデスクは利用顧客とITサービス提供者間の橋渡し的な役割を持ち、事業への影響度の軽減、通常のサービスへの復帰の支援を目的として以下の目標を掲げている。

  • 単一窓口としてあらゆる問い合わせを受け付け、登録する
  • インシデント対応によるエスカレーションを行い、問題解決までの状況を記録/管理する

主なツール[編集]

様々なベンダーが各種ツールを提供している。下記は2020年5月現在の主要ベンダーの一覧である。


モニタリングツール（アプリやインフラ、データベースなどの監視ツール）

  • DataDog
  • New Relic
  • Amazon CloudWatch
  • Dynatrace
  • CA UNIM (Nimsoft)
  • Cisco Meraki Alerts Dashboard
  • Google StackDriver
  • IBM Cloud
  • Microsoft Azure Alerts
  • Logz-io
  • Moogsoft
  • SignalFx
  • Zabbix Webhook

APIマネジメント

  • API Fortress connector
  • AppView X
  • Cisco Webex Teams
  • Oracle Developer Cloud Service

ITサービスマネジメント

  • Atlassian JIRA Cloud
  • BMC Remedy
  • ServiceNow
  • Microsoft SCOM

チャットコラボレーション

ログマネジメント

  • Elastic
  • Logz-io
  • Splunk
  • Sumo Logic
  • LogTrust

オンコール ツール（担当者の呼び出し）


脚注[編集]

  1. ^ 代表的な問題分析手法として石川ダイアグラムなどがITILで紹介されている。
  2. ^ KnownErrorDatabaseの略で既知のエラー情報を蓄積したデータベース。マイクロソフト、IBMなどの製品ベンダーでは積極的に公開している。
  3. ^ 保守作業や追加モジュールの導入、障害対策パッチの導入など。

関連項目[編集]

参考文献[編集]

  • 『強い会社はこうして作られる! ITIL実践の鉄則』- 久納信之（2007/6,ISBN 4774131253）
  • 『ITIL教科書』- 青柳雅之、北尾一彦、木村祐、吉田俊雄（2006/8,ISBN 9784872685664）
  • 『会社を守るITIL -経営者・ビジネスマネージャーのためのIT活用術-』- 久納信之、加藤寛二、吉田俊雄（2006/3,ISBN 487268530X）
  • 『ITIL導入のためのBS15000/ISO20000入門』- 尾崎雅彦（2006/1,ISBN 9784797332940）
  • 『ITIL大全』- 日経コンピュータ編（2004/12,ISBN 4822207943）
「https://ja.wikipedia.org/w/index.php?title=サービスサポート&oldid=81961394」から取得