インシデント管理

Jira Service Deskを使用する IT チームのためのベストプラクティス

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

robotsnoindex

インシデント モデルは、サービスデスクがサービスの中断や停止について調査、記録、解決する際に役立ちます。Information Technology Infrastructure Library (ITIL) のインシデント管理ワークフローは、ダウンタイムおよび悪影響の削減を目標としています。 

インシデント管理は短期ソリューションに重点を置いています。再発するインシデントまたは根本的な問題を管理するには、「IT サービスデスクで問題を管理する」を参照してください。

IT Service Desk テンプレートにはインシデント管理ワークフローが組み込まれています。このワークフローを使用することで、確実にインシデントを記録、診断、および解決できます。このワークフローから開始して、ビジネスニーズに合わせて適宜変更を加えることをお勧めします。

適切に管理されていればインシデントレコードは以下を明らかにできます。

  • 欠落しているサービス要件
  • 潜在的な改善点
  • 今後必要なチームメンバー研修

このページでは、Jira Service Desk を使用してインシデントを管理するためのベストプラクティスをいくつか紹介します。ITIL の推奨事項を最適な形でビジネスに生かす方法を習得する正式なトレーニングを探すこともできます。

このページの内容

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

IT Service Desk テンプレートは特定のリクエストをインシデントワークフローに関連付けます。このワークフローは、以下のインシデント管理プロセスを補完するため設定されています。このワークフローから開始して、使用していく中で特定のニーズに合わせて適宜変更を加えることをお勧めします。

ITIL インシデント管理プロセス (要約):

  1. サービスのエンドユーザー、監視システム、または内部の IT メンバーが中断を報告します。
  2. サービスデスクはインシデントを説明し、ログに記録します。また、サービス中断に関連するすべての報告を相互にリンクします。
  3. サービスデスクは日時、報告者名、およびそのインシデントの固有 ID を記録します。Jira Service Desk はこれを自動的に実行します。
  4. サービスデスクエージェントは、インシデントを適切に分類するラベルを付けます。チームはインシデント後のレビューの間と報告書作成でこれらの分類を使用します。
  5. サービスデスクエージェントは影響と緊急性に基づいてインシデントの優先順位を付けます。
  6. チームはインシデント、影響を受けたサービス、および可能な解決策を診断します。エージェントはインシデントの報告者と連絡を取り、この診断の完了を支援します。
  7. 必要に応じて、サービスデスクチームはインシデントを 2 次サポート担当者にエスカレーションします。これらの担当者は影響を受けたシステムを専門に修正する人々です。
  8. サービスデスクはサービスの中断を解決し、修正が成功していることを検証します。解決策は将来参照できるように完全にドキュメント化されます。
  9. サービスデスクはインシデントをクローズします。

チームメンバーは、重大なインシデントについてインシデント後のレビューを実施してください。これらの調査は以下の判定に役立つことがあります。

  • 欠落している要件
  • サービスレベルアグリーメントに対する潜在的な変更
  • 潜在的なサービス改善点または重点領域

Jira Service Desk の既定のインシデントワークフロー

リクエスト タイプを使用して、 インシデントと呼ばれる課題タイプにインシデントレポートを関連付けます。これにより、インシデントレコードがアトラシアンが推奨するインシデントワークフローに配置されます。

このワークフローは上記の基本プロセスに従います。ワークフローは、ビジネスのニーズに合うようにカスタマイズできます。

インシデントワークフローのカスタマイズ

  1. サービス デスク プロジェクトで、[プロジェクト設定]() > [ワークフロー] を選択します。
  2. Jira Service Desk のインシデント管理ワークフローというタイトルの項目で、編集アイコン (鉛筆) を選択します。
  3. ワークフロー エディターを使用して、ステップとトランジションを追加または編集します。

ワークフローの編集に関する詳細を読む

インシデント解決後のインシデント自動クローズ

IT Service Desk テンプレートには追加の SLA および自動化規則が含まれています。これらは連携して、エージェントによるインシデントの解決後 3 営業日でインシデントを自動的にクローズします。

障害の解決フィールドが設定されると、解決後のクローズまでの時間という名前の SLA が時間の記録を開始します。記録は、エージェントが解決フィールドをクリアするか、リクエストがクローズに移行した場合に停止します。

この SLA は表示、編集、または削除が可能です。

サービス デスク プロジェクト、[プロジェクト設定] () > [SLA] を選択します。

SLA について詳細を読む

解決後 3 営業日以内に自動クローズという自動化ルールが含まれています。このルールは、上記の SLA 超過があると、障害を解決済みからクローズに移行します。 

このルールは無効化または調整できます。

サービス デスク プロジェクトから、[プロジェクト設定] () > [自動化] を選択します。

自動化について詳細を読む

インシデントレコードを他の課題にリンクする

課題は相互にリンクできます。たとえば、インシデントレコードを問題報告または変更リクエストにリンクできます。

サービスデスク プロジェクト内の課題は他のプロジェクトや、他の Jira アプリケーション (Jira Software、Confluence など) にリンクできます。

たとえば、2 次または 3 次サポートメンバーが修正を行う必要がある場合、インシデントを Jira Software にリンクする必要がある場合もあります。以下にプロセスの概観を示します。

インシデントの原因が特定され、2 次または 3 次サポートメンバーが修正するために Jira Software でタスクを作成します。サービスデスクは、自動化規則を利用してカスタマーが最新の修正状況を確認できるようにすることが可能です。

インシデントレコードを別のプロジェクトの修正タスクにリンクする手順:

  1. インシデントレコードを表示します。
  2. さらに表示メニュー (•••) をクリックします。
  3. リンクを選択します。
  4. この課題フィールドで、is caused by を選択します。
  5. 課題フィールドにリンクしたい課題のキーを入力します。
  6. リンクを選択します。

サービスデスクにはリンク済み課題変更時に更新という自動化規則が組み込まれています。この規則は、リンク済み Jira 課題のステータスに関してインシデントレコードにコメントを付けます。したがって、開発チームでの修正の進行に応じてカスタマーは最新の情報を得ることになります。

この規則は、ニーズに合うように変更または拡張できます。たとえば、開発チームが Jira で課題を解決するとインシデントが自動的にクローズされるようにすることができます。または、開発チームが修正を完了したときにカスタマーに通知を送信できます。

リンクされた課題ルールを編集するには、次の手順を利用します。

  1. サービス デスク プロジェクトから、[プロジェクト設定] () > [自動化] を選択します。
  2. リンクされた課題の変更時に更新というルールの横にある [編集] を選択します。

自動化について詳細を読む

インシデントレポートの既定のフォームフィールド

Jira Service Desk では、カスタマーから収集する情報のフィールドをカスタマイズできます。さらに、エージェントが使用する情報のフィールドもカスタマイズできます。Jira Service Desk では、課題タイプのフィールドおよび画面を通じてこれを実行します。エージェントは、報告書作成または照会のためにフィールドを利用してインシデントの調査、評価、および分類を行うことができます。

既定では、エージェントのインシデントのビューには次のフィールドが含まれます。必要に応じてカスタムフィールドを追加できますJira のフィールドについて詳細を読む

 

フィールド名説明
要約リクエストの短い説明。
報告者リクエストの送信者。
コンポーネントリクエストに関連する IT インフラストラクチャーのセグメント。たとえば、「課金サービス」または「VPN サーバー」などです。これらはラベル、分類、およびレポートに使用されます。
添付ファイルリクエストに追加されるファイルまたは画像。
説明 リクエストの長く詳細な説明。
紐づく課題

リクエストに影響を与える、またはリクエストの影響を受けるその他のリクエストのリスト。ビジネスでその他の Atlassian 製品を使用している場合、このリストに、リンクされている開発課題が含まれる場合があります。

担当者リクエストの作業に割り当てられているチーム メンバー。
優先度リクエストの解決状況の重要性は、通常、ビジネスのニーズと目標に関係しています。優先度が影響力と緊急性によって計算されることもあります。
Labelsレコードの分類またはクエリに使用される追加カスタム ラベルのリスト。
リクエスト参加者リクエストに参加している追加のカスタマー (他のチームやベンダーの人々など) のリスト。参加者について詳細を読む
承認者リクエストを承認する責任のある人々のリスト。通常は、ビジネス、財務、または技術の連絡窓口担当者
組織リクエストの解決状況に関心のあるカスタマー グループのリスト。Jira Service Desk 内の組織に関する詳細はこちらをお読みください
影響インシデントの影響。通常は、サービスレベルアグリーメントに関連。
緊急度ビジネスにインシデントの影響が感じられる前に利用可能な時間。
保留中の理由インシデントが進行していない理由を示す短い説明またはコード。
製品分類リクエストが影響する IT 資産またはシステムのカテゴリ。
操作分類リクエストを遂行するために必要なアクションまたは機能の分類。
ソースインシデントが発生した資産またはシステム。

IT サービス マネジメント(ITSM)について

ITSM を成功させるために多くのヒントやコツを参照し、ワンランク上のサービス デスクを実現する方法を習得しましょう。「IT アンプラグドの ITSM リソース」を参照してください

最終更新日 2019 年 7 月 2 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.