サービスマネジメント - 15.サービスマネジメント - 3.サービスマネジメントプロセス - 9.インシデント及びサービス要求管理
インシデントとは、提供するITサービスの中断（事故・障害）または、ユーザーからのサービス要求を意味し、その発生や対応によりITサービスの品質を低下または阻害させる要因になる。
インシデント管理プロセスではその名の通り発生したインシデントに対して、インシデントの発生から対策、解決（クローズ）までの一連の流れをサービスデスクで管理し、コントロールを行う。ただし、ITILは従来の運用で行われてきた管理と異なり、暫定対応と恒久対応を明確に分離し、インシデント管理では暫定対応のみを対象として管理し、恒久対応に関しては問題管理プロセスにて管理を行う。
インシデント管理の目的はあくまで業務復旧であり、業務への影響を最小限に抑える事を第一として考える。この目的を達成させる為に、インシデント管理では以下の達成目標を掲げている。
- 可能な限り迅速に平常時のサービスを提供できる状態にすること
- ビジネス業務への悪影響を最小限にとどめること
- SLAに則ったサービスレベル(標準的なサービス)を維持すること
| プロセス内容 | 概要 | |
| 1 | インシデントの識別と記録 | サポートデスクの連絡を元にインシデントレコードを起票する。インシデントの対応に必要な情報を収集・整理する。 |
| 2 | インシデントの分類 | インシデントを分類し、カテゴリ、緊急度、影響度、優先度を設定し、初期サポートを行う。 |
| 3 | インシデントの調査と診断 | 初期サポートで解決できないインシデントをエスカレーションし、専門家による高度な分析を行う。 |
| 4 | インシデントの解決と復旧 | 専門家が提示した解決策を実行し、復旧する。 |
| 9 | インシデントのクローズ | 利用者が満足すれば、解決済みとし、インシデントをクローズする。 |
インシデント管理では上記達成目標に則り、緊急度とインパクトで優先順位を客観的に決定し、優先度に従い、処理していく。緊急度が高く、インパクトも大きいほど優先度が高い。
【 緊急度 】
インシデントの未対応を容認できる時間で、その時間が短いほど緊急度が高い。
【 インパクト 】
インシデントが業務や組織に与える影響度のこと。
【 ワークアラウンド（応急処置） 】(Workaround)
インシデントが発生した際、根本的な解決策または完全な解決策がまだ存在しないかすぐに実行できない場合に、応急的に問題を回避したり悪影響を低減したりする措置のこと。。
【 サービス要求 】
システムに関する質問や不定期のバッチ処理の依頼、データ抽出依頼や情報提供の依頼などのこと。
- 標準的なサービス
SLAで定められ、手順などが明確に定められたサービス - 標準的な変更
ユーザIDの作成、パスワードの変更、パソコンの設置など手順が明確に定義された日常的に行われる変更作業
インシデントの種類によっては、サービスデスクだけでは解決できない場合も発生する。その場合には、インシデントの対処を段階的に移行していく。
- サービスデスクで定められた対処を行う。(1次サポート)
- 情報システム運用部門で対処する。(2次サポート)
- 情報システム開発部門で対処する。(3次サポート)
- IT業者で対処する。(4次サポート)
このような段階的取り扱いをエスカレーションという。
まず、「８．解決プロセス」について説明します。 「８．解決プロセス」は、「８．１背景」、「８．２インシデント管理」、「８．３問題管理」と３つの要求事項で構成されています。
「８．１背景」は、８．２と８．３を連携させる必要があるということを説明しているので、８．２と８．３を実現できれば、この項目は自動的に実現されます。
次に、「８．２インシデント管理」と「８．３問題管理」についてですが、用語の解説は、以下のとおりです。
【インシデント】
運用の中で対応しているアラートや障害、ミスなどの標準の運用に属 さないもの
【問題】
運用の中で、会議や連絡会などで挙げられる問題や懸念事項など、いわば、運用 において解決や対策を用意しないと顧客やサービス提供に影響が出てしまうようなもの
上記のようなことは、普段の運用の中で当たり前のように実施されていることかと思います。
だからこそ、この「８．解決プロセス」は、普段の運用をベースに実現しましょう。
では、本日の本題である「８．２インシデント管理」について話を進めます。
「８．２インシデント管理」は、発生したインシデントを迅速に処理し、サービスへの影響を最小限に抑え、確実に管理するための要求事項です。
管理にあたっては、処理手順が要求され、記録からクローズまでの定義が必要になります。
実際の運用の中で実現する際には、具体的な事象（例えば、システム障害、オペレーションミスなど）を定義する必要があります。 なぜなら、ここで事象を具体的に定義しないと、実際の運用時には、担当者によって、発生した事象をインシデントと認識する人もいれば、認識しない人もでてきてしまい、「漏れ」や「ブレ」が生じてしまうからです。
発生したインシデントを確実に処理するために、具体的な事象をあげてインシデントの定義をする必要があります。
この定義にあたっては、適用するサービスを対象に、「サービス提供における標準の運用に属さない負の事象」を洗い出し、それをインシデントとして定義してください。
インシデントを定義したら、次は、発生したインシデントを管理する手順です。
以下についての定義や実施の仕方を決めましょう。
・ インシデントの記録の残し方
・ インシデントに対する優先順位付け
・ インシデントに対する影響定義の仕方
・ インシデントの分類基準と分類方法
・ インシデントの更新方法
・ インシデントに対するエスカレーション方法
・ インシデントに対する解決の定義
・ インシデントに対する正式なクローズの定義
この要求事項の実現には、冒頭の説明にもある通り自社の普段の運用のやり方に基づいて、規格の解釈と実現方法を決定していただければと思います。
イメージができない場合は、オーバコントロールになる可能性もありますが、ITILを参考にするのもよいでしょう。
- 平成28年度春期 問56 インシデント
- 平成27年度春期 問57 インシデント
- 平成23年度春期 問56 ITサービスマネジメント インシデント管理
- 平成22年度春期 問54 インシデント管理
www.it-shikaku.jp