サービスレベルアグリーメント (SLA) トラブルシューティングガイドIssue 目次 1. SLA がタスクレコードに添付されないのはなぜですか？2. 添付されたタスク SLA を表示するためにフォームを更新する必要があるのはなぜですか？3. タスク SLA レコードがキャンセルされるのはなぜですか？4. 実経過時間とビジネス経過時間の違いは何ですか？5. タスク SLA レコードの実経過時間とビジネス経過時間が正しくないのはなぜですか？6. ダッシュボード/ホームページ/レポートの更新時に、タスク SLA が更新されないのはなぜですか？7. SLA が一定のパーセンテージに達したことがタスク SLA レコードに反映していないのに、SLA が一定のパーセンテージに達したとユーザーに通知されるのはなぜですか？ 8. タスクレコードの [SLA 期限]、[SLA 達成]、[エスカレーション] フィールドの目的は何ですか？9. デフォルト SLA 条件ルールと簡易 SLA 条件ルールの違いは何ですか？ 10. ユーザーが定義した時間に対する違反時間 (予定終了時間) を持つ SLA を定義するにはどうすればよいですか？ 11. SLA 定義の条件において、ドット連結によって参照されるレコードを変更しても、タスク SLA が更新されないのはなぜですか？ style="text-decoration: none;" name="1"> 1.SLA がタスクレコードに添付されないのはなぜですか？ SLA 定義のアクティブフラグを確認する アクティブな SLA 定義のみが評価されます。 注意：Geneva 以前のリリースでは、デフォルトのフォームレイアウトやデフォルトのリストレイアウトに [アクティブ] オプションは表示されません。 SLA 定義が [アクティブ] に設定されているかどうかを確認するには、[アクティブ] オプションを表示するようにフォームレイアウトとリストレイアウトを設定します。 SLA 定義の開始条件を確認する SLA は、タスクレコードの値が SLA 定義で指定された開始条件に一致する場合にのみ、タスクレコードに添付されます。 SLA 定義の停止条件とキャンセル条件を確認する タスクレコードの値が停止条件またはキャンセル条件のいずれかに一致する場合、開始条件が一致しても、SLA はタスクレコードに添付されません。 注意：[キャンセル条件] オプションは、Helsinki 以降のリリースで使用できます。 ワークフローが false に設定されている可能性がある、カスタマイズされたビジネスルールを確認する タスクテーブル上のいずれかのカスタマイズされた「事前」ビジネスルールによりワークフローが false に設定されている可能性がないかを確認します。コードは current.setWorkflow(false); です。 current.setWorkflow(false); ステートメントをコメントアウトし、SLA が添付されているかどうかをテストします。ワークフローを false に設定すると、それ以降のビジネスルールが実行されなくなります。 SLA エンジンは、ベースシステムのビジネスルール「SLA の実行」と「SLA の処理」に基づき、SLA 条件を評価します。 ベースシステムのビジネスルールがアクティブかどうかを確認する ベースシステムのビジネスルール「SLA の実行」と「SLA の処理」がタスクテーブルでアクティブかどうかを確認します。 カスタムクエリビジネスルールが定義されているかどうかを確認する タスクまたは SLA 定義テーブルで、レコードをフィルタリングする可能性のあるカスタムクエリビジネスルールが定義されているかどうかを確認します。 クエリビジネスルールは、テーブルがクエリされるたびに条件を追加する機能を提供します。これにより、SLA エンジンがタスクまたは SLA 定義レコードをクエリできなくなり、SLA 定義が不適切に評価される可能性があります。 アクティブな「クエリ前」ビジネスルールをクエリする方法については、次のスクリーンショットを参照してください。 注意：この問題は、Helsinki 以降のリリースで修正されています。詳細については、KB0553527 を参照してください。この記事では、Geneva 以前のリリースのワークアラウンドについても説明しています。 style="text-decoration: none;" name="2"> 2.添付されたタスク SLA を表示するためにフォームを更新する必要があるのはなぜですか？ SLA エンジンが非同期で実行されるように設定されているか確認する Fuji 以前のリリース： [サービスレベル管理] > [アドミニストレーション] > [SLA プロパティ] に移動します。[タスクの挿入または更新操作後に、2011 SLA エンジンを非同期に実行します] プロパティがオンになっているか確認します。 Geneva リリース： [サービスレベル管理] > [プロパティ] > [SLA エンジン] に移動します。[タスクの挿入または更新操作後に、2011 SLA エンジンを非同期に実行します] プロパティがオンになっているか確認します。 Helsinki 以降のリリース： [サービスレベル管理] > [プロパティ] > [SLA エンジン] に移動します。[2011 SLA エンジンの非同期実行] プロパティがオンかオフかを確認します。 このプロパティがオンになっている場合、SLA エンジンは非同期モードで実行されます。これにより、タスクレコードの更新と SLA エンジンの実行の間に遅延が生じます。また、タスクレコードの挿入と更新のパフォーマンスが向上しますが、添付されている SLA を表示するには、タスクフォームまたはタスク SLA 関連リストを更新する必要があります。 style="text-decoration: none;" name="3"> 3.タスク SLA レコードがキャンセルされるのはなぜですか？ SLA 定義の開始条件を確認します。SLA 定義の開始条件が一致しなくなった場合、タスクに添付された SLA はキャンセルされます。SLA 条件を正しく定義するには、この動作を理解することが重要です。開始条件は、SLA をアクティブにする全期間にわたって true である条件と考える必要があります。開始時にだけ一致すれば良い条件ではありません。 Helsinki 以降のリリースでは、[キャンセルするタイミング] と [キャンセル条件] の 2 つの新しいフィールドが導入されました。この機能は、SLA がキャンセルされる際、より適切に制御できるように設計されました。 詳細については、製品ドキュメントのSLA 条件を参照してください。 style="text-decoration: none;" name="4"> 4.実経過時間とビジネス経過時間の違いは何ですか？ SLA エンジンは、各タスク SLA レコードに 2 セットの経過時間を保持します。[実績] フィールドには、常に 24 時間 365 日ベースで計算される時間が含まれます。これらのフィールドは、タスク SLA レコードが作成されてから経過した物理的な時間を示します。[ビジネス] フィールドには、タスク SLA レコードに関連付けられているスケジュールに基づく時間が含まれます。スケジュールでは、一連の作業時間または営業時間を定義します。 経過時間の例： 上記のタスク SLA レコードでは、次のようになります。 「優先度 1 解決 (8 時間)」という名前の SLA 定義がタスク INC0010001 に添付されています。このタスク SLA には「平日 8 時～ 5 時」という名前のスケジュールが関連付けられています。このタスク SLA の開始時間は午前 7 時 30 分です。これは、SLA 定義で定義された開始条件がタスクレコードのフィールド値と一致した時刻です。実経過時間は、1 時間 5 分 5 秒が経過したことを示しています。これは、タスク SLA レコードがタスクレコードに添付されてから経過した物理的な時間です。ビジネス経過時間は、35 分 5 秒が経過したことを示しています。これは、添付されたスケジュールの営業時間が午前 8 時から午後 5 時として指定されているため、システムが午前 8 時からビジネス経過時間を計算するためです。 注意：タスク SLA レコードに関連付けられたスケジュールがない場合は、以下のように対応します。 Fuji 以前のリリースでは、ビジネス値は空です。 Geneva 以降のリリースでは、システムプロパティを使用して、ビジネス経過時間を実経過時間と同じ設定にするかどうかを選択できます。 注意：タスク SLA のスケジュールが間違っている場合は、以下のように対応します。 Helsinki 以降のリリースでは、SLA 定義レコードの [スケジュールソース] フィールドの設定を確認します。これは、タスク SLA レコードに添付するスケジュールを制御します。 Fuji 以前のリリースでは、[SLA プロパティ] モジュールで設定を確認します。 style="text-decoration: none;" name="5"> 5. タスク SLA レコードの実経過時間とビジネス経過時間が正しくないのはなぜですか？ タスク SLA レコードの時間とパーセンテージは、パフォーマンスに影響を与える可能性があるため、継続的な計算や更新は行いません。SLA エンジンは、必要に応じて「ジャストインタイム」アプローチでこれらの値を計算し、更新します。 これらの値は、次のシナリオで更新されます。 タスクレコードの更新によってタスク SLA レコードのステージが変わった場合 (例えば、一時停止から処理中へ、処理中から完了へ)。ベースシステムの SLA 更新スケジュール済みジョブのいずれかが実行された場合。注意：一時停止したタスク SLA は、これらのレコードの時間経過がないため除外されます。これらのジョブは、タスク SLA が違反時間に近づくと、より頻繁に実行されます。 詳細については、製品ドキュメントの「SLA のスケジュール済みジョブ」を参照してください。 [glide.sla.calculate_on_display] システムプロパティが true に設定されていて、タスク SLA レコードが表示されている場合。 Fuji 以前のリリース： アプリケーションナビゲーターの [フィルターナビゲーター] テキストボックスに「sys_properties.list」と入力し、キーボードの Enter キーまたは return キーを押します。[glide.sla.calculate_on_display] プロパティを検索します。 Geneva リリース： [サービスレベル管理] > [プロパティ] > [SLA エンジン] に移動します。[タスクのフォーム表示時にタスク SLA レコードを再計算する] プロパティを確認します (タスク表示の際に現在のタスク SLA を計算するため、フォームのロードに時間がかかる場合があります)。 Helsinki 以降のリリース： [サービスレベル管理] > [プロパティ] > [SLA エンジン] に移動します。[タスクフォームが表示されたらタスク SLA を更新する] プロパティを確認します。 注意：このプロパティを有効にすると、フォームのロード中にタスク SLA 計算が更新されます。 ユーザーがタスク SLA レコードで更新アクションを手動で開始した場合。 注意：Fuji 以前のリリースでは、この UI アクションの名前は「SLA 計算を実行」でした。 style="text-decoration: none;" name="6"> 6. ダッシュボード/ホームページ/レポートの更新時に、タスク SLA が更新されないのはなぜですか？ タスク SLA レコードの時間とパーセンテージは、システムパフォーマンスのオーバーヘッドとなる可能性があるため、継続的な計算や更新は行いません。 SLA エンジンは、必要に応じて「ジャストインタイム」アプローチでこれらの値を計算し、更新します。したがって、タスク SLA データは、ホームページやダッシュボードに表示されるいかなる種類のレポートにロードされても更新されません。 混乱の原因となるよくある例は、5 分、15 分、30 分、60 分の間隔に設定できるホームページの更新タイミングです (こちらを参照)。ホームページの更新タイミングは、データベース内のタスク SLA データを計算/更新しません。この更新アクションは、送信された可能性のある新しい更新を表示するために、データベースからデータを再度ロードするだけです。 style="text-decoration: none;" name="7"> 7.SLA が一定のパーセンテージに達したことがタスク SLA レコードに反映していないのに、SLA が一定のパーセンテージに達したとユーザーに通知されるのはなぜですか？ 各タスク SLA レコードのワークフローは、経過時間を決定するための独自の値セットを持っています。ワークフローでは、SLA パーセンテージタイマーのワークフローアクティビティで指定されたパーセンテージで SLA が進行中であるときに、これらの値を使用して、ユーザーへの通知をトリガーします。 ワークフローは意図的に独自の計算を保持するため、タスク SLA レコードに保存されている値は最新ではない可能性があり、それらに依存しません。 この問題には既知のエラーがあり、KB0563889 でワークアラウンドを確認できます。 注意：この問題は、Helsinki 以降のリリースで修正されています。これで、ワークフロー内の SLA パーセンテージタイマーアクティビティが期限切れになるたびに、タスク SLA レコードが更新されるようになりました。 style="text-decoration: none;" name="8"> 8.タスクレコードの [SLA 期限]、[SLA 達成]、[エスカレーション] フィールドの目的は何ですか？ SLA エンジン (「2010 年秋」リリース) が導入される前、SLA は、各タスクレコードを単一の SLA に関連付けることができる「エスカレーション」エンジンによって処理されていました。また、[SLA 期限]、[SLA 達成]、[エスカレーション] フィールドは、エスカレーションエンジンによって管理されていました。この従来の SLA エンジンは、現在でも Express インスタンスで使用される唯一のエンジンです。 最新の SLA エンジンは、各タスクレコードに対して複数の SLA を追跡できるように、従来のエンジンから改善されています。ユーザーは、個々のタスク SLA レコードを表示することで、特定のタスク SLA レコードが違反したかどうかを確認できます。2010 年のエンジンでは、[ステージ] フィールドに [違反] と表示され、2011 年のエンジンでは新しい [違反 (Has breached)] フィールドが使用されています。 エスカレーションエンジンは、SLA プラグインを使用している場合でも、滞留アクティビティモニター (滞留アクティビティモニターの詳細についてはこちらをクリック) をサポートしているため、システム内で継続して実行されています。また、このサーバー側のコードによって、タスクがクローズされたときに [made_sla] フィールドの値が変更されることがあります。 システム内に従来の SLA フィールドが入力された既存のタスクレコードがある場合、それらは以前のリリースで作成された古いレコードである可能性があります。 ただし、これは最新の SLA エンジンには何の影響も与えません。従来のフィールドは無視できます。また、その値は予期せず変更される可能性があるため、ユーザーによる使用は意図されていません。 これらの従来のフィールドに値が入力された状態で新しいタスクレコードが作成されている場合は、[com.snc.sla.run_old_sla_engine] システムプロパティを確認して、インスタンスがサービスレベルアグリーメントの従来のエスカレーションエンジンを使用するように構成されているかどうかを確認することで、それらが意図的に使用されているかどうかを確認できます。プロパティが false の場合、(システムによって操作されるため) フィールドは予約済みとなりますが、内容は無視できます。従来のサービスレベルアグリーメント定義テーブル (「sysrule_escalate」) の内容を確認することもできます。このテーブルへのアクセス方法によっては、従来の SLA 定義と滞留アクティビティモニター定義の両方が表示される場合があることに注意してください。 style="text-decoration: none;" name="9"> 9.デフォルト SLA 条件ルールと簡易 SLA 条件ルールの違いは何ですか？ SLA 条件ルールは、SLA 定義で定義した条件をどのように組み合わせて、SLA の添付、一時停止、完了、再添付、キャンセルを決定するかを制御します。例えば、デフォルトの SLA 条件ルールは、「開始条件」が一致し、「停止条件」が一致しない場合にのみ、新しい SLA を添付します。 SLA 定義ごとに使用する条件ルールを指定できますが、フォームに [条件タイプ] フィールド (「SLA 条件ルール」テーブルへの参照) を追加する必要があります。 SLA 定義で [条件タイプ] が空白の場合、SLA エンジンは、使用するデフォルトの SLA 条件ルールを [com.snc.sla.default_conditionclass] システムプロパティから検索します。 すぐに利用可能な SLA 条件ルールは、デフォルトと簡易の 2 つです。次の表は、SLA に対して処理するアクションを決定する際に、チェックされる条件を示しています。以下のアクションがリストされる順序は、SLA エンジンがアクションを評価する順序でもあります。 これは、複数のアクションの条件が一致した場合のために覚えておく必要があります。例えば、SLA を「完了」または「キャンセル」するための条件が一致した場合、「完了」が最初に評価されるため、SLA は「完了」としてマークされます。 条件ルール デフォルト簡易 新しい SLA が添付される 開始条件が一致する かつ停止条件が一致しない Helsinki 以降のインスタンスが次のようになっている場合： 上記に加えて、SLA 定義で以下が選択される キャンセル条件が一致しない 開始条件が一致する 注意：Helsinki 以降のインスタンスでは、新しいキャンセル条件を簡易 SLA 条件ルールで使用することはできない 新しい SLA が停止 (完了) する 停止条件が一致する 停止条件が一致する SLA が再添付 (リセット) される リセット条件が一致する かつ開始条件が一致する リセット条件が一致する SLA がキャンセルされる 停止条件が一致しない かつ開始条件が一致しない Helsinki 以降のインスタンスでは、[キャンセルするタイミング] で選択されたオプションによって、SLA がキャンセルされる条件が決まる 開始条件を満たしていないとき 停止条件が一致しない かつ開始条件が一致しない 一度もない SLA はキャンセルできないため、条件はチェックされないキャンセル条件を満たしているとき キャンセル条件が一致する 停止条件が一致しない かつ開始条件が一致しないかつ一時停止条件が一致しない 注意：Helsinki 以降のインスタンスでは、新しいオプションである「キャンセルしない (never cancelling)」または「定義されたキャンセル条件と一致する (matching with a defined Cancel condition)」は、簡易 SLA 条件ルールで使用することはできない SLA が一時停止する 一時停止条件が一致する Helsinki 以降のインスタンスが次のようになっている場合： 上記に加えて、SLA 定義で以下が選択される 再開条件が一致しない 一時停止条件が一致する 注意：Helsinki 以降のインスタンスでは、新しい再開条件を簡易 SLA 条件ルールで使用できない SLA が再開する 一時停止条件が一致しない Helsinki 以降のインスタンスが次のようになっている場合： 上記に加えて、SLA 定義で以下が選択される 再開条件が一致する 一時停止条件が一致しない 注意：Helsinki 以降のインスタンスでは、新しい再開条件を簡易 SLA 条件ルールで使用できない すぐに利用可能な条件ルールがインスタンスに必要な SLA 処理を提供しない場合、独自の条件クラス (スクリプトインクルード) と SLA 条件ルールレコードを作成できます。 詳細については、オンラインヘルプトピック「SLA 条件ルールの拡張」を参照してください。 style="text-decoration: none;" name="10"> 10.ユーザーが定義した時間に対する違反時間 (予定終了時間) を持つ SLA を定義するにはどうすればよいですか？ タスクから取得した日付/時刻 (例えば、すべてのタスクタイプで利用可能な [期日] フィールド) に基づいて違反時間のタスク SLA を作成する SLA 定義を持つことができます。 これは、スクリプトを実行して SLA の違反時間を判断できる相対期間を作成することで実現できます。その後、SLA 定義を定義するときにこの相対期間を選択して、デフォルトのユーザー定義期間を置き換えることができます。期間は常に静的な値を返す必要があります。計算に gs.now や同様の関数を使用することはできません。 注意：相対期間の一時停止条件はサポートされていません。これは、一時停止条件が SLA を満たす必要がある固定の日付/時刻を提供するものとみなされ、違反時間が変更されるべきではないためです。 相対期間モジュールに移動して、新しい相対期間レコードを作成できます。SLA の違反時間をタスクの [期日] フィールドの日時に設定するスクリプトの例は次のとおりです。 /* This relative duration script will set the Breach Time of the Task SLA to the value in the "Due date" of the Task. If the "Due date" field is available on the Task form and editable then this effectively allows the user to specify the Breach Time of the SLA. If the Due Date field is empty or in the past, the script will instead set the Breach Time of the SLA to 1 second after the Start time */ (function() { var startDateMs = calculator.startDateTime.getNumericValue(); var dueDate; // Work out if "current" is a Task record or Task SLA and then get the "due_date" element from the Task var tableName = current.getTableName(); if (tableName) { var baseTableName = GlideDBObjectManager.getAbsoluteBase(tableName); if (baseTableName == "task") dueDate = current.getElement("due_date"); else if (baseTableName == "task_sla") dueDate = current.getElement("task.due_date"); } // if we've got a "due_date" and it's after our SLA's Start time then use it // otherwise we'll have to default to the same as Start Time plus 1 second (i.e. instant breach of SLA) if (dueDate && !dueDate.nil() && dueDate.dateNumericValue() > startDateMs) dueDate = dueDate.getGlideObject(); else { dueDate = new GlideDateTime(calculator.startDateTime); dueDate.addSeconds(1); } // if we have a schedule then check if the Due Date is in it and if it isn't // find the next time we are in the schedule if (calculator.schedule && !calculator.schedule.isInSchedule(dueDate)) dueDate.add(calculator.schedule.whenNext(dueDate, calculator.timezone)); // set the endDateTime property of the calculator object to dueDate calculator.endDateTime = dueDate; calculator.calcScheduleDuration(); })(); 上記の例では、期日が空または過去の場合に、SLA の違反時間のデフォルトを開始時間の 1 秒後に設定しています。上記の例を「Breach on Due Date」という名前で作成した場合、次に示すように SLA 定義でこれを選択します。 style="text-decoration: none;" name="11"> 11.SLA 定義の条件において、ドット連結によって参照されるレコードを変更しても、タスク SLA が更新されないのはなぜですか？ ドット連結を使用すると、参照フィールドを介して別のテーブルのフィールドに移動できます。ドット連結は、SLA 定義のすべての条件で使用できます。 参照レコードが変更されたときにタスク SLA フィールドが更新されることを想定していると、混乱することがよくあります。 SLA エンジンは、「SLA の実行」という名前のビジネスルールを介してトリガーされます。このルールは、挿入および更新時にタスクテーブル (およびインシデント、問題などの拡張テーブル) に対して実行されます。さらに、特定のレコードに対する SLA エンジンの実行では、そのレコードのテーブルに対して実行するように設定された SLA 定義のみがチェックされます。 つまり、インシデントレコードの変更 (または送信) によって、インシデントテーブルに対してのみ SLA 定義をチェックする SLA エンジンの実行がトリガーされます。同様に、ユーザー (またはグループ) レコードの変更では、そのユーザー (またはグループ) テーブルに対してのみ SLA エンジンをトリガーし、他のテーブルに対しては実行されません。 例：「Fred Luddy のグループ解決」という名前の SLA 定義が、インシデントテーブルに対して実行されるように設定されているとします。開始条件は以下のとおりです。 注目すべきは、条件のクエリの最後の部分でドット連結 (Assignment Group.Manager) が使用されていることです。 ここで、以下の 2 つのステップで表されるケースを考えてみましょう。 インシデント INC0000001 が送信され、この時点では、Assignment Group.Manager が「Beth Anglin」である以外は、すべてのフィールドが上記の条件に一致します。 管理者はデータベースグループレコードに移動し、[Manager] フィールドを「Fred Luddy」に変更します。 ステップ 2 が実行されると、SLA エンジンはインシデントテーブルに対して実行されないため、タスク SLA 「Fred Luddy のグループ解決」は INC0000001 に添付されません。 INC0000001 が別のテーブル (インシデント) にあるのに対して、データベースはグループテーブルのレコードであるため、データベースグループに対するその変更によって INC0000001 に対する SLA エンジンの実行はトリガーされません。 考えられるワークアラウンド： この動作のワークアラウンドとして、current が参照フィールドとして設定されているレコードに対して、SLA エンジンを手動でトリガーして実行できます。 上記の例でワークアラウンドを適用するには、グループテーブルにビジネスルールを記述し、[更新] および [詳細] のフラグにチェックマークを付けて、次のスクリプトを追加します。 (function executeRule(current, previous /*null when async*/) { var grInc = new GlideRecord("incident"); grInc.addQuery("assignment_group", current.getUniqueValue()); grInc.query(); while (grInc.next()) new TaskSLAController.run(grInc); })(current, previous); ワークアラウンドの影響： このワークアラウンドを適用すると、ビジネスルールが実行されるテーブル (上記の例ではグループテーブル) のレコードを変更する際に、膨大な量のレコードで実行される可能性があるため、パフォーマンスが低下する可能性があります。例えば、データベースが 1,000 件のインシデントのアサイン先グループとして設定されている場合、SLA エンジンはそれらすべてに対して実行されます。 ServiceNow では、このワークアラウンドが本当に必要な場合にのみ、慎重に適用することを推奨しています。 提供した例において、上記のスクリプトが改善できるとすれば、SLA 定義で構成されたすべてのクエリ条件を GlideRecord オブジェクトに適用することです。 (function executeRule(current, previous /*null when async*/) { var serviceNowCompanySysId = "012345678910111213141516171819202122"; var newStateValue = 1; var grInc = new GlideRecord("incident"); grInc.addActiveQuery(); grInc.addQuery("priority", 1); grInc.addQuery("company", serviceNowCompanySysId); grInc.addQuery("state", newStateValue); grInc.addQuery("assignment_group", current.getUniqueValue()); grInc.query(); while (grInc.next()) new TaskSLAController.run(grInc); })(current, previous); 注意：上記のコードは、SLA エンジンの実行対象となるインシデントの数を減らそうとしていますが、処理されるデータが多すぎる可能性があります。 Related Linksサービスレベル管理 (SLA) リソース サービスレベルアグリーメント (SLA) に関する FAQ