連載コラム

知らないでは許されない
ITILでシステムの効率化を目指そう

2005年9月1日　　協力●東芝ソリューション

第8回
「次につなげるトラブル管理術（2）」～問題管理～（2/3）

ステップ2　原因を特定し、対策を指示する

　問題を記録したら、次に根本原因の調査を行ないます。その場合、前述したKEDBの検索はもちろん重要ですが、他の管理プロセス、特に変更やリリース管理との情報共有が重要になります。

　問題の8割は、その直前に何か変更を行なっているといわれています。したがって、その問題が発生したCIや関連するCIで、直前に何か変更を加えていないか調べることが重要です。たとえば、あるネットワークで問題が発生したら、そのネットワークのゲートウェイだけでなく、接続先のルータや電気を供給している電気系統まで調べるわけです。

　事例では先週末に行なった変更（パッチ配布）に関するRFC（変更要求）や、変更が失敗した結果やバックアウト（パッチ戻し）の作業報告、あるいは変更後のPIR（変更後レビュー）議事録が問題管理の担当者Bさんにも配布されていたら、この変更が関連しているということに早く思い当たったかもしれません。その結果、より適切な復旧指示をより早く出すことができたでしょう。