インシデント管理は応急処置、問題管理は根治と予防
時としてインシデント管理と問題管理は混同されることがあります。
インシデントをとりあえずできるだけ早く解決するのがインシデント管理、そのインシデントを二度と起こさないように再発防止まで行うのが問題管理です。
ちなみにITILでは「問題」のことを「1つまたは複数のインシデントを引き起こす未知の根本原因」と定義しています。何だかピンと来ない定義ですが、要は「放っておいたら同じ厄介ごとを起こしてしまう原因」ということです。
問題管理には、再発防止を行う「リアクティブな問題管理」と、そもそもインシデントが発生しないように予防する「プロアクティブな問題管理」があります。これにはインシデントの予防も含まれるわけです。
例えるなら、ハードディスクが反応しなくなり困っていたが、叩いたら一時的に復旧した。これはインシデント管理です。しかし、いつまた動かなくなるかわからないので、他のハードディスクにデータを移して交換したり、SSDなどを採用したりする。これは問題管理になります。インシデント管理が応急処置なら、問題管理は根治と予防と言い換えても良いでしょう。
問題管理では根本原因を詳細に検討するため、時間がかかります。また、原因を解決するためにサービスの内容等も変えなければならないことがあるので、他の管理プロセスと連携することもあります。
問題管理プロセスでは、主に次の9つの活動を行います。
- 問題の識別
- 問題の記録
- 問題の優先度付け
- 問題の調査と診断
- ワークアラウンド(暫定対応策)の実施
- 問題の記録(情報の既知化)
- 変更要求の記票
- 問題の解決
- 問題のクローズ
前半部分はインシデント管理とほぼ同じです。ワークアラウンドの実施はインシデント管理とも重なりますね。
変更要求はRFC(Request for Change)とも呼ばれ、サービスの内容や構成要素を変更する必要がある場合に行われます。
Redmineを活用すれば、インシデント管理だけでなく、問題管理にも応用することができます。また、変更管理にも対応できます。変更管理については、次回解説致します。
Remineが得意とするチケットというシステムは、変化に強いと言われます。ステータスの変化などにも柔軟に対応できるので、インシデント管理→問題管理→変更管理のプロセスをカバーすることが可能なのです。