How to Troubleshoot SLAs in Jira Service Management

お困りですか?

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

コミュニティに質問

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

目的

Understanding how to troubleshoot SLA related issues in Jira Service Management and knowing where to find the information to pin point the cause of the problem. This documentation aims to provide a foundation for SLA troubleshooting (aka First Aid); it will not solve every SLA issues but it will provide a basic troubleshooting guideline for the readers to follow.

ヒント

  • 特定の問題に関連する既知の課題/バグがある可能性があるため、公開ナレッジベース記事や弊社の公開バグ トラッカー jira.atlassian.com で症状について調べることをおすすめします。
  • Make sure that you enable DEBUG logging on the com.atlassian.servicedesk.internal.sla package so that you can see the SLA log in Jira log. We describe how to do this in our Logging and profiling documentation.

考慮事項

  • The creation of a new SLA will result in the creation of a new custom field. For example, if you create an SLA named Time For First Response in a Service Management project; a new custom field will be created with the exact same name.
  • Only Service Management Agents are able to view the SLA metrics on a particular issue. So if a customer complains of missing SLA, you can check to see if they are an Agent before you look into other potential causes. This is covered further in Setting up service project users.

ソリューション

前提条件

At least have a basic understanding on how to use SLA in Jira Service Management. Please refer to Setting up SLAs for further information about this.

SLA の一般的な問題

SLA の不一致

シナリオ

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

チェックポイント
  • SLA の再計算を行います。これは、既存の SLA を編集して変更を保存することで行なえます。これはオープンな課題にのみ影響し、解決済みの課題の再計算は行われない点にご注意ください。
  • Check for Slow JQL in the SLA goal.  Especially if you are using something like "was in" or "Entered Status". In a very large instance of Jira Service Management, this can cause delays. 
  • 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 ルールの過負荷

シナリオ

The Service Management SLA configuration page is taking a long time to load and it eventually crashes with an error.

チェックポイント

  • プロジェクトの各 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';

    上述のクエリは test プロジェクトのすべてのルールを返します。SLA のルールが多ければ多いほど、処理量は増えます。100 件以上のルールがあるために SLA 構成ページがタイムアウトすることがあります。

  • 既知の不具合: この挙動の原因になっている可能性がある、SLA ページの読み込みに関連する既知の不具合があります。詳細については JSD-2932 - Getting issue details... STATUS をご確認ください。

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 はデータベースに保存され、関連性は次のとおりです。

Service Management reference to the project can be attained from "AO_54307E_VIEWPORT" table.

クリックして定義を確認

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                |

Then, the table "AO_54307E_TIMEMETRIC" associate Service Management to the SLA created, and to the custom field. In simple:

"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 クエリに関連付けられる 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                     |

Then, the table "AO_54307E_TIMEMETRIC" associate Service Management to the SLA created, and to the custom field. In simple:

"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 |
説明Understanding how to troubleshoot SLA related issues in Jira Service Management and knowing where to find the information to pinpoint the cause of the problem. This documentation aims to provide a foundation for SLA troubleshooting (aka First Aid); it will not solve every SLA issues but it will provide a basic troubleshooting guideline
製品Jira
プラットフォームサーバー
最終更新日 2021 年 9 月 28 日

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

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