IT オペレーションのプロのようにインシデント管理プロセスに習熟する

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

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

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

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

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

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

インシデントの分類

These next two steps–categorize and prioritize–are both critical and commonly overlooked. They also separate the more “sane” service desks I’ve worked with from the...well, not so much.

最初に、論理的で直感的なカテゴリ (必要に応じて、サブカテゴリ) を、すべてのインシデントに割り当てる必要があります。そのように割り当てないと、後でデータを分析して傾向やパターンを探せなくなります。これは、効果的なインシデント管理と将来のインシデント防止の重要な部分です。

基本的に、このことは常に念頭に置いてください。そして、インシデント カテゴリを簡単にカスタマイズできないもので IT サービス デスク ソリューションを妥協しないでください。

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

次に、すべてのインシデントに優先順位を付ける必要があります。

インシデントに優先順位を付けるには、まず、業務への影響を評価します。影響を受けるユーザーの数と、財務、セキュリティ、コンプライアンスへのインシデントの潜在的な影響の両方を考慮して、インシデントによって生じる問題の程度と業務に対する解決の緊急性を判断します。

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

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

これらの優先度を設定したら、オープンしているすべてのインシデントを優先順位順に解決します。ほとんどの組織では、優先度ごとに明確なサービス契約を設定しているため、顧客は対応と解決がどの程度迅速に行われると期待されるかを把握できます。このように実践することを強くお勧めします。

応答

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

初期診断
これを、病院が新しい患者に行うトリアージ機能として考えてみてください。サービス デスクの従業員は、考えられる問題について迅速な仮説を打ち立てることにより、修正するか、適切な手順に従うか、解決のための適切なリソースを集めるかのいずれかに着手できます。

ナレッジ ベースと診断マニュアルは、このステップにおいても有効なツールです。

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

インシデントのエスカレーション
エスカレーションは悪い意味に聞こえますが、そうではありません。

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

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

最前線のサポート担当者は、情報の収集時にすでにある程度調査しており、診断に成功し、エスカレーションする必要なくインシデントの解決すら終わっているかもしれません。

その場合は、次の数ステップ、解決と復旧、およびインシデントのクローズを直接省略します。

それ以外の場合は、レベル 2 と 3 のサポートにエスカレーションすると調査と診断が行われます。または、解決をサポートするために外部リソースまたは他の部門のメンバーに参加してもらいます。

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

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

結論：ステップは省略しない

数人のサービス デスク アナリストしかいない場合には、このプロセスが不必要に堅苦しく思えるかもしれません。しかし、チーム構造に関係なく、インシデントのライフサイクルは依然として同じです。

たとえば、サービス デスク アナリストが 1 人しかいないため、レベル 3 のサポートがないとします。しかし、サービス デスク アナリストの知識を上回るインシデントには、誰かが対応しなければなりません。それは、チーフ エンジニア、社外コンサルタント、あるいはあなたであるかもしれません。

そのため、レベル 2 またはレベル 3 のサポート担当者が自社にいるとすれば、その役目は、あなたか同僚のエンジニアが果たすことになります。

つまり、ITIL はセマンティクスがすべてのように見えるかもしれませんが、その考えに囚われてはなりません。組織階層とプロセス ワークフローを、前に説明したような簡単な IT サービス管理フレームワークに適合させる簡単な方法を探してください。

そうすることで、はるかに優れたカスタマー サービスを提供するとともに、より多くの価値をビジネスに戻せます (その上、あなたの狂騒状態も落ち着かせられるでしょう)。

最後に、いくつかの注意事項を示します。

• すべてのインシデントを記録します。インシデントに一意の番号を付けます。そして、重要な詳細 (日時や説明など) を中央のヘルプ デスク システムで捕捉します。
• インシデントの更新情報を伝える社内外の対象者が多い場合は、インシデント コミュニケーションのステータス ページを検討します。
• すべてのインシデントにカテゴリを割り当てます (必要に応じてサブカテゴリも割り当てます)。
• すべてのインシデントに優先度を付けて、すべての優先度に SLA を設定します。
• インシデント指揮官、重大なインシデント担当マネージャー、コミュニケーション リードなど、インシデント対応者のロールを明確に定義します。
• 可能な限り、ナレッジ ベース記事とインシデント診断スクリプトを最前線のサポート チームに提供して、インシデントを迅速に解決できるようにサポートします。
• サービス デスクがインシデントの進捗状況、ルーティング、ステータスを常に制御できるようにします。
• インシデント データは、捕捉するだけではなく分析します。インシデントの量を削減してリスクを軽減する上で役立つ傾向、パターン、根底にある潜在的な問題を探します。

著者について