サービスレベルアグリーメント (SLA) のトラブルシューティング - Support and Troubleshooting

サービスレベルアグリーメント (SLA) のトラブルシューティング Issue  この記事の情報を使用して、いくつかの初期トラブルシューティング手順を実行し、いくつかの一般的な SLA の問題を理解します。

SLA の問題のトラブルシューティングを行う際に従うべきいくつかの最初のステップを次に示します。

実行中の SLA エンジンのバージョンを特定します。SLA エンジンには、次の 3 つの主要なバージョンがあります。 SLA エンジンのバージョン 説明 エスカレーションエンジンに依存していたバージョン。(2010 年以前) ワークフローベースで、1 つの大きなビジネスルール「プロセス SLA (Process SLAs)」に多くのロジックが含まれています。 SLA プラグイン (別名 2010 エンジン) ビジネスルール、スクリプトインクルード、およびスケジュール済みジョブによって実行されます。通知のみを処理するようにワークフローを降格させる) 2011 エンジン ( 2011 年 6 月 バージョンで利用可能) 「新しい」SLA エンジンのメジャーリビジョン (反復 2)。これにより、以前は拡張可能な単一のスクリプトインクルードに分散されていた機能の多くがプルされます。 2010 Engineから2011 Engineへの移行 プロセスの詳細については、ServiceNow の製品ドキュメントを参照してください。

注: 2010 エンジンの修正により、2011 エンジンとの互換性が得られます。(2011 エンジンは、com.snc.sla.engine.version と呼ばれる単一のsys_propertiesブールフラグに応じて、2010 と 2011 の間を行き来するように設計されています。2010 SLA エンジンには複数の既知のエラーがあります。新しいエンジンに移行することをお勧めします。 考えられる SLA コンポーネントを特定します。顧客から報告された予期しない動作を分析し、顧客の期待を理解していることを確認した後、報告された SLA 動作を制御するコンポーネントを決定します。 Installed with Service Level Management を参照)。 例を調べます。

SLA デスクチェックスクリプトを使用したタイムラインの作成 カスタマーが提供した例を使用して、表示されている動作が予期しないものかどうかを確認します SLA の詳細については、「 KB0529411: 2011 SLA エンジンの実際の仕組み 」を参照してください。 Resolution ここでは、混乱しやすい分野をいくつか紹介します。

SLA が作成されたときと同じステップで技術者がタスクをクローズした場合、SLA は作成されません

これは正常な動作ですが、いくつかの回避策があります。一定期間後に [作成>解決>クローズ ケースプロセスを使用する場合 システムによって SLA が作成され、経過割合 0% で 達成/完了 とマークされます。これは、 解決 ですぐに SLA を一時停止し、 クローズ がケースレコードの個別の更新であるためです。

既存のツールと 簡易 SLA 条件タイプを使用することもできます。そうしないと、そもそも SLA が添付されないためです。

条件タイプ:シンプル 開始条件:(必要なものは何でも) 停止条件:(必要なものは何でも) 注意: [シンプル] を使用する場合は、前回停止条件を満たしている場合に、後続のケース更新で SLA のコピーを添付しないように注意してください (停止条件にすべての「ターミナル」状況が含まれている場合は簡単です)。 SLA 計算の説明

SLA (task_slaテーブル) は、臨機応変ではなく、特定の時刻にのみ計算されます。詳細については、製品ドキュメントの「 SLA Calculation 」を参照してください。

SLA は、ビジネスルールとスケジュール済みジョブのグループによって計算され、評価されます (以下を参照)。ビジネスルールは、タスクが更新、作成、または削除されるとトリガーされます。スケジュール済みジョブは、設定された間隔でバックグラウンドで実行されます。

「SLA の処理」という名前の非同期ビジネスルールは、すべてのタスクが挿入または変更された後に実行され、SLA の開始条件、一時停止条件、および終了条件を評価します。

SLA 計算は、違反した場合に基づいて更新されるようになりました。これらは、次のスケジュールジョブ (sys_triggerテーブル) で発生します。

SLA 更新 (すでに違反):毎日繰り返し SLA 更新 (30 日より後の違反):5 日ごとに繰り返し SLA 更新 (1 日以内の違反):1 時間ごとに繰り返し SLA 更新 (1 時間以内の違反):10 分ごとに繰り返し SLA 更新 (10 分以内の違反):1 分ごとに繰り返し SLA 更新 (30 日以内の違反)：毎日繰り返し 警告: SLA ワークフローと SLA 自動化を制御するメカニズムは、互いに完全に独立しています。多くの顧客は、SLA の現在の経過割合を示すメール通知を SLA ワークフローから送信することを要求されています。ただし、task_slaテーブルのフィールドを使用すると、そのフィールドの最新の更新された値のみが表示されるため、これは機能しません。その結果、不正確な値がメールで送信されます。1 つの解決策は、各パーセンテージ レベルの通知を使用して、目的の経過割合を SLA 通知にハードコーディングすることです。たとえば、SLA が 75% の経過時間に達したときにメールを起動する場合は、「75% SLA 警告」のメール通知を作成し、特別なイベントを使用してその通知をトリガーします。このイベントは「sla.warning.75」と呼ばれます。[イベントを作成] ワークフローアクティビティを使用して、トリガーするイベントの名前を指定できます。2 番目の解決策は、通知を送信する前に SLA を更新するコードを直接呼び出すことです。[SLA 計算を実行] UI アクションに類似したコードを使用します。

警告: [表示時に SLA を計算] プロパティ (glide.sla.calculate_on_display) をオンにすると、ユーザーがケースフォームを表示したときにも SLA が計算されます。SLA は、ユーザーがレポートを実行するとき、リスト内のケースを参照するとき、または通知がスクリプトを介してtask_slaレコードにアクセスするときに更新されません。[表示時に計算] がオンになっている場合、ユーザーがタスク (ケース、change_request、sc_request...) フォームを表示したときに SLA が更新されます。SLA を必要なときに常に計算させる方法はありません。これはパフォーマンス上の理由から不可能です。[表示時に計算] プロパティは、インスタンスではデフォルトでオフになっています。つまり、ビジネス経過時間と他のすべての計算フィールドは、SLA が最後に計算されたときの値のみを表します。 SLA 定義期間フィールドの説明 SLA を定義する場合、 期間 フィールドは スケジュール フィールドと連携して重要です。このフィールドに指定された日数は 24 時間に変換されます。たとえば、日が 8 時間のスケジュールが使用されている場合、期間 1 日は 3 営業日後に SLA の違反を設定します。

または、たとえば、5 日間 2 時間の期間と 9 時から 5 時までのスケジュールを選択するとします。5 日と 2 時間は 122 時間 (5x24 + 2) と見なされます。122 時間は 9 時から 5 時までのスケジュールに 1 日あたり 8 時間配分され、15.25 日のスケジュール日となります (122/8 = 15.25)。詳細については、「 SLA Definition 」を参照してください。

SLA 実績割合とビジネス割合の説明

実際の割合とビジネスの割合は、特定の時点で必ずしも同じではありません。ただし、ビジネス期間が 100% に達すると、実績パーセンテージも 100% になるはずです。その理由は、両者の唯一の違いは、一方がスケジュールを考慮し、もう一方が考慮しないことだからです。たとえば、次の状況を考えます。毎日午前 8 時から午前 9 時まで、スケジュール時間が 1 時間しかないスケジュールがあります。SLA の合計時間は 2 時間です。SLA がスケジュールされた時刻の午前 8 時 15 分に開始するとします。午前8時45分までに、30分が経過した。30 分は、合計ビジネス時間の 25% を占めます (例:2 時間 / 30 分)。ただし、この場合の実際の期間は、予定終了時間が開始時間の 2 日後の午前 8 時 15 分になるため、48 時間になります。48時間のうち30分は、実際の経過割合の1%にすぎません。

SLA 残り時間フィールドと一時停止時間の説明

Task SLA。残り時間 フィールドは、SLA が一時停止している間もカウントダウンを続けます。 Task SLA。ただし、実際の割合 フィールドには、まだ一時停止時間が必要です [タスク SLA.一時停止期間]が考慮されます。次のように数式を記述できます。

[派生終了日] = [一時停止期間] + [SLA 定義.期間] [残り時間] = [派生終了日] - [現在]

これを処理するコードは、SLACalculatorNG という名前のスクリプトインクルードで確認できます。

var dc = this._newDurationCalculator(sla, newTaskSLA.sla_duration + newTaskSLA.business_pause_duration); ... var timeLeftMS = currentSLA.derived_end_time - nowMS; 混乱が生じるのは、タスク SLA が「一時停止」ステータスから抜け出すまで一時停止期間が計算されないためです。

SLA 期間:8 時間 午前 10:00 - ケースと SLA が作成されました 午前 11:00 - SLA が一時停止します (1 時間経過、一時停止期間 = 0) 0 + 8 - 1 = 7 時間 残り時間 午前 12:00 - SLA が計算されます (2 時間が経過しましたが、一時停止期間は 0 のままです) 0 + 8 - 2 = 6 時間 残り時間 午後 1:00 - SLA が [一時停止] から他のものに移動します (3 時間が経過すると、一時停止期間が計算されます。今は2時間です) 2 + 8 - 3 = 7 時間 残り時間 Related Links SLA 条件の理解 SLA 経過時間の測定