ITIL V2 において曖昧さを含んでいたいくつかの概念が、 ITIL V3 ではより明解に説明されています。問題管理の章で説明されていた 既知のエラーもまた曖昧さの多い概念でした。そのために、様々な誤解が 生まれていたように思います。
誤った認識を持たれがちな、いくつかの例を取り上げてみたいと思います。
・ 「問題」と「既知のエラー」の関係
・ 既知のエラー・レコードの内容
・ 既知のエラー・レコードの提起
・ 問題レコード／既知のエラー・レコードの作成者
「問題」と「既知のエラー」の関係
「問題」の根本原因が発見され、ワークアラウンドが識別された時に、「既知のエラー」 というステータスが割り当てられます。従って、「既知のエラー」になっても「問題」がクローズ される訳ではありません。「既知のエラー」になってもインシデントは 発生します。「既知のエラー」になった「問題」は、インシデントの再発防止やインパクト 低減のために、引き続き問題管理によってコントロールされます。
既知のエラー・レコードの内容
既知のエラー・レコードに記載されるのは、ワークアラウンドや根本原因だけではありません。 既知のエラー・レコードには、発生した障害の症状や判明した事実の詳細が記載されます。 また、ワークアラウンドとして、サービス回復のために取られた手順や、インシデントの発生を 迂回して目的を達成する回避策などが記載されます。 実装については、問題レコードが既知のエラー・レコードを兼ねる方法もあれば、 FAQ のような実現方法も考えられます。
既知のエラー・レコードの提起
問題の根本原因とワークアラウンドが判明したときに、問題は既知のエラーと 呼ばれるようになります。しかし、問題が「既知のエラー」になる前に、既知のエラー・ レコードが提起されることもあります。記される情報がインシデント管理にとって有用であると 判断された時点で、既知のエラー・レコードは提起すべきです。ややこしい話ですが、 既知のエラー・レコードを持つ「既知のエラー」ではない問題が存在することなります。
問題レコード／既知のエラー・レコードの作成者
同じ問題に対する別の問題レコード／既知のエラー・レコードが作成されることを 避けるために、問題マネージャだけが新しいレコードを作成できるようにするなど、 レコードの重複を避ける工夫が必要です。これは、 既知のエラー・レコードを提起できる人を制限するということではありません。 「提起する人」はあらゆる領域に渡りますが、「作成する人」は 問題管理の限られた関係者であるべきです。
次回は、2009/8/25 の予定です。
