インシデント管理=障害対応という誤解システム管理入門(2)(2/2 ページ)

» 2010年05月10日 12時00分 公開
前のページへ 1|2       

やりたいことができればそれでよい

 改めて考えてみましょう。情報システムの利用者が望むことは何でしょうか。最も望むのは「やりたいことをやりたい時にいつでもできる」ことです。言い換えれば、インシデントが発生しないということです。一方、最も望んでいないことは「やりたいと思った時に限って使えない」ことでしょう。双方の間には、以下のようにいくつかの段階があります。

インシデント段階

 この中には、重要なことが2つ潜んでいます。1つ目は、利用者にとって最も理想的なのはインシデントがまったく発生しないということです。2つ目は、その次の段階である、インシデントが発生しても即座に復帰できるということです。例えば、ルータの調子が悪い場合、ルータの電源を入れ直せば1分で元通りに戻ることが分かっていれば、インシデントは1分で復帰できることになります。アプリケーションの使い方が分からない場合、すぐに調べられたり、誰に聞けばいいか把握していれば、即座にインシデントは解決します。

 インシデント管理の最初の目標は、インシデントをすぐ取り除ける環境を整えることです。ルータの電源を入れ直すというような一時的な対応策のことを「ワークアラウンド」といいます。ワークアラウンドが確立されており、それを利用者に伝えることができれば、それでインシデントは解決します。紙やトナーの買い置きを切らしてしまうことのないように工夫したり、紙の入れ方やトナー交換の方法をプリンタのすぐ近くに目立つように書いておくのもインシデント管理の範疇(はんちゅう)です。

 こう考えると、インシデント管理=障害対応ではないのが分かるはずです。利用者はインシデントが取り除かれればそれでいいのです。「インシデントが発生するたびに障害を取り除かなければならない」と思い込んでしまうとストレスがたまります。目線を変えて、すぐに復旧させるには「どうすればいいか?」を考えるべきです。

 余談ですが、わたしはインシデントに見舞われたら困るものはすべて2セットずつ用意しています。「それって、二重化というのでは?」と思われるかもしれません。繰り返しになりますが、現場は使えればそれでいいのです。機器が故障したときの一時対応策(ワークアラウンド)として代替機を用意しておくというのも立派なインシデント管理の活動です。

 厳密には、「どの機器をどのように二重化しておくか」「Active-Activeの状態で完全に二重化するのか、Active-Standbyの状態で有事に切り替えるか」といった具体的な方策を考えるのは、ITILにおける「可用性管理」の範疇です。それはまた別の機会にお話することにしましょう。

 何はともあれ、印刷できればそれでよいという状況を最も簡単に作り出すにはどうすればいいかを考えて、普段使うプリンタとは別に安価なプリンタをもう1台オフィスに設置しました。ホチキスやはさみなども2セット以上手元に置いています。「やりたいことができればそれでよい」と考えるのが、インシデント管理の基本なのです。

利用者の視点で考える

 インシデント管理の目標はもう1つあります。それは「インシデントがいつ解決できるかを知らせること」です。例えば、インシデントが発生してから30分間、利用者にまったく連絡せず、30分後に復旧したと突然連絡が入るのと、インシデントが発生してからすぐにシステム管理者から利用者に連絡が入り、その10分後に「60分後に復旧する」との通達があり、さらに50分後にシステムが復旧するというのでは、利用者にとってフラストレーションがたまるのはどちらでしょうか。

 結果的にインシデントの復旧が早かったのは前者ですが、それまで何の連絡も入らなかったのでは、利用者はさぞかし、待っている間にやきもきするでしょう。後者のケースでは、インシデント発生のすぐ後に利用者に連絡が入り、10分後には復旧の目処を告げています。利用者がまったくやきもきしないということはないでしょうが、いつ復旧するかの目処が立っていると、利用者にも心積もりができます。インシデント復旧に時間がかかる場合は、利用者に連絡を入れることが大切です。状況を利用者に的確かつ正確に伝えることで利用者の満足度は高まります。

 インシデント管理の基本は、利用者の視点で考えるということです。利用者が本当に望んでいるのは、障害を取り除くことではありません。使えるようになるということです。この2つを混同しないように注意したうえで、すぐに使えるようになるにはどうすればいいかを考えましょう。そうすると、システム管理者としてのフラストレーションは軽減されるかもしれません。障害を取り除かなくていいのですから。

 とはいえ、インシデント管理がいくら成熟しても、インシデントそのものがなくなるわけではありません。インシデントがあまりにも多発すると、いくらインシデントに対するワークアラウンドが確立されていたとしても、利用者は満足してくれないでしょう。インシデントの発生頻度やインシデント発生における影響の大きさによっては、きちんと原因を特定し、その原因そのものを取り除かなければなりません。そこで必要な仕事が「問題管理」です。これについては、次回に詳しくお話します。

著者紹介

▼著者名 谷 誠之(たに ともゆき)

テクノファイブ株式会社 阪神支社 ラーニング・コンシュエルジュ。IT技術教育(運用系/開発系)、情報処理試験対策(セキュリティ、サービスマネージャ、ネットワークなど)、対人能力育成教育(コミュニケーション、プレゼンテーション、チームワーク、ロジカルシンキングなど)を専門に約20年にわたり、活動中。「講習会はエンターテイメントだ」を合言葉に、すぐ役に立つ、満足度の高い、そして講義中寝ていられない(?)講習会を提供するために日夜奮闘している。

ディジタルイクイップメント株式会社(現:日本HP)、グローバルナレッジネットワーク、ウチダスペクトラム、デフォッグなどを経由して現職。

テクニカルエンジニア(システム管理)、MCSE、ITIL Manager、COBIT Foundation、話しことば協会認定講師、交流分析士1級などの資格や認定を持つ。近著に『高度専門 ITサービスマネジメント』(アイテック、2009年6月)

がある。


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ