Redmine
インシデント管理とは、システム障害やセキュリティ事故、操作ミスなどのインシデントが発生した際に、迅速な復旧と影響最小化を目的として対応する一連の管理プロセスを指します。発生状況の把握・記録、優先度付け、原因切り分け、復旧対応、再発防止策の検討までを体系的に行うことが特徴です。適切なインシデント管理を行うことで、サービス停止時間の短縮や顧客満足度の維持、IT運用の安定化につながり、企業の信頼性向上にも寄与します。本記事ではインシデント管理の違いについて問題管理との違いなど含めて解説します。
目次
インシデントとは、システム障害やサイバー攻撃、人的ミスなどにより、業務やサービスの正常な提供が妨げられている、またはその恐れがある事象を指します。必ずしも重大な事故に発展していなくても、放置すれば影響が拡大する可能性がある点が特徴です。企業のIT運用やセキュリティ分野では、インシデントを迅速に検知・記録し、影響範囲を最小限に抑えながら早期復旧を図ることが重要とされています。そのため、発生原因の分析や再発防止策まで含めて体系的に対応する「インシデント管理」が求められています。
インシデント管理（Incident Management）とは、なんらかの理由でユーザーのシステムが正常に利用できなくなったときに、その原因やトラブルを解決し、再びシステムを正常に利用できるようにするためのサポート体制です。
一時的な回避策、対応策を使い、ビジネスへの影響を少なくすることが求められます。可能な限り迅速なサービスの復旧を行い、ビジネスへの影響を最小限に抑えるために必要です。あくまでも一時的な解決策ではありますが、根本的な解決をするためには必要なことになります。インシデント（incident）は日本語では「あまりよくないできごと」「ちょっとした事件」という意味になります。
ちょっとしたバグや短時間の障害、ユーザーの操作ミス、システムの一時的な停止など、本当に些細で様々なことが含まれています。
迅速に対応しなければ被害が大きくなる、広がるような状態発生をインシデントと呼びます。
インシデント管理の目的は、ビジネスへの影響を最小限にすること、迅速なサービスの復旧をすることが目的です。
ですがインシデント管理ができていないと、問題管理にまでつながらない、根本的な問題解決にならない、などの可能性が出ます。
またインシデント管理はインシデントについて即時的に対応し、その記録を残していくことが大事になります。
同じインシデントが繰り返されている、似たようなインシデントばかりがある、そのような時は、インシデント管理が問題管理にまで到達していない可能性があるでしょう。
根本的な解決をするために、インシデント管理は必須です。
インシデントが繰り替えされる場合、根本的な原因の解決ではなく、インシデントの解決ばかりがされているのではないでしょうか。
サービスを正常に遂行できない事象が「インシデント」です。ここでは、別の業務システムを例に、インシデント管理の考え方を解説します。
【事例】
ある朝、営業部の担当者からサービスデスク部門に次のような問い合わせがありました。
「取引先にメールを送信しようとしたところ、何度試しても送信エラーになり、メールが相手に届きません。社内宛てのメールは問題なく送れています」
【対応】
サービスデスク部門は一次対応として、
を依頼しましたが、状況は改善しませんでした。
そのため、影響範囲を確認したところ、複数の部署で同様の問い合わせが発生していることが判明しました。
【原因の特定】
メールサーバーのディスク容量不足
システム部門が調査した結果、メールサーバーのディスク容量が上限に達しており、新規メールの送信処理が正常に行えない状態になっていることがわかりました。不要なログファイルを削除し、容量を確保したことで、メール送信は復旧しました。
【定義】
この事例における「インシデント」とは、
「業務に必要なメールを外部に送信できず、営業活動に支障が出ている状態」
を指します。
たとえシステム自体が完全に停止していなくても、ユーザーが本来の業務を遂行できない状況が発生していれば、それはIT運用上のインシデントに該当します。
●システム・アプリケーションに関するインシデント例
・業務システムの画面がフリーズし操作できない
・アプリケーションが起動しない／強制終了する
・一部機能のみ動作せず、処理が完了しない
・バッチ処理が途中で停止し、データが更新されない
・システムレスポンスが極端に遅く、業務に支障が出ている
●サーバー・インフラに関するインシデント例
・サーバーがダウンしサービスが利用できない
・CPU・メモリ・ディスク容量の枯渇
・仮想サーバーが起動しない
・バックアップ処理が失敗している
・冗長構成の切り替えが正常に行われない
●ネットワークに関するインシデント例
・社内ネットワークに接続できない
・VPN接続が不安定、または接続できない
・特定の拠点からのみシステムにアクセスできない
・外部サービスへの通信が遮断されている
・無線LANが断続的に切断される
●クラウド・SaaS利用時のインシデント例
・クラウドサービスにログインできない
・SaaSの障害により業務が停止している
・API連携が失敗しデータ同期が行われない
・クラウド側の設定変更により機能が使えなくなった
・利用上限超過によりサービスが停止した
インシデントとは、予期せぬシステム停止や障害によって業務遂行が妨げられる状況を指します。インシデントが発生すると業務効率が著しく低下するだけでなく、顧客満足度や企業のブランドイメージにも深刻な影響を与えかねません。例えば、オンラインサービスが停止すれば直接的な売上損失につながるほか、復旧に時間がかかれば顧客離れも進んでしまいます。また、繰り返し起こるインシデントは、従業員のモチベーション低下を引き起こし、生産性の低下や組織の信頼性低下にも繋がります。企業はインシデントによるリスクを最小限に抑えるため、迅速かつ適切なインシデント管理が必要となります。
時としてインシデント管理と問題管理は混同されることがあります。
インシデントをとりあえずできるだけ早く解決するのがインシデント管理、そのインシデントを二度と起こさないように再発防止まで行うのが問題管理です。
ちなみにITILでは「問題」のことを「1つまたは複数のインシデントを引き起こす未知の根本原因」と定義しています。何だかピンと来ない定義ですが、要は「放っておいたら同じ厄介ごとを起こしてしまう原因」ということです。
関連記事：ITILにおけるインシデント管理
問題管理には、再発防止を行う「リアクティブな問題管理」と、そもそもインシデントが発生しないように予防する「プロアクティブな問題管理」があります。これにはインシデントの予防も含まれるわけです。
例えるなら、ハードディスクが反応しなくなり困っていたが、叩いたら一時的に復旧した。これはインシデント管理です。しかし、いつまた動かなくなるかわからないので、他のハードディスクにデータを移して交換したり、SSDなどを採用したりする。これは問題管理になります。インシデント管理が応急処置なら、問題管理は根治と予防と言い換えても良いでしょう。
問題管理では根本原因を詳細に検討するため、時間がかかります。また、原因を解決するためにサービスの内容等も変えなければならないことがあるので、他の管理プロセスと連携することもあります。
インシデント管理とワークアラウンド、問題管理の違いを説明します。
似ているため混同されがちではありますが、違いを理解していきましょう。
このような違いがあります。
ワークアラウンドとは、根本的な解決にはなっていないものの、応急処置的にその場のトラブルを解決する動きを指します。
またワークアラウンドは応急処置的に動くので、インシデント管理と思われがちですが、実際には問題解決を行っているので問題管理の部類です。
どのようなワークアラウンドを行い、その後どうなっていったのか、根本的原因の解決の妨げになっていないように、確認する必要性があるでしょう。
問題管理とは、発生したインシデントを解消することだけでなく、そのインシデントの再発や予防するための対策を考えること、実際に対策をすることを指します。
この場合の問題はインシデントを引き起こす、根本的なトラブルのことです。
発見された課題や問題を、インシデント管理し、ワークアラウンドで即時的に解決します。問題管理は、その結果や経過をシステムやサービスに反映させるのです。
品質やサービスを安定させ、また向上させたり改良していきます。
インシデント管理、ワークアラウンド、問題管理の違いはこのようになっています。
| インシデント管理 | ワークアラウンド | 問題管理 |
| 迅速な対応を考えるサポート体制一時的な解決、回避策を行い、ビジネスへの影響を少なくする | 迅速な対応を行う復旧作業を実際に行う | インシデント後再発や予防の対策を行う体制品質やサービスを安定させ、向上や改良していく |
このように、対処をするタイミング、実際に対処をする内容などで違いがあります。
インシデント管理はインシデントが発生してから迅速に対応することであり、問題管理はその後の再発や予防を行うことが大切です。
そうすることで、同じインシデントを繰り返すことなく、逆にサービスの質や安定、向上や改良にまでつながります。
問題管理に関してはこちらの「ITILにおける問題管理」で詳しく解説していますので合わせてお読みください。
ここでは、インシデント管理の各段階について説明します。
インシデント管理にも各段階があり、何が行われているのか、担当者は誰なのか、理解した上で対応を行いましょう。
また担当者を明らかにしておくことで、メリットもあります。
ナレッジベースの記録から、似ているインシデントを把握し、ユーザー担当者でも対応できるものにすることができるからです。
それでも分からない場合や、難しいと判断された時には上位者が対応すればよい状態になります。
この判断が的確にできる状態になると、エスカレーションの回数や、対応する時間の短縮ができ、業務の効率化が望めるでしょう。
ここでは
この6つの流れで説明していきます。
発生したインシデントを早期に検知して、それに記録します。
ユーザーからの連絡であったり、システムのアラートであったり、と検出される場所は様々です。
どこで発生したのか、何が起きたのかをしっかりと記録することで、今後のインシデント管理につながります。
インシデントを分類することは、問題管理につながり、根本的な解決へつながる一歩です。
またインシデントの分類は、ナレッジベースから過去によく似たものがないかを検索し、その内容や状況などから分類します。
そのデータから対応の優先度や難易度を決定するのです。
緊急度や優先度、難易度などが違うため、ユーザーサポート担当者で対応が可能なのか判断します。
難しい場合は、上位の管理者などに意見を聞いたり、指示を仰いだり、など対応を引き継ぐことをしましょう。
担当者で対応が可能であると判断されたインシデントは、ユーザーサポートの担当者が解決します。
ナレッジベースから過去に似ているものや優先度、難易度を判断しているので、担当者でも解消できるインシデントです。
担当者だけでは対応できないインシデントの場合は、エスカレーションにより、マネージャーや責任者が問題を解決します。
エスカレーションとは、ユーザーサポート担当者では対応できなかった場合にその上位者へ指示を仰いだり、対応を引き継ぐことです。
インシデントが解決したあとは、その記録をナレッジベースに登録します。
状況や経過観察、顧客のフォロー、再発していないかなどを確認することは、重要なことです。
対応が必要な場合は、対応が終了するまで継続します。
インシデントが解消され、作業が再開することができたら報告をして、対応を終了します。
この時、再発していないか、顧客は満足しているか、など様々なことに配慮しましょう。
Redmineを活用すれば、インシデント管理だけでなく、問題管理にも応用することができます。また、変更管理にも対応できます。変更管理については、次回解説致します。
関連記事：ITILにおける変更管理とは？メリットとデメリット、変更管理プロセスを解説
Remineが得意とするチケットというシステムは、変化に強いと言われます。ステータスの変化などにも柔軟に対応できるので、インシデント管理→問題管理→変更管理のプロセスをカバーすることが可能なのです。
より詳しくRedmineについて知りたい方はこちらの「Redmineとは？基本機能とおすすめの使い方をわかりやすく解説」をご覧ください。
関連記事：障害管理からRedmineが発展しインシデント管理ツールとして利用する方法
ITIL®（ITインフラストラクチャ・ライブラリ）におけるインシデント管理は、サービス中断の時間を最小化し、業務への影響を迅速に取り除くことを目的としています。具体的なプロセスは下記5ステップになります。
「検知と記録」
「分類と優先順位付け」
「調査と診断」
「解決と復旧」
「インシデントのクローズ」
これらのプロセスを明確化し、関係者間で共有することで、インシデント発生時の対応スピードを高め、再発防止策の構築を容易にします。また、ITIL®に則った管理プロセスは業務の透明性を向上させ、継続的なサービス改善にもつながります。
インシデント管理をしっかりと行うことで、様々な各担当者にメリットがあります。
現在は様々なサポートがありますので、そういったものを活用しながら、インシデント管理のメリットにつなげていく必要性があるでしょう。
インシデント管理のメリットは、ナレッジベースが適切に管理されていなければ効果が期待できません。そのため、データに漏れや抜け、ミスがないかなどを注意する必要性があります。
「サービス担当者とマネージャー」だけでなく、「ユーザー」にとっても有益であり、迅速な対応が求められる重要な業務の1つが、インシデント管理です。
サービス担当者とマネージャーは、過去のデータを管理することで、迅速で効率的な対応ができるようになります。
また業務改善、顧客の満足度の向上にもつながるので、わかりやすいメリットではないでしょうか。
またユーザーのメリットは、インシデントが発生しても迅速な対応をしてもらえる結果、システムやサポートを信頼することができます。
信頼のあるサポートは愛用され、リピーターもできるでしょう。
それぞれにどのようなメリットがあるのか、ここで説明します。
ユーザーサポート担当のメリットは、過去のデータを一元管理することでインシデント管理を効率化できることです。
迅速な対応ができるようになり、業務改善や顧客の満足度の向上にもつながるでしょう。
ナレッジベースの情報が分類されているので、無駄なエスカレーションも減らすことができます。
マネージャーのメリットは、日常的な対応をユーザーサポート担当者に任せられます。
毎回マネージャーがエスカレーションする必要性がなくなり、業務が効率的になるのです。
そのため、マネージャーはインシデントの分析をする時間が確保でき、問題管理へつなげることができるでしょう。
それによりシステムやサービスの品質を向上させることにもなります。
インシデントが発生した時に正確で的確なサポートを受けることができます。
それによってスムーズに業務を再開できるでしょう。
またシステムやサポートを信頼でき、安心感を持つことができます。そのようなユーザーは長く愛用したり、リピーター顧客になる可能性が高くなるのです。
実際にインシデントへの対応が完了した後に必要な取り組みについて解説します。
インシデント対応後に不可欠な取り組みの一つが、ナレッジベースの構築です。過去のインシデントの発生原因、対応方法、復旧プロセスをドキュメント化し、社内で共有可能な形で蓄積することで、再発時に迅速に対応できるようになります。ナレッジベースが整備されている企業ほどインシデントの収束が早く、業務への影響も最小限に抑えられる傾向があります。また、新入社員や異動したメンバーでもスムーズに対応できる環境を整えることができ、組織のナレッジ共有と人材育成にも寄与します。
インシデント対応後には、運用方法や対応オペレーションルールの策定が重要です。インシデントが再発した場合に備えて、誰が何をいつまでに行うべきかを明確にルール化しておくことで、対応時間を大幅に短縮できます。オペレーションルールには、具体的な連絡経路や責任者の役割分担、報告手順、緊急対応フローを記載します。さらに、ルールを定期的に見直し、実際のインシデント対応時の課題や改善点を随時反映することで、より効果的な運用体制を構築できます。
インシデントの管理に関して、よくある悩みをこちらにまとめています。
様々なインシデントの発生だけでなく、複雑化したシステムの導入による予期せぬトラブル、外注することでのコスト増加、どのように改善していくのかわからない、など誰もが感じる悩みではないでしょうか。
似たような悩みを持っている人は、参考にしてみてください。
ITシステム運用では、複数事業者のクラウドシステムを混在させて利用していたり、利用するサービスそのものが多岐に渡っており、把握するのも難しい、などの傾向があります。
複雑化してしまったことで、予期せぬトラブルが増えたり、様々なアラートに対応しなくてはいけなくなりました。
そうなった時、大量の情報の中に緊急性の高いものや、重要なものが埋もれてしまい、インシデントを見落とす可能性もあります。
顧客の期待値も高まっており、迅速なレスポンスを希望するのが当たり前、24時間365日が当たり前に求められているのです。
その中でどれだけ迅速に対応できるか、インシデントの解決ができるかは難易度が上がっています。
システム運用と保守について詳しく知りたい方は「システム運用・保守と管理の違いや業務内容、課題点と解決策を解説」の記事をご覧ください。
外注する場合、インシデント対応を請け負う業者の計算によって、コストが下がりにくい状態があります。
必要サーバー台数など多く所持している会社は、特にコストがかかるでしょう。
外注の場合、サーバー台数だけではなく、そこにいる人員の数も関係します。
ですが、人員が少なくなるとインシデントの対応可能人数や時間が減ってしまいます。
人員不足によってインシデントの対応ができなかった、となると会社の信用を失う可能性にもつながってしまうのです。
それらを解決するために、運用システムには多くの人数を確保しておかなければいけません。
まず運用プロセスを改善するために、このような情報が必要になります。
など細かい時間の測定をした上での、情報収集が必要です。
様々な情報を駆使して運用プロセスの改善を行うためには、自社の運用プロセスを定義した上で仕組みを整備し、自社で必要な測定をする必要性があります。
そこで出た測定時間などの情報をもとに、改善する必要性があるのです。
現場によって程度は違いますが、抱えている問題はどこも似通っています。これらの悩みを解決できる手段があればいいと思いませんか？
現場が抱えているさまざまな悩みを自動化し、システム運用担当者の手を介することなくある一定の処理まで行います。
今まで担当者が手動で行っていた業務の一部を自動化することで正確で確実な処理を実行し、担当者がより優先順位の高い業務に集中できる環境を整えていきます。
結果的に、システム運用が安定し、安定した運用が継続的に行えることでコストの低減も図っていくことが可能です。
SHERPA SUITEのSHERPA-IRとSHERPA-SMは、どちらも現場のシステム運用を支えるシステムで課題解決の手段の一つとなります。
インシデントの対応は時間勝負です。一般的な現場では手順書の見直しなど、操作に関する改善は行われていても、運用を含めて改善されていません。
インシデント発生から完了までは様々なステップがあり、担当者に頼った運用をしているのが実情ですが、作業が煩雑で多くなり時間がかなりかかってしまいます。ミスも誘発しやすい環境となり、リスクも増大してしまっているのが現実です。
1次的な運用対応プロセス業務をSHERPA-IRで自動化することで時間と労力を大幅に簡略化し、担当者が迅速で確実な復旧に取り組むことができます。
担当者が迅速に復旧作業できることで、結果的に安定したシステム運用にも繋がります。
他にも、問合せメールから情報を拾い、フィルタリングしてRPA(ロボットプロセスオートメーション)と連携するなどのカスタマイズも可能。オペレーションの自動化で、効率化・高品質化・コスト削減を実現します。
SHERPA-SMはインシデント管理から問合せ管理までを担当します。SHERPA-SMには3つのメリットがあります。
インシデントの通知が来ると、SHERPA-SMはチケットとして自動登録します（アラートメールなどの集約はSHERPA-IRが行います）。人手による入力の手間を大幅に削減し、登録漏れやヒューマンエラーを未然に防ぐことができます。
チケットには独自のIDが割り振られるので、対応するスタッフが替わっても素早く応答することができます。すべての記録はSHERPA-SMに残るので、履歴やノウハウをチームで共有することができ、業務改善と生産性向上に活用することも可能です。
チケットには担当者情報が割り当てられ、担当者はリストボックスを設定することで自動で通知メールを送れます。これは、担当者間の“お見合い遅延”防止に効果を発揮します。アサインされた担当者は、通知メールに記載されたURLをクリックすればチケットにダイレクトに接続できます。チケットは一括で管理されるため、漏れも生じにくくなります。
他にも問合せ管理機能、インシデントの進捗状況を視覚化できるガントチャート、定期業務をチケットによって指示してくれる機能など、SHERPA-SMにはインシデント管理を効率化する機能が満載されています。
