Close

ベロシティの高い ITSM の準備

インシデント管理とは

インシデント管理は、予期しないイベントまたはサービス中断に応答して、サービスを運用状態に戻すプロセスです。ITIL (IT Infrastructure Library) によると、「インシデント管理プロセスにより、通常のサービス運用をできるだけ早く復元し、業務への影響を最小限に抑えられます」と報告されています。

インシデントは、サービスの質を損なう、または低下させる (または脅かす) あらゆる種類の予期しないイベントです。ビジネス アプリケーションのダウンは、インシデントです。停止はしていないが著しくパフォーマンスが落ちているウェブ サーバーもインシデントです。動作が遅いために、生産性を低下させています。さらに悪くなると、完全な障害を引き起こす大きなリスクをもたらします。

全員で情報を共有するために、関連する用語の簡単な定義をいくつか紹介します。

ITSM (IT サービス管理) IT サービスの作成、サポート、管理を行うための一般的なアプローチです。ITSM のコア コンセプトは、IT をサービスとして提供する必要があるという信念です。また、ITSM のコア プラクティスの 1 つは、インシデント管理です。

ITIL は、ITSM 一連のベスト プラクティスです (プレイブックとして考えてください)。

問題は、1 つ以上のインシデントの背後にある未知の根本原因です。ネットワークが遅くなり、ビジネス アプリケーションがダウンしている上記のインシデントでは、ルーターの構成ミスがその両方の背後にある根本的な問題である可能性があります。

ITSM プラクティスとしてのインシデント管理の重要性

組織が今日依存しているすべてのソフトウェア サービスを考えると、潜在的な障害点はこれまで以上に多く存在します。また、インシデントの影響は大きなものになる可能性があります。調査によると、重大なインシデントは、システムがダウンするたびに 30 万ドルかかる可能性があります。一部の Web ベースのサービスでは、その数が大幅に多くなる可能性があります。

インシデント管理プロセスを明確に定義することで、これらのコストを大幅に削減できます。明確に定義されたプロセスのメリットには以下が含まれます。

  • より早いインシデント解決
  • インシデントに起因する組織のコストまたは収益損失の削減
  • インシデント発生中のコミュニケーション (内外部の両方) の向上
  • 継続的な学習と改善

インシデント管理プロセス

インシデント管理の鍵は、優れたプロセスを設定して、それに従うことです。それでも困難なように思えるかもしれませんが、良い点は、何千もの他の IT サービス チームの経験から学ぶことができるということです。

成長する多忙な IT 組織の主な間違いの 1 つは、一からやり直してプロセスをゼロから作成することです。ベスト プラクティスを利用して、チケットを処理するために自社製の開発ツールを構築する時間を無駄にしないでください。

インシデント管理プラクティスの重要な手順の概要を次に示します。

インシデントの特定と記録

インシデントはどこからでも発生します。従業員から報告を受けることもありますし、ネットワーク ハブの設置ミスと天井の雨漏りが重なった場合には、文字どおり天井タイルから膝の上に落下することだってありえます(私たちの経験を話しているわけではありませんよ ...)。

どこから報告を受けたかに関係なく、最初の 2 つのステップはシンプルです。誰かがインシデントを特定した後に、誰かがそれを記録します。

サービス デスク経由ですでに記録されているインシデントを受信した場合、これらの最初の 2 つのステップはすでに完了しています。インシデントについて電話を受けた場合や E メール、テキスト、または伝言で報告を受けた場合は、それをサービス デスクに適切に記録するのは、サービス デスク チームの仕事です。

通常、これらのインシデント記録 (すなわち、チケット) には以下の内容が含まれます。

  • そのインシデントの報告者の名前
  • インシデントが報告された日時
  • インシデントの説明 (何がダウンしている、または適切に動作していないか)
  • 追跡するためにインシデントに割り当てられた一意の識別番号

インシデントの分類

論理的で直感的なカテゴリ (必要に応じて、サブカテゴリ) をすべてのインシデントに割り当てます。そのように割り当てないと、後でデータを分析してトレンドやパターンを探せなくなります。これは、効果的な問題管理と将来のインシデント防止の重要な部分です。また、インシデント カテゴリを簡単にカスタマイズできる ITSM サービス デスク ソリューションを選択してください。

インシデントの優先順位付け

すべてのインシデントに優先順位を付ける必要があります。まず、業務への影響を評価します。影響を受けるユーザーの数と、財務、セキュリティ、コンプライアンスへの潜在的な影響を考慮します。これは、インシデントによって生じる問題の程度と、企業がそれを解決しなければならない緊急性を判断するのに役立ちます。

ここでのベスト プラクティスは、インシデントが発生する前に重大度と優先度を定義することです。これにより、インシデント マネージャーが優先度を迅速に測定しやすくなります。

優先度について確定が持てない場合は、高い方の優先度を選択します。何か重大なことを見落とすよりは、慎重すぎる方が無難です。

これらの優先度を設定したら、未解決のすべてのインシデントを優先順位順に解決します。ほとんどの組織では、優先度ごとに明確なサービス契約を設定しているため、顧客は対応と解決がどれくらい早く行われるかを把握できます。

応答

インシデント対応はかなり広範な用語です。ですので、インシデントの特定、カテゴリ化、優先順位付けが済んだ後で、最も実行する可能性の高いステップにさらに分割してみましょう。

初期診断

これを、病院が新しい患者に行うトリアージ機能として考えてみてください。サービス デスクの従業員は、考えられる問題について迅速な仮説を打ち立てることにより、修正するか、適切な手順に従うか、適切なリソースを集めるかのいずれかに着手できます。ナレッジ ベースと診断マニュアルは、このステップにおいて有効なツールです。

最初のエージェントが、自身の初期診断に基づいて利用可能なナレッジとツールを使用してインシデントを解決できた場合は、ここで解決済みとなります。そうでない場合は、エスカレーションします。

インシデントのエスカレーション

最前線のサポート チームは、最も一般的なインシデントの多くをエスカレーションせずに解決できるはずです。しかし、解決できない問題の場合、目指すべき目標はサポートが即座に対応に取りかかり、迅速にインシデントを解決できるよう、適切な情報を収集して記録することです。

調査と診断

ITIL は、これを独自の 1 ステップと見なしています。実際には、インシデントのライフサイクル全体を通じて発生します。

最初のサポート担当者は、情報の収集時にすでにある程度調査しており、診断に成功し、エスカレーションする必要なくインシデントの解決すら終わっているかもしれません。その場合は、次の数ステップ、解決と復旧、およびインシデントのクローズを直接省略します。

それ以外の場合、エスカレーションすると調査と診断が行われます。または、解決を支援するために外部リソースに参加してもらいます。

解決と復旧

最終的に、そして理想的には設定されたサービスレベルアグリーメント (SLA) で定めた時間内に、診断を行い、インシデントの解決に必要なステップを実行します。一部の修正 (バグのパッチなど) は、適切な解決策が特定された後も、テストおよびデプロイメントが必要な場合があるため、復旧は単に運用が完全に元どおりになるまでにかかる時間を意味します。

インシデントのクローズ

その後、インシデントはサービスデスクに戻され (エスカレーションされた場合)、クローズされます。品質を維持してスムーズなプロセスを確保するため、インシデントのクローズは、サービスデスクの従業員のみに許可されています。インシデントオーナーはインシデントの報告者に解決が満足のいくものであったことを確認する必要があり、確認できたらインシデントをクローズできます。

概要

インシデント管理プロセスは、特に小規模な組織に属している場合、不必要に堅苦しく見えるかもしれません。しかし、チーム構造に関係なく、インシデントのライフサイクルは同じままであり、エスカレーションが必要になることがよくあります。ステップを省略しないでください。

インシデントは起こってしまうものです。しかし、強力なインシデント管理プロセスは、その影響を軽減し、サービスを迅速に復元できることを意味します。