いったん障害が発生すると、ユーザーからは「いつになったら直るのですか」という矢のような催促が来るはずです。こうした催促で胃が痛くなるというのは、システム管理者であれば誰でも経験があることだと思います。しかし、運用対処が適用され、サービスが復旧すると、これらのフォローは必要なくなります。もちろん、こうしたシステムの立ち上げ当初は、インシデントが発生しても運用対処の方法がわからないかもしれません。しかし、運用を重ねるにつれてデータベースにインシデントのデータがたまってくると、障害が発生しても運用対処のみで復旧ができるようになってきます。
ただ、これは「サービスを速やかに復旧し、ビジネスへの影響を最小化する」というインシデント管理の目的に合致してはいますが、そのままでは「同じ問題が何度も発生する」という現象につながります。したがって、インシデントが発生した場合には問題管理にエスカレーション(移行)し、根本原因を特定することが重要です。
![]() |
|---|
| 図1●インシデント管理と問題管理の振り分け |
インシデント管理がない場合は、問題管理のエンジニアはユーザーから「早く原因を調べて、復旧させて!」というプレッシャーの中で作業をしなければなりません。しかし、インシデント管理が機能していれば、運用対処によりユーザーへのサービスは復旧しているので、問題管理のスタッフも余裕を持って調査ができるようになるというメリットがあります。
今回のインシデント管理についてまとめると、以下のようになります。
インシデント管理を効率的に行なうためには、最初にコールを受けるサービスデスクと密に連携することが重要です。データベースを統合したサービスデスクツールも市販されていますのでそれらの導入を検討するのもよいでしょう。次回は、もう一方の問題管理について見ていきます。
協力:ネットワークマガジン
|
|
||||
|
|
|
|
|
|
|
|
||||