連載コラム

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

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

第7回
「次につなげるトラブル管理術（1）」～インシデント管理～（1/3）

　大手流通業F社の情報システム部門でサーバ運用を担当するBさん。ある日の午前、社内インフラのヘルプデスクから「社内Webにアクセスできないが、システム障害ではないか」という連絡が入った。さっそく調査に向かったが、一見したところ異常は見当たらない。
　しかし、調査を進めると、Webサービスのプロセスからエラーメッセージがログに書き出されているのを発見した。このエラーは以前にも発生した記憶があったので、Webサーバのドキュメントを広げて該当するエラーの個所を探してみた。だが、「調査状況を教えてください」とのヘルプデスクからの頻繁な進捗問い合わせに、なかなか解析に集中できない。こうしている間にもどんどん時間が過ぎていく。トラブル対応は時間との勝負であることは分かっているが、この状況は何とかならないものだろうか……

インシデント管理と問題管理

　ITが日常の業務に欠かせないものになるにつれ、システムはいつでもきちんと動いていて当たり前という感覚になっています。しかし、実際には程度の差はあれ、障害の発生は避けられません。発生した障害を切り分け、原因を特定し、解決策を適用することはシステム管理のもっとも基本となる重要な作業です。ですが、いざトラブルが発生するとさまざまな割り込みが発生して、なかなか原因解析に専念させてもらえないものです。

　ITILではトラブル発生後、原因を特定するまでの作業を、前半の「インシデント管理」と後半の「問題管理」の2つのプロセスに分け、可用性（アベイラビリティ）向上と作業の効率化を図っています。

　インシデント管理は、トラブル等（インシデントと呼びます）の履歴を記録し、問題管理へ渡すとともに、運用対処によりサービスの速やかな復旧を図るのが目的です。一方、問題管理は問題の根本原因と対策を特定し、後段の変更管理（第2回で紹介）のデータベースに登録するほか、再発防止のために予防措置を検討します。従来のトラブル対応ではこれらの機能が一緒に行なわれていたため、事例のようにきちんと機能しないケースがありました。しかし、ITILではインシデント管理と問題管理のプロセスを分離することで、業務への影響を最小化すると共に、原因解析の作業を効率化します。

　では今回は、インシデント管理でどのようなことを行なうのかを見ていきましょう。

ステップ1　事象を正確に記録する

　インシデント管理でまず行なわなければならないことは、事象を正確に記録することです。この連載をお読みの方はすでにおわかりだと思いますが、対応の記録を残すことはITサービス管理の基本です。障害等のインシデントの場合も同様で、発生した事象の内容や、いつ、どこで発生したかといった情報は、この後に続く問題管理プロセスや、解決策の影響分析を行なう変更管理で必要になる基本情報になります。したがって、これらの情報を正確に記録し、後続のプロセスで参照できるようにすることが、インシデント管理に求められる重要な役割の1つになります。そのためには、第3回のサービスデスクの回で紹介したように、トラブルシート等のフォームを用意し、そこに記入していくのが効果的です。

　よくある質問として、「どんな小さな事象でも、対応したすべてのインシデントを記録しておかなければいけないのか？」というものがありますが、答えは「Yes」です。もし記録に残しておかなかった場合、そのインシデントに対応したスタッフの労力や時間、それに要したシステムリソース等は、すべて「隠れたコスト（Hidden Cost）」となり、費用対効果を正確に求めることができなくなります。問題管理での障害の傾向分析を行なうためにも、対応したインシデントはすべて記録に残しておきましょう。

「ステップ2　ビジネスを正常な状態に戻す」へ続く