インシデント管理とは

インシデントにより、一時的なダウンタイムからデータ損失まで、組織にさまざまな問題がもたらされる可能性があります。インシデント管理がうまくいった場合、あらゆる種類のインシデントをほぼシステム障害を経験せずに修正できる効率的で効果的な方法が得られ、組織は今後のインシデントに備えることができます。

インシデント管理は、もともとIT サービス・デスクから始まったもので、長い間 ITオペレーション（ITOps） とエンド・ユーザー間の主なインターフェースとして機能してきました。テクノロジーが進歩し複雑になるにつれて、組織のインシデントの特定や対応の見方も同様に進化してきました。こうした手法により、ユーザーの問題解決を支援するだけでなく、アプリの継続的なアップタイムを維持し、継続的な改善の取り組みを加速するためのプロセスにまで発展しました。

企業のITオペレーションにおけるインシデント管理は、 ITIL インシデント管理と呼ばれることが多く、ノートPCのクラッシュやプリンターのエラーから、Wi-Fi接続の問題やネットワークのダウンタイムまで、サービスや営業活動に影響を与える可能性のあるさまざまな問題に対応します。

ITSM（ITサービス管理）のフレームワークに基づくインシデント管理は 、ITSMサービスモデルの1つの側面として機能します。ITのインシデント管理は、システムやテクノロジーの構築ではなくユーザーに焦点を当て、アプリ、そしてセンサーやデスクトップPCなどのエンドポイントであっても、ITインフラストラクチャーを適切に運用し続けることを目的としています。

問題が発生したときの対応など、ITサービス管理内のIT部門にはさまざまな役割があります。こうした問題の重大度が、インシデントとサービス要求を区別しているものです。

サービス要求とは、簡単に言えば、ユーザーがアドバイスや機器など、何かを提供するよう求めることです。サービスには、パスワードのリセットや、デスクトップPCのメモリ増設などのサポートが含まれます。

一方、インシデントは、緊急性が高く、根本的なエラーで対応が必要なものを指します。

インシデントとは、サービスにおいてシステム障害を引き起こす予想外の事象のことで、問題とは、サービスにおいてシステム障害を引き起こす根本原因のことであり、一つまたは一連のインシデントの場合があります。

その違いは、修復および対応者の問題修復方法にあります。インシデント対応は事後対応型です。インシデント管理チームは警告を受信し、インシデントに対応します。しかし、問題に対応する際には、ITチームが根本原因を特定し修正します。問題管理では、さまざまな種類のインシデントやパターンを観察し、今後のインシデントをどのように防止できるかを理解して、事前対応型の手法を取ります。

DevOps チームは、ソフトウェアを構築、テスト、デプロイするためのより効率的な方法を見つけることに重点を置いていますが、そのためにはインシデントに迅速に対応する必要があります。ITILインシデント管理と同様、DevOpsインシデント管理はオペレーションを停止せずに問題を修正することを目的としています。 例えば、DevOpsチームが平均故障間隔（MTBF）のメトリクスが不十分であることを測定した場合、調査が必要な根本的な問題があることを示しています。

DevOpsはもともと継続的な改善を基盤としているため、事後分析および透明性が高く責任の伴わない文化に重点が置かれています。その目標は、システム全体の性能を最適化し、インシデント解決を効率化、迅速化して、今後のインシデントの発生を防ぐことです。

現代のITチームと同様、DevOpsチームでは、自動プロビジョニング、インシデントの優先順位付け、人工知能（AI）対応の根本原因分析ツールを使って、アップタイムを確保し、最も差し迫ったインシデントに最初に対応し、今後の問題をより迅速に解決する方法を学べます。（または元から発生するのを防ぎます）

一般的に、組織は対応チームが取るべき一連のイベントを文書化するインシデント管理プロセスを作成します。すべての利害関係者は、インシデント対応担当者、問題解決の処理時間、インシデントを上司にエスカレーションするタイミング、インシデントと解決方法を文書化する方法を知っておく必要があります。

プロセスが定義されると、インシデント管理ワークフローは通常、次のようになります。

1. インシデントの特定：  エンドユーザーがヘルプデスクにチケットを送信する場合や、自動アラートシステムが問題をチームに通知する場合を問わず、対応チームはシステム内の問題のレポートを受け取る方法が必要です。
   
   
2. インシデントの記録と分類：  インシデント・レポートをインシデント・ロギング・システムに入力し、対応すべきスタッフ・レベルなどの優先順位の割り当てなどが含まれます。例えば、レベル1のインシデントは、通常、経験の浅い新人スタッフが担当しますが、レベル2やレベル3のインシデントは、解決がますます難しくなるため、経験豊富な対応担当者が必要となります。
   
   
3. 問題の封じ込め：  セキュリティ・インシデントの場合、対応チームはDDoS攻撃かデータ侵害かを問わず、問題を封じ込めるためには迅速に行動しなければなりません。いかなる場合でも、チームはインシデントがさらに拡大してシステムに影響を与えることがないようにする必要があります。
   
   
4. インシデントの診断：  この段階では、トラブルシューティングが関係します。対応チームは、ナレッジ・ベースやChatOpsツールを使って、考えうる原因を推定し、時間を節約できます。
   
   
5. インシデントの解決： 原因が特定できると、チームは追加メモリーのプロビジョニングやネットワーク停止への対応など、インシデントへの対応作業に着手します。
   
   
6. インシデントのクローズ、レビュー： 今日のデジタル環境における信頼性と可用性を向上させる上で、事後検証は重要な要素です。このデータにより、組織内の知見を蓄積できるだけでなく、 機械学習 や AI 対応ツールで使用して、インシデントをより迅速に特定したり、インシデントが発生する可能性がある場合に通知を作成したりするのに役立てることもできます。徹底的なレビューは、組織がより効果的なインシデント修復手順を実施するのに役立ちます。

すべての組織は問題を修正し、インシデントを解決する必要があります。営業活動にはそれが不可欠だからです。しかし、事業に大きなシステム障害をもたらすことなく迅速に対応できる効果的なインシデント解決ツールとチームを編成することには、明らかなメリットもあります。そのメリットは、以下のとおりです。

ITオペレーションはますます複雑化しており、これは組織が通常の営業活動のなかで多くのアプリケーションに依存しているからでもありますが、インシデント対応ツールとオートメーションがこれまで以上に重要になってきています。

最も一般的なインシデント管理ツールには、次のようなものがあります。

• 監視ツール：  停止状態を識別し、警告を出して、インシデントを診断します。 また、監視ツールを使うことで 、DevOpsチームが他に時間を割けるようになるため、ソフトウェアのライフサイクルを適切に管理でき、コストが削減できます。
  
  
• サービス・デスク： ユーザー向けチケットの送信、サービス・デスク・チームとのチャット、チケットの進捗状況の監視、セルフサービス業務の実行のための場所です。通常、サービスデスクは、優先順位付けや分類などの主要なインシデント管理タスクを可能にする管理システムを通じて実行されます。
  
  
• AlOpsプラットフォーム： AIOpsでは、ログと履歴データを使って、適切な意思決定、スマートなリソース割り当て、迅速なインシデント対応のためのコンテキストを提供できます。
  
  
• VDocumentation: 環境への変更を自動的に文書化するスクリプトを使って、事後分析のためにインシデントを簡単に記録できます。例えば、チームはPowerCLIスクリプトを月次スケジュールで実行するように設定して、インシデントを記録して詳細な分析を行えます。