SLA を設定する
良いサービスとは、顧客が何度も利用するサービスであり、良いサービスの主要な要素は応答性です。
Jira Service Management では顧客の課題の処理時間に関する目標を設定することで、チームに常に時間を意識してもらえます。これらの目標が顧客との契約で設定されている場合は、SLA (サービス レベル アグリーメント) として認識される場合もあります。
SLA は次のような項目の進捗を追跡します。
- 2 時間以内にすべてのリクエストに応答する。
- 24 時間以内に高優先度のリクエストを解決する。
SLA の表示方法
さまざまなシナリオでエージェント ビューとカスタマー ポータルに SLA がどのように表示されるかを確認するには「チームへの SLA の見え方」をご参照ください。
SLA の設定方法
Jira 管理者またはプロジェクト管理者は、[プロジェクト設定] > [SLA] で SLA を設定できます。
SLA を設定する際は、次の 3 つの項目を選択します。
- SLA を表示できるユーザー: カスタマー ポータルのエージェントまたは顧客
- 時間メトリック。これは、いつ、どのように時間を測定するかを定義します。
- 目標。これは、達成目標を定義します。
SLA を表示できるユーザーを選択する
この機能を使用するには、Data Center ライセンスが必要です。
初期設定では、SLA はエージェントにのみ表示されます。カスタマー ポータル上の顧客に対しても、各 SLA を個別に表示するように選択できます。顧客には SLA のステータスとその時間メトリックが表示されますが、目標そのもの (たとえば 5 日以内) は表示されません。
時間メトリックの設定
時間メトリックは、課題のライフサイクルにおける 2 点間の時間を追跡するストップウォッチのように機能します。例えば、課題が作成された時点で計時を開始し、顧客の応答を待機している間は一時停止し、課題が解決された時点で計時を終了します。
Jira Service Management は事前構成済みの時間メトリックを備えており、最も一般的な IT 要件をカバーしていますが、必要に応じてこれらを変更、または独自のメトリックを作成できます。
新しい評価基準を作成するには、サービス デスク プロジェクトのサイドバーから、[プロジェクト設定] > [SLA] > [SLA の作成] を選択して、以下の条件を入力します。
| 条件 | 説明 |
|---|---|
| 名前 | この名前 (例えば、解決までの時間) は、課題の [SLA] セクションでエージェントに表示されます。エージェントはこの名前を確認し、測定対象を認識できます。SLA メトリックの名前を保存した後は変更できません。 |
| Start | これらのいずれかが発生した場合 (例えば、課題が作成されたなど)、SLA に対する計時が開始されます。 |
| 一時停止 | これらの条件の少なくとも 1 つ (例えば、ステータス: 顧客の応答待ちなど) が課題に適用される場合は、SLA に対する計時は行われません。 |
| 停止 | これらのいずれかが発生した場合 (例えば、解決状況: 設定など)、SLA に対する計時が終了されます。 |
計時の開始、終了、および一時停止について、複数の条件を設定できます。次に示すのは、[解決までの時間] の SLA の条件セットの例です。
ワークフロー全体を通じてタイム カウンターを開始および停止することでより複雑な SLA を作成する方法を確認するには、「例: 複数のサイクルで構成される SLA を作成する」を参照してください。
目標の設定
SLA メトリックの [目標] セクションでは、追跡する課題のタイプ (課題)、課題を解決するまでの時間 (目標)、チームの稼働時間 (カレンダー) を選択します。
設定する目標の例を以下に示します。
- 24 時間以内にブロッカー課題を解決する。
- ビルド エンジニアリング チームにより作成されたブロッカー課題を 12 時間以内に解決する。
- 経理チームにより作成されたブロッカー課題を 36 時間以内に解決する。
[新しい SLA] または [SLA の編集] 画面では、次のフィールドに必要事項を入力して目標を定義します。
| フィールド | 説明 |
|---|---|
| 課題 | Jira クエリ言語 (JQL) を使用して、特定の課題基準を入力できます。課題のライフサイクルを通じて比較的一定に維持される基準に基づいて目標を設定します (例えば、ワークフロー ステータスではなく、課題の優先度)。 |
| 目標 | 事前に設定した SLA 条件に対する目標時間をここで指定します。時間の単位を使用して SLA 目標を指定する場合、Xh Ym (3h 30m など) と入力します。SLA 目標は日数ではなく、時間および分単位で設定します。 |
| カレンダー | SLA に対して計時が可能な場合、カレンダーで稼働時間を指定できます。 |
重要度の順に目標をドラッグして移動できます。このリストで最初に一致した目標基準に対して課題の追跡が行われます。
稼働時間の設定
Jira Service Management では、休憩、休日、週末を含む稼働時間に対応するカレンダーを作成できます。このカレンダーを SLA に割り当て、チームが作業していないときは計時を止めるようにできます。
この方法については、「SLA カレンダーの作成と編集」を参照してください。
SLA カレンダーは各サービス プロジェクトに固有です。稼働時間が 9-5 時の SLA カレンダーによる SLA 設定の一例については「例: 基本 SLA の作成」をご参照ください。
SLA 設定を行う
Jira 管理者は、権限、フォーマット、その他の SLA 設定を管理できます。
SLA を設定するには、次の手順に従います。
[管理] > [アプリ] の順に移動します。
[SLA 設定] を選択します。
3. 管理するセクションを見つけます。
4. [設定] を選択します。
SLA デバッグ ログ イベントをクリーンアップする
Jira Service Management 課題イベントがトリガーされるか、SLA が作成または削除されるたびに、Jira Service Management は対応する SLA を更新します。SLA デバッグ ログ機能は、その変更を反映するエントリをデータベース (AO_54307E_SLAAUDITLOG と AO_54307E_SLAAUDITLOGDATA の各テーブル) に作成します。
Jira 管理者は、SLA デバッグ ログのクリーンアップ方法を決定できます。また、データベースからイベントが削除される頻度を選択できます。
スレッド処理を設定する
Jira Service Management のパフォーマンスを向上させるため、SLA 計算はバックグラウンド タスクで実行します。このコンテキストでは、これらのタスクは並行実行のスレッドによって実行されます。
SLA 計算の処理方法とスレッド数を設定できます。
処理方法 | 説明 |
|---|---|
マルチスレッドのシリアライズ処理 (スレッド数は設定可能) | この処理方法を使用することをお勧めします。 バージョン 4.21.0 で導入されたこの新しい処理方法は自己修復に対応して、特に Jira がマルチノード クラスタ モードで実行されている際にクラスター効率と信頼性が高くなります。 この方法では、どの Jira ノードでも保存されているすべてのイベントを処理できます。インメモリ処理モードとは異なり、この方法ではアプリケーションを再起動しても SLA 処理に影響しません。クラスターにノードが 1 つしかなくても、中断が発生した場合に SLA 計算は中断された場所から再開されます。 データベースに保存されている履歴イベント データに基づいて、課題に対してイベントが発生した順序で SLA が計算されます。この方法におけるスレッド プールは 1-20 個のスレッドの範囲で設定できます。 |
マルチスレッドのインメモリ処理 (スレッド数は設定可能) | この方法は従来の処理モードと見なされます。この方法におけるスレッド プールは、シリアライズ処理方法と同様に 1-20 個のスレッドの範囲で設定できます。 このモードでは、処理されたすべてのイベントがそれらの発生元ノードにバインドされます。アプリケーションが 1 つのノードで停止すると未処理のイベントはすべて失われて (5.0 より前のバージョンでは) 手動で再構築されるまで、(5.0 以降のバージョンでは) 同じ課題に対して別のイベントが発生するまで、SLA 履歴に追加されません。 |
バックグラウンド処理なし (スレッド数は設定不可) | この方法では、すべての処理がリクエスト スレッドで実行されて、SLA 計算が終了するまで応答 (ユーザー フィードバック) がロックされます。この処理モードを選択すると、課題の作成、コメントの作成、課題のトランジションなどのアクションの体感的なパフォーマンスが大幅に低下する可能性があります。 |
SLA 計算の結果として、情報をフェッチするためにデータベースに対してクエリが実行されます。データベースでは、同時にアクティブにする接続を制限するために接続プールが使用されます。バックグラウンド処理がない場合は HTTP スレッドで動作するため、プール数は制御されません。そのため、負荷がかかるとデータベース接続プールが急速に枯渇する可能性があります。データベース接続の詳細についてご確認ください。
SLA スレッド数を設定する
マルチスレッドのシリアライズ処理またはマルチスレッドのインメモリ処理のいずれかの方法を選択した場合は、SLA 計算のスレッド プール数を 1-20 個の範囲で設定できます。スレッド数の値は、プロセッサーを再起動しなくてもすべてのノード全体で同期されます。
ノードあたりの SLA スレッドの既定数は 5 に設定されています。ただし、SLA 計算が課題の更新に追いついていない場合は、推奨されたマルチスレッドのシリアライズ処理方法によって SLA スレッド数を少しずつ増やしながらシステム応答を確認することをお勧めします。
SLA の更新
既存の SLA 設定を変更する場合は、次のルールに従います。
すでに完了しているサイクルは再計算も変更もしません。リクエストが開始と停止の各条件を満たすとサイクルが完了します (設定とイベントによっては、同じ SLA の別のサイクルが開始される場合があります)。
継続中の SLA を再計算して新しい設定と指標を測定します。
設定を変更すると、継続中の SLA が完了するか完全に破棄される場合があります。これは、以前の Start または Stop の各条件を削除、または別の条件に変更したことによって完了がトリガーされた場合に発生する可能性があります。前述のように、継続中の SLA は新しい設定を使用するように再計算されます。
単一の課題に対する SLA を再計算する
場合によっては、SLA 値の変更をトリガーする課題イベントが見落とされる、または誤って解釈されて、キューまたは課題ビューに不正な SLA 値が表示されることがあります。通常、SLA 計算は見落とされたイベントに追いついて値を修正するためのものですが、そうでない場合は課題ビューで課題に対する SLA を再計算できます。
課題の SLA の再計算を行うには、次の手順を利用します。
課題ビューに移動します。
[SLA] セクションから [
] (その他の操作) メニュー > [すべての SLA を再計算] の順に選択します。
[再計算] を選択します。
SLA 使用のベスト プラクティス
- 課題の報告者ではない担当者を選択するようにします。同じユーザーを割り当てると、SLA が適切に動作しない可能性があります。
- 課題の目標に影響するような課題データの変更があった場合 (優先度が致命的からブロッカーに変更される場合など)、オープンの課題の場合のみ、以前の目標に対する時間が新しい目標に対して記録されます。
例えば、サポート チームが致命的な課題に 1 時間費やした場合に、課題がブロッカーにエスカレーションされると、経過時間は新しい目標に対してカウントされます。その結果、SLA 違反になる場合もあります。 - SLA データ (特に優先度) を追跡するためにサービス プロジェクトでフィルターを使用している場合は、これらのフィルターに関連する優先度スキームで定義済みのすべての優先度が含まれていることをご確認ください。詳細は「プロジェクトに優先度を関連付ける」をご参照ください。
- 異なる SLA に依存する目標を設定することはお勧めしません。