大手流通業F社の情報システム部門でサーバ運用を担当するBさんは、Webシステムが使えないとの一報を社内インフラのヘルプデスクから受けた。この障害に関しては、サーバの再起動によって復旧することができた。
その日の深夜、日中に採取したデータをもとに原因を解析した。その結果、問題はWebサービスではなく、他のプログラムが異常にシステムリソースを消費していたのが原因と判明した。そしてさらに調査を進めると、先週末に当てたOSのパッチにバグがあったことがわかった。作業をした担当者に聞くと、パッチのバグにはすぐに気付いてすべて戻したつもりだったが、このサーバだけ洩れてしまったらしい。
Bさんは悩んだ。なぜもっと早く気付くことができなかったのか。そして、今後このようなことが起きないようにするにはどうすればいいのだろうか……
前回では、障害時にはまずサービスを復旧するのが最優先であることを説明しました。とはいえ、原因がわからないまま運用対処を繰り返すだけでは、いつまでも同じトラブルを繰り返すだけです。再発防止のためには、根本原因を究明することが重要になります。
今回は「次につなげるトラブル管理術（2）」として、どのように効率的に原因を究明するか、そして、そもそも問題が起きないようにするにはどうしたらよいかを考えていきます。
この連載の読者の方はもうお分かりだと思いますが、ITシステム管理の基本は記録することです。記録することで情報が蓄積され、部門内での情報共有や、再利用のための基盤とすることができます。特に情報の再利用は業務の生産性向上につながる重要な特性ですので、今回は重点的に説明しましょう。
情報を利用する上で重要になるのは分類することです。皆さんもさまざまなメールマガジンを購読していると思います。しかし、きちんとフォルダを分けるなどして整理していなければ、気になる新製品や新技術の紹介記事を保存しておいても、必要になったときに見つけられません。情報は単に蓄積しておいても、検索できなければ何の役にも立たないのです。しかも、いったんランダムに蓄積された情報を、あとから分類しなおすのは非常に困難です。そのため、最初にその情報を取得した人が、あとの検索を考えて、適切な分類やラベル付けをしておくことが重要になります。
ITILの問題管理プロセスでは、「問題の特定・記録」と「問題の調査・判別」の間に「問題の分類」という手順を設けています。これは優先度・緊急度で分類することでその後の処理を最適化するという目的だけでなく、情報を整理して検索しやすくする効果もあります。そして、その分類された問題に関する情報をデータベース化しておくことで、あとあとの情報共有が可能になります。
分類のキーはいくつかありますが、大半はインシデント管理と共通で、問題の現象や発生個所（CI：構成アイテム）などです。ただ、インシデント管理ではビジネスへの影響を最小限にするという観点から、ユーザー情報が重要であったのに対し、問題管理では1つの問題が複数のインシデントに関連する場合もありますので、問題それ自身の症状や関連するCIの情報が重要なキーになります。
ITILでは問題に関するデータベースがいくつか定義されていますが、中でも重要なものが「既知エラーデータベース（Known Error Data Base：KEDB）」です。ITILでは原因が判明した問題は「エラー」と呼ばれますが、KEDBは対処方法まで判明しているエラーを集めたDBになります。問題が発生した時には、まずこのDBと照合することで、原因・回避策を素早く特定することが可能になるわけです。KEDBには実環境で発生した既知エラーを集めた「実環境KEDB」や、実環境にリリースする前の開発環境で判明している既知エラーを集めた「開発KEDB」、その他、機器やソフトウェアに関するKEDBもあります。マイクロソフトのように製品ごとにこのKEDBが公開され、Web等で検索できる場合もあります。
事例のケースでは、あるOSのパッチの不具合が直接の原因だったわけですから、そのOSに関するKEDBがきちんと整備されていれば、症状と発生したサーバのOS種別やバージョン（CI）をキーにして検索できたはずです。こうすれば、もっと早くパッチが原因だったことに辿り着くことができたかもしれません。
 |  |
|---|
「ITILでシステムの効率化を目指そう」トップへ
【アスキービジネス 新刊ムック】
【ASCII.jp SaaS・ASP】
