インシデントの根本原因を突き止める
今回はITILのサービスサポートにおける6つの運用プロセスの3つ目、「問題管理」をご紹介します。
問題管理はインシデント管理と混同されることもありますが、問題管理はあくまで原因究明を目的としたプロセスで、ITサービスをいかに迅速に復旧させるかを目的としたインシデント管理とは異なります。インシデントの根本原因を突き止め、再発を完全に防止するのが、問題管理の役割なのです。
問題管理にはある程度時間がかかります。再発防止策を施すためですが、するとインシデントを素早く解決し業務を続行することを支援するインシデント管理とは利害が対立する可能性があることがわかりますね。ITILの目的はサービスマネジメントを最適化することですから、ビジネスに対する影響を最小限に抑えることが必要です。このため、問題管理とインシデント管理の担当者は別に配置し、うまくバランスを取っていくことが重要だと言われています。
問題管理の4つのプロセス
問題管理プロセスの主要な活動は4つあります。
- 問題の記録・分類
- 問題の調査・診断
- エラー制御
- 問題のクローズ
インシデントの発生をもたらした根本原因が不明な場合は、インシデントが解決されたとしても「問題」として認識されることになります。問題が認識されたら、発見された問題を放置しないために発見者や関連するインシデントの情報などを記録・分類しておくことが必要です。
分類においてはビジネスに対するインパクトと緊急度などを要素として考え、優先度を決定します。これは、対応が必要なものが複数ある場合に備えるためです。より優先度の高い問題から調査を開始し、根本原因を究明します。根本原因が判明した問題は「既知のエラー」として識別されます。
既知のエラーも記録しておき、恒久的な解決策を施し、再発防止を目指します。この時、恒久的な解決策も記録しておきます。問題の発生経緯なども含め、基本的な事項を詳細に記録しておくことで、次に同じようなインシデントが再び発生したとしても、迅速な解決が可能になります。既知のエラーが完全に解決されたことを確認したら、問題をクローズします。
問題管理はすでに発生したインシデントへの対策ですから、基本的に受身な活動です。しかし、ベンダーが提供する情報を基にしたり、インシデントのトレンド分析を行うなど、将来発生するであろうインシデントを予防する活動をしておくと、インシデントそのものの数を減らすことができます。そのため、「積極的な問題管理」こそが問題管理の真髄とも言えるでしょう。