いかに根本的な原因を追究するか：システム管理入門（3）（1/2 ページ）

メールシステムなどに見られるインシデントを管理する目的は、障害対応ではなく、あくまで現状復帰であると前回述べた。しかし業務に支障をきたすインシデントであれば、根本的な原因を突き止めて取り除く必要がある。それが「問題管理」である。

　今回は、「問題管理」という概念についてお話します。

　その前に、明らかにしておきたいことがあります。システム管理者、あるいはITサービスマネージャと呼ばれる人たちの教科書的な存在にITIL（システムの運用、管理業務に関する体系的なガイドライン）や、ITILを元に作成したISO/IEC 20000（日本ではJIS Q 20000）があります。インシデント管理や問題管理という言葉は、これらの中で明確に定義されています。

　本連載でも当然これらを参考にはしているものの、システム管理者の心構えを中心に述べていきますので、「ITILではこう書いているのに、この連載ではどうしてこう書いてあるのだ」という意見もあると思います。

　実は、ITILはそのまま日本のIT事情に導入するのは難しく、独自の解釈が必要だと筆者は考えています。事実、多くのITIL関連書籍にも「導入できるところだけ選んで導入すればよい」と書かれています。今回取り上げる問題管理も、IITLでいうところの「プロセス」としてではなく、あくまでも考え方や方針としてとらえていることをご了承ください。

問題管理の必要性は業務担当者が判断

　本題に入る前に、前回の「インシデント管理」について復習しましょう。一言でいえば、インシデント管理の目的は現状復帰です。既に申し上げているように、インシデント管理では、原因追求やその原因を取り除くための措置というのは考えません。例えば、ルータを再起動したら直るといった一時的な対応策（ワークアラウンド）を持つインシデントであれば、ルータを再起動すればいいわけです。

　しかし、すべてのインシデント対策がそれでいいというわけではありません。場合によっては、きちんと原因を追究し、それを根本的に取り除く活動が必要になります。そうした一連の活動を「問題管理」といいます。

　筆者の今までの経験から、問題管理が必要になるのは次の場合です。

1. インシデントが頻繁に発生し、ワークアラウンドが確立されていたとしても業務に支障が出ている場合
2. インシデントが次回発生すれば、業務に致命的な影響が出る場合
3. インシデント発生によって、利用者に（ITやシステム管理者に対する）不信感が生まれる可能性が高い場合
4. 利用者がインシデントの根本原因に気付いており、その認識が正しい場合

　重要なのは、問題管理が必要かどうかの判断基準はあくまでも業務と、その業務に携わっている人だということです。ITそのものは判断基準になりません。よく「ITが動かないことは悪いことだ」と勘違いされますが、本来は「業務が止まることや業務に携わる人に迷惑が掛かることが悪いこと」なのです。システム管理者の責任は、文字通り情報システムを管理することですが、システムにばかり目を向けていてはいけません。目を向けるべきは、業務と人です。業務と人こそが主役なのです。それらに迷惑を掛けないためにシステムを管理するという意識が必要です。

問題＝インシデントの根本原因

　問題管理は大きく2つの活動に分けられます。

1. インシデントの原因追究
2. 恒久的な解決策の立案と実施

　ITILでは、まだ特定されていない未知の根本原因のことを「問題」と呼び、特定されて解決策が見えている根本原因のことを「既知のエラー」と定義していますが、本連載ではひとまとめに問題と呼ぶことにします。つまり、問題＝インシデントの根本原因です。

　ITにまつわる問題の多くは、ハードウェアやソフトウェアの障害、不具合でしょう。障害が発生している場所の切り分け、障害の特定といった作業がインシデントの原因追究に当たります。システム管理者が最も頭と神経を使う仕事です。

　障害の場合、最初にすべきことは障害が発生している場所の特定です。「クライアントPCから電子メールが送受信できない」というインシデントであれば、障害の発生場所は、恐らく次のうちのいずれかでしょう。

　一口に「電子メールが送受信できない」というだけでも、これだけ障害が発生する可能性のある場所があるのです。 障害の発生場所が特定できたら、今度はどんな障害が起こっているのかを調べます。具体的な調べ方は割愛しますが、最近ではハードウェアやソフトウェアに対して非常に便利なトレースツールが存在しますから、それらを有効に使いましょう。

　しつこいようですが、インシデントの発生原因は障害だけとは限りません。あるインシデントが重なるのでよくよく調べてみたら、利用者の大半がソフトウェアの使い方を間違って理解していたというようなこともあります。そういうことも含めて問題を明らかにしていくのです。