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"
テーブルから得られます。
次に、テーブル "AO_54307E_TIMEMETRIC"
は、作成された SLA とカスタム フィールドにサービス デスクを関連付けます。簡単に表すと次のようになります。
"AO_54307E_TIMEMETRIC"
."SERVICE_DESK_ID"
= "AO_54307E_VIEWPORT"
."ID"
"AO_54307E_TIMEMETRIC"
."CUSTOM_FIELD_ID"
=
customfield.id = customfieldvalue.customfield
JQL and SLA on the Database
最後に、課題の一覧で JQL クエリに関連付けられる SLA は "AO_54307E_GOAL"
テーブルにあります。
"AO_54307E_GOAL"."TIME_METRIC_ID"
= "AO_54307E_TIMEMETRIC"."ID"
次に、テーブル "AO_54307E_TIMEMETRIC"
は、作成された SLA とカスタム フィールドにサービス デスクを関連付けます。簡単に表すと次のようになります。
"AO_54307E_TIMEMETRIC"
."SERVICE_DESK_ID"
= "AO_54307E_VIEWPORT"
."ID"
"AO_54307E_TIMEMETRIC"
."CUSTOM_FIELD_ID"
=
customfield.id = customfieldvalue.customfield