Close

ベロシティの高いチームのためのインシデント管理

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

Nick Wright、Atlassian サービス オペレーション マネージャー

はじめに述べておきたいことは、現場にいるサポート担当者はあらゆるビジネスの陰の英雄であるということです。

あらゆるビジネスです。

技術サポートはサービス業とみなすべきであり、優れたサービスを提供するエージェントには顧客がチップを置けるようにするべきだと真剣に考えています。私なら、課題を笑顔ですばやく解決してくれた優れたサポート担当者全員に、喜んでチップを置きたいと思います。そうできればの話ですが。

ここで横道に逸れますが、この記事をご覧になっている方はまず間違いなくヘルプ デスク チームのマネージャーやメンバーでしょう。そして、おそらく今は狂騒状態にあり、それに関連する影響もあるのでしょう。ですので、まずはそれを何とかしてから、IT インシデント管理プロセスを制御しましょう。

ただし、インシデント管理について詳しく見ていく前に、一般的な用語に関する認識を揃えておきましょう。

ITSM とインシデント管理

IT 業界に身を置いているのであれば、ITIL、ITSM、インシデント、問題についてよくご存じでしょう。しかし、認識を揃えるために、Atlassian でこれらを使用する場合の定義をここで簡単に紹介します。

ITIL (IT インフラストラクチャ ライブラリ) は、ITSM の一連のベスト プラクティスです (プレイブックのようなものと考えてください)。

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

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

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

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

さて、なぜインシデント管理を行うのでしょうか? なぜインシデント管理は ITSM の世界の一部ですらあるのでしょうか?

答えはその影響にあります。調査によると、重大なインシデントが発生すると、システムがダウンしている 1 時間ごとに 10 万ドルから 30 万ドルのコストがかかります。

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

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

インシデント管理ワークフロー

ITIL フレームワークを使用して、適切なチケット処理の大まかな概要を説明しますが、他の多くの一般的なフレームワークでも、使われる専門用語は少し異なるだけでほぼ同様のコンセプトで説明できます。

インシデント管理の鍵は、優れたプロセスを設定して、それに従うことです。

それでも困難なように思えるかもしれませんが、良い点は、何千もの他の IT サービス チームの経験から学べるということです。

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

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

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

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

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

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

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

インシデントの分類

次の 2 つのステップ、カテゴリー化と優先順位付けは、どちらも重要ですがよく見過ごされます。ここが、私が使用してきた、より「健全な」サービスデスクが他と大きく異なる点です...まあ、それほどではありませんが。

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

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

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

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

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

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

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

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

応答

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nick Wright
Atlassian サービス オペレーション マネージャー

チーム、そして私は、Atlassian のクラウド アプリケーションとインフラストラクチャが確実に最高の状態で機能するように努めています。急成長を続けながら、これを実現する方法をぜひ共有したいと思っています。ニュージーランド出身であるという言語的なハンデはありますが、フィッシュ & チップスをきちんと発音できますよ。プライベートでは、サイクリング、ゲーム、妻と可愛い幼い娘と時間を過ごしています。