Jira Service Management で SLA をトラブルシューティングする方法

お困りですか?

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

コミュニティに質問

プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Fisheye および Crucible は除く

目的

Jira Service Management で SLA に関連する問題のトラブルシューティング方法を確認し、問題の原因を特定するための情報を見つけられる場所について学習します。このドキュメントは SLA のトラブルシューティングの基本を提供することを目的としており、すべての SLA の問題を解決するわけではありませんが、読者が利用可能な基本的なトラブルシューティングのガイドラインを提供します。

ヒント

  • Always search for the symptoms in public KB articles or our public bug tracker jira.atlassian.com as there may be known issues / bugs around certain problems.
  • Jira ログで SLA ログが確認できるよう、com.atlassian.servicedesk.internal.sla パッケージで DEBUG ロギングが有効化されていることを確認します。この方法については「ロギングとプロファイリング」ドキュメントで説明しています。

考慮事項

  • 新しい SLA を作成すると、新しいカスタム フィールドが作成されます。たとえば、サービス プロジェクトで Time For First Response という名前の SLA を作成すると、まったく同じ名前で新しいカスタム フィールドが作成されます。
  • サービス エージェントのみが、特定の課題で SLA メトリックを表示できます。したがって、SLA が表示されない問題がカスタマーから報告された場合、そのユーザーがエージェントかどうかを最初に確認します。これは「サービス プロジェクト ユーザーのセットアップ」で詳細に説明しています。

ソリューション

Prerequisites

Jira Service Management での SLA の使用方法の基本を理解している必要があります。詳細情報については「SLA のセットアップ」をご確認ください。

SLA の一般的な問題

SLA の不一致

シナリオ

ユーザーが SLA の不一致を指摘しています。SLA が期待される値を表示していないか、まったく表示されません。

チェックポイント
  • SLA の再計算を行います。これは、既存の SLA を編集して変更を保存することで行なえます。これはオープンな課題にのみ影響し、解決済みの課題の再計算は行われない点にご注意ください。
  • SLA ゴールに低速な JQL が使用されているかどうかを確認します。"was in" または "Entered Status" などを使用している場合は特に注意します。Jira Service Management の非常に大きなインスタンスでは、これによって遅延が発生する可能性があります。 
  • SLA ゴールが変更されたかどうかを確認します。課題のゴールを変更するような方法で課題データが変更された場合 (例: 優先度を Critical から Blocker に変更)、従来のゴールまでの時間が新しいゴールに対して追跡されます。つまり、サポート チームが Critical の課題に 1 時間を費やしたあとに課題が Blocker にエスカレートされた場合、SLA に違反するかどうかを問わず、時間数は引き続き新しいゴールに対して計上されます。
  • Check how the users are assigned to the ticket? This is especially true when SLA conditions are based on the assignee. There is an SLA Service Management bug that prevents the SLA condition from being triggered when the ticket is assigned to a user on creation. See JSD-811 - Getting issue details... STATUS for more info.
  • データベース情報とクロスチェックします。課題の詳細画面の SLA 情報はデータベースの情報と一致しますか?

    SLA 一覧をクエリする
    SELECT * FROM "AO_54307E_TIMEMETRIC";

    上述のクエリは、インスタンスの SLA の一覧を返します。また、あとから REST API 呼び出しに使用できる、SLA ID も返します。

    SELECT ( p.pkey 
             || '-' 
             || i.issuenum ) AS issuekey, 
           cf.cfname, 
           cv.textvalue 
    FROM   customfield cf, 
           customfieldvalue cv, 
           jiraissue i, 
           project p 
    WHERE  i.project = p.id 
           AND cv.issue = i.id 
           AND cv.customfield = cf.id 
           AND cf.customfieldtypekey = 'com.atlassian.servicedesk:sd-sla-field' 
           AND p.pkey = 'TEST' 
           AND i.issuenum IN ( 1, 2 );

    上述のクエリは、チケット TEST-1 と TEST-2 の SLA 情報 (すべての SLA フィールド タイプ) を返します。p.pkey = 'TEST' および i.issuenum in (1,2) を削除すると、すべてのプロジェクトのすべての課題をかえします。

  • REST API 呼び出し経由で直接クロスチェックすることもできます。これはデータベースから SLA 情報を返します。

    特定の SLA 用のクエリ
    https://<ATLASSIAN_DOMAIN>/rest/servicedesk/1/servicedesk/<PROJECT_KEY>/sla/debug/issue/<TICKET_ID>/metric/<SLA_ID>/data

SLA ルールの過負荷

シナリオ

サービス デスクの SLA 構成ページの読み込みに時間がかかり、最終的にはエラーが表示されてクラッシュする。

チェックポイント

  • プロジェクトの各 SLA のルール/条件の数を確認します。アプリケーションが応答しなかったり、時間がかかったりする原因は、1 つの SLA に大量のルールが含まれていることである可能性があります。実行に大量の時間がかかる複雑な JQL が原因になっていることもあります (プロキシには既定で 60 秒のタイムアウトが設定されており、レスポンスに 1 分以上がかかったすべてのリクエストは最初にプロキシで終了されます)。

    select g."JQL_QUERY", vp."NAME"
    from "AO_54307E_GOAL" g, "AO_54307E_TIMEMETRIC" tm, "AO_54307E_VIEWPORT" vp
    where g."TIME_METRIC_ID" = tm."ID"
    and tm."SERVICE_DESK_ID" = vp."ID"
    and vp."KEY" = 'test';

    The query above will return all the rules under the test project. The more rules the SLA has the more rules it has to process. In some cases, having 100+ rules can cause a time out on the SLA configuration page.

  • Known bugs: There is also a known bug with SLA page loading as detailed in  JSD-2932 - Getting issue details... STATUS , which can cause this behaviour.

SLA データの解読

このセクションでは、上述のトラブルシューティング手順で収集した情報を読み解く方法について説明します。SLA データは次の例のように、JSON 形式でデータベースに保存されます。

{
    "timeline":{
        "events":[
            {
                "date":1440587743167,
                "types":[
                    "START"
                ]
            }
        ]
    },
    "ongoingSLAData":{
        "goalId":8,
        "startTime":1440587743167,
        "paused":false,
        "thresholdData":{
            "calculatedAt":1441192543192,
            "remainingTime":-115200025,
            "thresholdsConfigChangeDate":1440585575158
        }
    },
    "completeSLAData":[
    ],
    "metricId":4,
    "definitionChangeDate":0,
    "goalsChangeDate":1440585575204,
    "goalTimeUpdatedDate":1440585575193
}

例として startTime フィールドを確認してみます。http://www.epochconverter.com/ に移動して、人間が読み取りやすい形式に値を変換できます。変換すると、SLA の startTime Wed, 26 Aug 2015 11:15:43 GMT であることを確認できます。

データベースについてのその他の情報

一般に、SLA はデータベースに保存され、関連性は次のとおりです。

サービス デスクのプロジェクトへの参照は "AO_54307E_VIEWPORT" テーブルから得られます。

クリックして定義を確認

jira=# \d "AO_54307E_VIEWPORT"

                                           Table "public.AO_54307E_VIEWPORT"
          Column          |          Type          |                             Modifiers
--------------------------+------------------------+-------------------------------------------------------------------
 DESCRIPTION              | text                   |
 ID                       | integer                | not null default nextval('"AO_54307E_VIEWPORT_ID_seq"'::regclass)
 KEY                      | character varying(255) | not null
 LOGO_ID                  | integer                |
 NAME                     | character varying(255) | not null
 PROJECT_ID               | bigint                 | not null
 SEND_EMAIL_NOTIFICATIONS | boolean                |
 THEME_ID                 | integer                |

次に、テーブル "AO_54307E_TIMEMETRIC" は、作成された SLA とカスタム フィールドにサービス デスクを関連付けます。簡単に表すと次のようになります。

"AO_54307E_TIMEMETRIC" ."SERVICE_DESK_ID" = "AO_54307E_VIEWPORT" ."ID"

"AO_54307E_TIMEMETRIC" ."CUSTOM_FIELD_ID" = customfield.id = customfieldvalue.customfield

クリックして定義を確認

jira=# \d "AO_54307E_TIMEMETRIC"

                                                Table "public.AO_54307E_TIMEMETRIC"
            Column             |            Type             |                              Modifiers
-------------------------------+-----------------------------+---------------------------------------------------------------------
 CUSTOM_FIELD_ID               | bigint                      |
 DEFINITION_CHANGE_DATE        | timestamp without time zone |
 GOALS_CHANGE_DATE             | timestamp without time zone |
 ID                            | integer                     | not null default nextval('"AO_54307E_TIMEMETRIC_ID_seq"'::regclass)
 NAME                          | character varying(255)      | not null
 SERVICE_DESK_ID               | integer                     | not null
 THRESHOLDS_CONFIG_CHANGE_DATE | timestamp without time zone |

JQL and SLA on the Database

最後に、課題の一覧で JQL クエリに関連付けられる SLA は "AO_54307E_GOAL" テーブルにあります。

"AO_54307E_GOAL"."TIME_METRIC_ID""AO_54307E_TIMEMETRIC"."ID"

クリックして定義を確認

jira=# \d "AO_54307E_GOAL"

                                          Table "public.AO_54307E_GOAL"
      Column       |            Type             |                           Modifiers
-------------------+-----------------------------+---------------------------------------------------------------
 DEFAULT_GOAL      | boolean                     |
 ID                | integer                     | not null default nextval('"AO_54307E_GOAL_ID_seq"'::regclass)
 JQL_QUERY         | text                        |
 POS               | integer                     | not null default 0
 TARGET_DURATION   | bigint                      |
 TIME_METRIC_ID    | integer                     | not null
 TIME_UPDATED_DATE | timestamp without time zone |
 CALENDAR_ID       | integer                     |

次に、テーブル "AO_54307E_TIMEMETRIC" は、作成された SLA とカスタム フィールドにサービス デスクを関連付けます。簡単に表すと次のようになります。

"AO_54307E_TIMEMETRIC" ."SERVICE_DESK_ID" = "AO_54307E_VIEWPORT" ."ID"

"AO_54307E_TIMEMETRIC" ."CUSTOM_FIELD_ID" = customfield.id = customfieldvalue.customfield

クリックして定義を確認
jira=# \d "AO_54307E_TIMEMETRIC"
                                                Table "public.AO_54307E_TIMEMETRIC"
            Column             |            Type             |                              Modifiers
-------------------------------+-----------------------------+---------------------------------------------------------------------
 CUSTOM_FIELD_ID               | bigint                      |
 DEFINITION_CHANGE_DATE        | timestamp without time zone |
 GOALS_CHANGE_DATE             | timestamp without time zone |
 ID                            | integer                     | not null default nextval('"AO_54307E_TIMEMETRIC_ID_seq"'::regclass)
 NAME                          | character varying(255)      | not null
 SERVICE_DESK_ID               | integer                     | not null
 THRESHOLDS_CONFIG_CHANGE_DATE | timestamp without time zone |
説明 Jira Service Management で SLA に関連する問題のトラブルシューティング方法を確認し、問題の原因を特定するための情報を見つけられる場所について学習します。このドキュメントは SLA のトラブルシューティングの基本を提供することを目的としており、すべての SLA の問題を解決するわけではありませんが、読者が利用可能な基本的なトラブルシューティングを提供します。
製品Jira
プラットフォームServer
最終更新日: 2024 年 1 月 26 日

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

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