サービスサポート

**サービスサポート**（英: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サービス提供者間の橋渡し的な役割を持ち、事業への影響度の軽減、通常のサービスへの復帰の支援を目的として以下の目標を掲げている。
*単一窓口としてあらゆる問い合わせを受け付け、登録する
*インシデント対応によるエスカレーションを行い、問題解決までの状況を記録/管理する

### 主なツール
様々なベンダーが各種ツールを提供している。下記は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

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

* HipChat Extension
* Slack
* Microsoft Teams
* Zapier

ログマネジメント

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

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

* PagerDuty 
* VictorOps
* OpsGenie


## 脚注


## 関連項目
*Information Technology Infrastructure Library（ITIL）
*サービスデリバリ
*サービスデスク
***インシデント管理**
***問題管理**
*変更管理
*リリース管理
*構成管理

## 参考文献
* 『強い会社はこうして作られる! 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）