![baloon-red]()
インシデントとは
インシデントとはアクシデントに至らないためのインシデント管理
インシデント（incident）とは、元々は「事件」や「できごと」といった意味を持つ英単語です。様々な業界において、事故（アクシデント）などのリスクが発生する恐れのある事態をインシデントと呼びます。例えば航空業界では、ケガ人はいなくても飛行機が滑走路から逸脱するようなできごとはインシデントとされます。医療機関のインシデントは国内ではヒヤリ・ハットとも呼ばれ、投薬の間違いなどを事前に気付き実害がなかったとしても、インシデントとして報告しなければなりません。いずれも取り返しのつかないアクシデント（事故）に至らないために、インシデントの段階で把握・管理する必要があるためです。
ITサービスも同様です。ITサービスにおける「インシデント」とは、計画外の停止やサービス品質の低下など、ビジネスの継続やユーザーの業務に悪影響を与える「できごと」を指します。このようなインシデントが繰り返されると、ユーザーから自社のビジネスへの信頼も失うことになります。
インシデントの発生時に、スピーディーに対応し、ビジネスへの悪影響を抑えるために「インシデント管理」が必要となるのです。
目次
![baloon-red]()
ITシステム運用におけるインシデント
サービスを正常に遂行できない事象が「インシデント」
まずは「インシデント」を理解するために、事例をもとに解説していきます。
サービスデスク部門の担当者のもとに、経理部門の担当者から次のような問い合わせがきました。「いつも正常に使用できている経理システムで決済処理をし、次の画面へ遷移しようとしたところ、画面が固まってしまい次の画面にいけない」
サービスデスク部門では、取り急ぎの対処法として経理に「システムからのサインアウト」を依頼しました。
経理部門からは「サインアウト実行後、また通常に利用できるようになった。しかし、同様のトラブルは度々発生している」との返信が届きました。
その後、サービスデスク部門からシステム部門へ更なる調査を依頼。システム部門の担当者が、問題の特定と原因究明を行ったところ、経理システムサーバーのメモリ不足が原因でシステムにインシデントが発生しやすい状態であることが判明しました。
この事例の場合、ITシステム運用上のインシデントとは「経理システムが次の画面に遷移しない」というできごとを指し、ユーザーがITシステムを正常に運用できていない状態がインシデントに該当します。
![baloon-red]()
ビジネスに不利となるインシデントの影響
企業内で起こり得るインシデントには、事例以外にも以下のようなできごとが想定されます。
情報セキュリティにおけるインシデント例- 顧客・社員などの個人情報流出
- マルウェア感染
- 不正アクセス
- USBメモリの紛失 など
- ネットワークの稼働停止
- メール送受信の停止
- 業務アプリケーションの不具合 など
- 営業活動・企業活動の中断
- 社会的信用の失墜
- 損害賠償の発生、罰金や課徴金等の支払
- 社内の従業員の働く意欲の低下
- 人材採用の見直し
など様々な悪影響が想定されます。そもそもユーザーが利用する機器そのものが増えています。PC、スマートフォン、VPN機器、サーバー、クラウドなどサイバー攻撃の対象そのものが広がっており、ユーザーの実態把握も難しくなっています。そのためにも、確実なインシデント管理を実行することで、取り返しのつかないアクシデントを防ぐことが重要です。
![baloon-red]()
インシデント管理とは？
インシデント管理ではサービスの迅速な復旧を優先
インシデント管理とは、ビジネスへの影響を最小限に抑えるために、可能な限り迅速にサービスを復旧するための一連の活動のことです。インシデント管理では、インシデントの根本原因を深く調査することよりも、一時的な回避策を活用しながらサービスを迅速に復旧することを優先します。
インシデントの一次対応は、サービスデスクのスタッフで行うことが一般的です。
冒頭の事例の場合、サービスデスク部門から経理部門担当者に「システムからのサインアウト」を依頼し、インシデントを迅速に解決しています。その他にも「経理システムの代わりにメールでエビデンスを残し決済処理を実施する」などの回避策が考えられます。
![baloon-red]()
問題管理とインシデント管理の違い
インシデントの根本原因をが「問題」
問題とは、インシデントを引き起こす根本原因のことを指します。この事例の場合は「経理システムのサーバーのメモリ不足」が問題に該当します。
問題管理とは、インシデントの根本原因を調査し、恒久的な解決策を特定する一連の活動のことです。根本原因を特定することで、インシデントの再発や将来的に新たなインシデントが発生することを予防します。
事例の場合、「サーバーのメモリを増設する」や「サーバーのデフラグを実行する」が、問題管理プロセスにおける解決策となります。
上記のフロー図に沿って考えると、「インシデント管理」は経理システムが次の画面に遷移しないというできごとに対し「システムからのサインアウト」という取り急ぎの対応策がインシデント管理にあたります。次に、画面遷移しなかった根本原因を探るのが「問題管理」で、経理システムのサーバーメモリ不足が二度と起こらない再発防止策がそれに該当します。そこから、実際にサーバーのメモリを増設していくという変更管理プロセスへと移っていきます。
![baloon-red]()
インシデント管理のよくある課題
すでにインシデント管理を実践しているものの、思うような成果が得られていないという現場は少なくありません。例えば、よくある課題として以下が挙げられます。
- 同様のインシデントがたびたび発生する
- メールや表計算シートでの情報管理が煩雑
- 情報共有が難しく「誰が対応しているか」や「進捗状況」が分からない
- 問合せ対応が属人化してしまい、ナレッジを共有できない
このような課題については、インシデント管理ツールを導入することで、課題を可視化でき、管理フローを標準化することで解決できます。
![baloon-red]()
理想的なインシデント管理フローとは？
例えば、ManageEngineが提供するITサービスマネジメントツール「ServiceDesk Plus」のインシデント管理機能を利用すると、理想的なインシデント管理フローを容易に構築できます。
ServiceDesk Plusの機能を活用すると、以下の7つのステップに沿って、効率的にインシデント管理を進めることが可能です。
ITサービス/ITシステムの停止やサービスレベルの低下が検出されたら、ServiceDesk Plusにインシデントとして登録し、サービスの復旧に向けて対応を開始します。
インシデントの内容を基に、インシデントを分類します。ServiceDesk Plusには、インシデントのカテゴリー・緊急度・重要度・業務への影響・報告手段・報告者・関連するIT資産などを設定する項目が用意されています。組織のニーズにあわせて、任意のフィールドを追加できます。
インシデントの業務への影響度合いを基に優先度を設定します。さらに、インシデントの優先度やその他項目の値によって、インシデントにSLAを自動的に適用します。
分類されたインシデントには適切なサポートグループとサポート担当者を割り当てます。業務ルール・担当者の自動割り当て機能でサポートグループとサポート担当者への割り当てを自動化できます。
インシデントに割り当てられたサポート担当者はインシデントの調査と診断を行います。
インシデントの解決策を特定しサービスを復旧します。サポート担当者からユーザーに解決策を連絡し、ユーザー自身で復旧作業を行うパターンや、サポート担当者から上位グループにエスカレーションを行い、上位の技術者グループで復旧作業を行うパターンがあります。
インシデントが解決していることを確認できたらインシデントをクローズします。
インシデント管理に不可欠なレポート機能
また、インシデントの対応履歴や進捗状況を見える化するためのレポート機能もお勧めです。対応中のリクエストはどれだけあるのか、クローズしたリクエストはいくつあるのか、また、回答期日が超過しているリクエストはいくつあってそれは誰が担当者なのかなど、管理者が必要とするデータを表示するレポート作成機能を標準装備しています。1クリックで必要なレポートを作成でき、レポート作成時間を大幅に削減することができます。また、標準レポートでは要件を満たせない場合、カスタムレポート機能を利用して独自のレポートを作成することで、より詳細なレポート作成が可能です。
![baloon-red]()
インシデント管理の目的と重要性
インシデントの内容によって深刻度や影響度の違いはありますが、いざインシデントが発生したスピーディーにITサービスを復旧させることは、加速の時代においてますます重要な意味を持っています。インシデントを管理することから、問題管理・変更管理へのプロセスが始まり、再発防止に向けた効果的な対策が取れるようになります。その点でも、インシデント管理はITサービスマネジメントの出発点とも言えます。
不正アクセスや情報漏えいなどの深刻なインシデントの場合、その対応がずれ込むほどシステム復旧ならびに社外的な信用回復のコストも嵩みます。確実なインシデント管理は業務遂行の円滑化だけでなく、企業の存続の関わる大きな課題であることを認識し、確実にインシデント管理を実行できるツールの導入をお勧めいたします。